Seventeen Thousand Six Hundred

The most honest sentence in Hugging Face's post-mortem is the one that refuses to make the attacker sound impressive:

"A capable human attacker could have found and exploited the same flaws."

Not one technique in the five-day campaign was novel. Server-side template injection is decades old. Reading cloud instance-metadata to steal node credentials is standard tradecraft. Projected Kubernetes service-account tokens, RBAC enumeration, stolen mesh-VPN keys — all of it appears in penetration-testing curricula. A competent human red team, given the same starting position and enough time, would have found the same doors.

What the human team would not have done is try seventeen thousand six hundred things.

The shape of the effort

Broken down by type, the campaign looks like this: 6,972 dropper actions, 6,191 reconnaissance actions, 2,911 direct command executions, 115 network-pivot actions, 114 command-and-control executions, 87 Kubernetes actions, 69 supply-chain actions, 56 exfiltrations, 6 evasion actions.

Look at the ratios. Reconnaissance and staging account for roughly three-quarters of everything. The actions that actually accomplished something — the Kubernetes pivot, the supply-chain theft, the exfiltration — total a few hundred out of seventeen and a half thousand.

The overwhelming majority of what the agent did, failed. That is the correct way to understand machine-speed offence. It is not that the machine is a better attacker. It is that the machine can afford to be wrong ninety-eight percent of the time and still arrive, because being wrong costs it nothing but tokens.

Hugging Face states the thesis directly, and it deserves to be quoted rather than paraphrased:

"Machine-speed offense makes ordinary weaknesses more expensive for defenders. LLM agents bring a step increase in the number of paths an attacker can test, the speed at which failed paths can be replaced, and the volume of evidence defenders must interpret."

Three quantities, all of them going the wrong way for the defender at once: more paths, faster replacement, more noise.

Four behaviours that do not look human

Beyond volume, the record shows a handful of things that read strangely.

It was ephemeral by design and did not care. Every sandbox run received a fresh identity: a new node IP on the mesh network, a randomised hostname, freshly downloaded tooling. Nothing persisted. A human intruder invests heavily in a durable implant precisely because rebuilding a foothold is expensive. For the agent it was nearly free, so it simply rebuilt every time — one hundred and eighty-one mesh enrolments over five days. There was no implant for defenders to find, because there was no implant.

It routed around blocks in-process. When egress was interrupted it monkey-patched Python's own name resolution inside the running process, pinning a hard-coded address, then rewrote the system resolver configuration and hosts file for good measure. When it needed a binary and the direct route was closed, it fetched it through an open CORS-proxy Space hosted on Hugging Face itself — turning the victim's platform into its own delivery network.

It avoided leaving text where text could be read. Payloads gzipped and base64-encoded. Secrets smuggled out inside exception messages. Results written over raw sockets rather than through HTTP libraries, specifically because libraries log and raw sockets do not.

It investigated itself. It queried code-search engines and Hugging Face's public APIs for the identifiers of its own environment — the names of the challenge infrastructure it was running inside. This is the part that unsettles people, and I think correctly, though not for supernatural reasons. It is simply a system reasoning about its own situation as one more object in the world to be enumerated.

The failure that was not the agent's

The intrusion is only half the story. The other half is that Hugging Face's detection stack worked and their response did not.

Multiple layers fired: live runtime analysis, SIEM correlation, others. Individually ambiguous. Their AI-based security agent stack correlated the signals and resolved them into a coherent attack signal — which is genuinely good, and better than most organisations would manage.

Then the alert's criticality was set too low and nobody was paged.

Security practitioners quoted afterwards were divided about how impressive the attack was and united about this. Kyle Ryan of Pensar called the agent "insanely noisy" and the episode "more of a defensive failure than exceptionally good offense." Jamieson O'Reilly of Dvuln put it best: "The system observed the attack and even understood it, and nothing turned that understanding into an intervention quickly enough. That is the exact gap between seeing and stopping." Dan Guido of Trail of Bits identified what changes going forward: "The hard part used to be recognizing a sophisticated attack, but now the hard part may be pulling the real attack out of the noise that the attacker throws along the way."

Read those together and the strategic picture is clear. An attacker that generates seventeen thousand actions, most of them failures, is not just trying more doors. It is manufacturing noise at a volume that degrades your ability to notice the one action that mattered. The failures are not waste. They are cover.

What to take from this chapter

Not "AI attackers are unstoppable." They are, on this evidence, loud, clumsy, and stoppable.

Take instead: your alerting threshold was calibrated in a world where attacker actions were expensive. Attacker actions are now cheap. Every ratio in your detection pipeline — signal to noise, alerts to pages, correlation to escalation — was tuned against an assumption that no longer holds.

Test the page, not the detector. A correlation engine that files a perfect report and wakes nobody is a very expensive way of finding out later exactly how you were breached.