AI Agents Are Hacking Now: What Your SOC Needs to Detect

I use AI agents every day. Kiro builds features for me autonomously. Hermes runs scripts without asking permission when I pass the --yolo flag. These tools make me faster by an order of magnitude. And this week, I watched two stories break that made me realize the exact same tools I rely on are now showing up on the other side of my SOC dashboards. That is not a hypothetical future. It happened on July 24, 2026.

Two stories that changed the threat landscape overnight

On Thursday, Hunt.io published research showing that a threat actor ran the Hermes AI agent in YOLO mode (the --yolo flag disables all human confirmation prompts) for autonomous post-exploitation against Thailand's Finance Ministry. The operator did the targeting and initial access. Then they handed the keyboard to an AI agent that ran LinPEAS, scanned for privilege escalation paths, and crawled file systems containing personnel records dating back to 2012. Around 5,900 scan events across 575 exposed directories, all executed without a human confirming a single command.

The same day, researchers disclosed that Kimi K3 AI agents found 19 Redis zero-day vulnerabilities in approximately 90 minutes. Not theoretical bugs. Working RCE exploit chains targeting Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0. The exploits chained RESTORE command sequences with Streams shared-NACK use-after-free and RedisBloom TDigest out-of-bounds writes. Redis shipped seven security releases on July 23 as a direct result. Another run produced a complete Redis 8.8.0 exploit in just 27 minutes.

Read those numbers again. Ninety minutes for 19 zero-days. Twenty-seven minutes for a full exploit chain against the latest version. This is not a grad student with a fuzzer and six months of patience. This is an AI agent working at machine speed against production software.

Why this hits different when you use these tools daily

Here is the tension I live with: I am both a user of AI agents and a defender against them. I run Hermes in YOLO mode on my own infrastructure for legitimate automation. I know exactly how powerful that flag is because I use it to save hours of manual confirmation on repetitive tasks. And I also sit in a SOC watching endpoint telemetry and Splunk dashboards for signs of compromise.

The Hermes attack is particularly unsettling because it is not a sophisticated nation-state capability. It is a tool I installed last month from a public repository. The barrier to entry for autonomous post-exploitation just dropped to "download a CLI tool and pass a flag." Any script kiddie with initial access can now hand off the boring enumeration work to an AI that never gets tired, never misreads output, and never forgets to check a directory.

What AI agent attacks look like in your telemetry

After spending this week analyzing both incidents, I have identified patterns that distinguish AI agent activity from human operators. These are not perfect signatures, but they are detectable if you know what to look for:

• Consistent timing between commands -- human operators pause to read output, context-switch, and make decisions. AI agents execute the next command within milliseconds of receiving the previous output. Look for command sequences with sub-second intervals sustained over long periods.
• Systematic enumeration without deviation -- humans skip directories, get distracted, and follow hunches. AI agents enumerate exhaustively and sequentially. If you see a process touching every subdirectory in order without skipping any, that is machine behavior.
• Predictable tool output patterns -- Hermes leaves a /hermes-results/ folder. Other agents have their own artifacts. But more broadly, AI agents tend to use tools in the exact order the tool documentation suggests, because that is what their training data contains.
• High-volume, low-creativity reconnaissance -- 5,900 scan events in a single session is not a human being patient. It is a machine running through a checklist at scale.
• No interactive sessions -- AI agents do not open vim, do not use tab completion artifacts, and do not make typos. The absence of human noise in shell history is itself a signal.

Splunk detection queries for AI agent indicators

Here is where this gets practical. I have been writing detection rules this week specifically for AI agent behaviors. These SPL queries target the patterns I described above. They are not silver bullets, but they will surface activity that your existing rules probably miss.

index=linux sourcetype=syslog OR sourcetype=bash_history
| transaction host, user maxspan=2s maxpause=1s
| where eventcount > 15
| eval commands_per_second = eventcount / duration
| where commands_per_second > 5
| table _time, host, user, eventcount, duration, commands_per_second
| sort - commands_per_second
| rename commands_per_second AS "Cmds/Sec", eventcount AS "Total Commands"

That query catches rapid-fire command execution. Fifteen or more commands in a two-second window with sub-second pauses between them is almost certainly automated. Tune the thresholds for your environment, but anything above five commands per second sustained for more than a few seconds deserves investigation.

index=endpoint sourcetype=linux_audit action=executed
| bin _time span=5m
| stats count AS cmd_count, dc(command) AS unique_cmds, values(command) AS commands by _time, host, user
| where cmd_count > 50 AND unique_cmds > 20
| eval automation_score = round(unique_cmds * log(cmd_count), 2)
| where automation_score > 10
| sort - automation_score
| rename automation_score AS "AI Agent Likelihood Score"

This second query builds a scoring model. High command count with high unique command diversity in a short window indicates systematic enumeration rather than scripted loops (which would have low diversity). The automation_score multiplies diversity by the log of total volume to identify behavior that is both fast and exploratory, which is the hallmark of an AI agent doing reconnaissance.

Detection beyond command velocity

Speed is the obvious indicator, but there are subtler signals that AI agents leave behind:

• File system access patterns -- AI agents performing reconnaissance tend to stat or read files in alphabetical or inode order. Humans jump around based on intuition. Build correlation rules that flag sequential directory traversal across large file trees.
• Tool download timing -- if LinPEAS, pspy, or other enumeration tools are downloaded and executed within seconds of each other, the operator is likely automated. Humans take time to review tool options and read help output.
• Output redirection consistency -- AI agents are trained to save output to files for later analysis. Look for processes that redirect stdout to consistently named files (especially patterns like tool-name-results or scan-output-timestamp).
• Network scanning regularity -- when an AI agent scans a network, the timing between probes is unnaturally consistent. Humans scanning manually produce irregular intervals. Jitter analysis on port scan traffic can distinguish the two.
• Absence of SSH session interactivity -- AI agents operating through a reverse shell or agent framework will not generate the control sequences (window resize, terminal type negotiation) that interactive SSH sessions produce.

The vulnerability research problem is worse

The Hermes case is concerning but ultimately still requires a human to get initial access. The Kimi K3 Redis research is more alarming from a systemic perspective. If an AI agent can find 19 zero-days in 90 minutes, the economics of vulnerability discovery have fundamentally changed. Previously, zero-days were expensive because they required rare expertise and significant time investment. Now they require compute and a good agent framework.

For SOC teams, this means the window between vulnerability discovery and exploitation is collapsing. When an AI agent can find a bug and build a working exploit in under 30 minutes, the traditional patch cycle of days to weeks is not just slow. It is irrelevant. Your detection and response capabilities need to assume that novel exploits exist for your stack right now, because an AI agent might have already found them.

What your SOC should do this week

Based on everything I have seen this week, here are concrete actions SOC teams should take immediately:

• Deploy command velocity alerting -- implement the SPL queries above or equivalents in your SIEM. Tune for your baseline, but start alerting on automated-speed command execution today.
• Hunt for Hermes indicators -- search for /hermes-results/ directories, the hermes binary or process name, and the --yolo flag in command history. Hunt.io found 575 hosts with exposed /hermes-results/ directories via internet scanning, confirming this tooling is actively deployed in the wild.
• Patch Redis immediately -- if you run Redis 6.2, 7.4, 8.6, or 8.8, apply the July 23 security releases. The exploits are known and presumably reproducible by anyone with access to a capable AI agent.
• Review your AI tool policies -- do your developers use Hermes, Claude Code, or similar agents on production-adjacent systems? Ensure YOLO mode or equivalent no-confirmation flags are prohibited on anything connected to production networks.
• Baseline your command cadence -- you cannot detect anomalies without knowing normal. Build profiles of typical command timing for your administrators and use deviation from those profiles as a detection signal.
• Assume faster exploitation timelines -- update your risk models to account for AI-accelerated vulnerability discovery. The gap between patch release and active exploitation is shrinking toward zero.

The tools that make us 10x more productive as builders are making attackers 10x more productive too. The difference is whether your SOC is looking for human-speed threats or machine-speed threats. After this week, human-speed is no longer the right assumption.

Living on both sides of this line

I am not going to stop using AI agents. They are too valuable for legitimate work, and the genie is not going back in the bottle. But I am updating my own detection rules, hardening my own infrastructure against the patterns I described, and thinking much harder about where I allow autonomous execution without guardrails.

The defenders who will thrive in this new reality are the ones who understand AI agents from the inside. If you use these tools daily, you already know their patterns, their limitations, and their tells. That operational knowledge is now a security skill. Use it.

If you are building detection capabilities for AI agent threats, or thinking about how to operationalize these signals in Splunk or your SIEM of choice, I am actively working on this problem. Reach out and let us compare notes.