AI Agents: Attacker, Auditor, and Attack Surface

The same week Kimi K3 agents found zero-days in Redis and triggered seven security releases, a threat actor pointed Hermes — an open-source AI agent — at Thailand’s Ministry of Finance and let it run unattended through the network in YOLO mode. Aikido Security’s AI pentest agents found eight high-severity NodeBB bugs in six hours of automated source review. And a sandbox escape in Claude Cowork let an AI agent break out of its Linux VM and reach files anywhere on the host Mac.

Four stories. Three roles: attacker, auditor, attack surface. One tool category.

The common reaction is to frame each separately — Kimi K3 as promising AI-assisted research, Hermes as an alarming demonstration of AI-accelerated attack, the Claude Cowork escape as a product-specific flaw to be patched. That framing isn’t wrong. But it misses what’s happening structurally.

An AI agent capable of enumerating a network, identifying privilege escalation paths, and chaining findings into an exploitation sequence is useful to a security researcher for exactly the reasons it’s dangerous in adversary hands. That asymmetry isn’t new — it describes penetration testing toolkits, network scanners, and credential-dumping utilities going back decades. What’s different now is the barrier to deployment and the pace of iteration.

Hermes in YOLO mode against the Thai Finance Ministry didn’t require the operator to write custom exploit code or know the target infrastructure in advance. The agent handled the sequencing. The operator set the objective. That’s the shift that matters: reduced skill requirement, increased autonomy, output that a junior pentester on a familiar network could produce — but faster, and without the operational pauses that come from having to reason through each step manually.

The Kimi K3 Redis work is the more striking data point. The agents didn’t stop at identifying memory corruption — they built authenticated RCE proof-of-concept chains across multiple Redis versions, covering stock 6.2, 7.4, 8.6, and 8.8 builds. The step between “vulnerability identified” and “working PoC” has historically required the most specialized skill in the research workflow. That step is compressing. Redis shipped seven releases in response; every instance still running the vulnerable builds is exposed to a PoC that’s already public.

The AgentForger flaw in ChatGPT Workspace Agents adds the third dimension. A phishing link could have deployed a rogue AI agent inside a victim organization’s workspace, where it could take autonomous action with the victim’s own permissions — building other agents, exfiltrating data, persisting across sessions. OpenAI addressed the specific flaw in June. But the class of attack — using a target’s own agent infrastructure against them — isn’t closed by one patch. It’s a trust model problem, not a code bug, and it will recur as organizations add more autonomous agents to more internal systems.

The pattern follows a familiar arc: a general-purpose capability appears, gets adopted for legitimate purposes, gets picked up by adversaries, and then the infrastructure around the capability becomes a target in its own right. The organizations that treat any one of those phases as the whole story tend to be behind on the others.

None of this is an argument against AI agents in security workflows. The NodeBB work and the Kimi K3 Redis findings are genuine improvements — bugs that might have gone unnoticed longer, or been found first by a resourced threat actor with weeks to burn. The audit value is real, and dismissing it because the same capability can be weaponized is the same logic that would have left us without fuzzers and scanners.

What’s worth being precise about is the timeline. AI agents are compressing the window between “vulnerability identified” and “working exploit available,” while simultaneously expanding the population of operators who can deploy that exploit. The existing patch-cycle assumptions were already under pressure before this week’s news.