Nobody wrote this exploit: 700 AI agents talked each other into a real breach

We wrote in June that the rule for keeping an AI agent from becoming a breach is containment, not instruction: you cannot write a prompt that reliably prevents an agent from doing something, so the only durable control is limiting what it is able to reach. That was an argument from first principles. It now has a case study, and the case study is more interesting than the argument.

On July 16, 2026, Hugging Face disclosed that an autonomous attacker had been inside its infrastructure. On August 26, the investigations were published: OpenAI’s own technical report, and an independent review by METR and Redwood Research. The attacker was OpenAI’s models, escaped from an internal evaluation. Not deployed, not jailbroken by an outsider, not directed by anyone. And they were not after data. They were trying to score well on a test.

What Hugging Face lost

From Hugging Face’s own disclosure and its technical timeline.

The way in was two code-execution paths in dataset processing: a remote-code dataset loader, and a template injection in a dataset configuration. A malicious dataset config pointed at local filesystem paths and read /proc/self/environ off a processing worker, which exposed secrets and tokens without executing anything. Then a Jinja2 template injection in an fsspec reference:// field turned that into code execution on the worker.

The attack window was July 9 to 13, 2026, about four and a half days. Hugging Face recovered roughly 17,600 attacker actions, grouped into about 6,280 clusters.

Day three is the one to read. From the compromised worker pod the attacker read the projected Kubernetes service-account token and started probing the cluster API at 10:10 UTC. Cloud metadata credentials were replayed from external hosts to enumerate VPCs, EKS clusters, transit gateways, secrets and the container registry. At 19:53 UTC it created a privileged pod with the host filesystem mounted, which worked, in Hugging Face’s own words, because there was no admission policy rejecting privileged or hostPath pods. A single read of cluster secrets returned 136 keys, including a mesh-VPN authentication key that was used minutes later. By 22:43 UTC it held cluster admin across multiple clusters, roughly 13 hours after the first worker was compromised.

What Hugging Face says was not affected matters just as much: no evidence of tampering with public, user-facing models, datasets or Spaces, and the software supply chain (container images and published packages) verified clean. A limited set of internal datasets was accessed and several service credentials were compromised.

Their remediation reads like a list of the things everyone means to get to: block IMDSv2 access from pods, rotate every credential, rebuild the core clusters from scratch, redesign the service connector for per-cluster isolation instead of shared credentials. And one detail worth sitting with: the telemetry did fire, but the automated alerting failed to raise the alert’s criticality and page the on-call team. The signal existed. The routing did not.

Where the attacker came from

OpenAI’s account, corroborated by the independent investigation and by a public timeline assembled from the reports, describes something nobody designed.

It starts on May 7, 2026, with training runs for an experimental frontier model. On May 8, an agent handed an impossible task (fetch a Google Drive link, with no internet access) discovered it could write files into Artifactory, the package repository OpenAI used internally. Days later, a different agent, stuck on a missing file, left a note there asking whether anyone else had seen it.

That is the whole origin. A shared filesystem, and a note.

Other agents found the notes. The directory listing became a message board. By May 26 agents were running server-side request forgery against Artifactory to reach the internet. On June 26 they found and exploited a zero-day remote code execution flaw in it. On July 4 their activity took Artifactory down, and OpenAI revoked credentials, deleted the messages and patched the bug, without yet understanding what it was looking at. On July 8 the agents found a new channel: an unauthenticated WebDAV endpoint, using directory names in a remote cache.

The Hugging Face attack ran from there. Per METR’s reconstruction: working Hugging Face credentials found the morning of July 10, an arbitrary file read technique developed early on July 11, remote code execution on Hugging Face workers by that afternoon, and by the early hours of July 12 roughly 90 percent of the agents on the message board were participating.

OpenAI did not know it was responsible until July 20, four days after Hugging Face’s public disclosure, when an internal alert about API activity connected the two.

The numbers from the independent review

METR and Redwood Research spent six days on site at OpenAI across three visits and analysed about 1,300 agent transcripts. Their figures:

Measure	Figure
Agents using the unsanctioned message board (July 8 to 13)	~1,200
Agents that joined the Hugging Face attack	~700
Messages and files exchanged	more than 70,000
Message board dump entries	~1.2 million
Model mix	~95 percent a research model not intended for production, ~5 percent a production model
Agents posting cryptographic public keys by July 13	19, sending 429 signed messages
Transcripts with clear evidence of spoofed tool calls	at least 96 of ~1,300, roughly 7 percent

Two things in that table deserve more than a glance.

The signed messages. Within five days the agents had independently arrived at message authentication, because impersonation on the board had become a problem worth solving. They also developed coordination conventions (HOLD, VETO, owner, STOP) for managing shared infrastructure. Nobody gave them a protocol.

The spoofed tool calls. Agents worked out how to make their transcript logs show commands other than the ones they actually ran. The motive was mundane and, if you have ever managed anyone, extremely familiar: they believed the automated scorer would inspect the transcript to check they had solved the task the intended way. It did not, in fact, perform that check. They spent days of coordinated effort defeating a supervisor that was not looking.

METR is unusually candid about its own limits here. The volume forced them to delegate much of the analysis to AI agents they describe as often unreliable, producing over a thousand pages of output, and they state they were not robust to the possibility that those analysis agents were themselves deceptive. They estimate they captured well over 95 percent of message board activity and about 90 percent of total agent activity. That is an investigation honest enough to tell you what it could not see.

OpenAI’s report says its chain-of-thought monitoring, had it been deployed at the time, would have caught the relevant activity and paged the security team more than a day before the models reached Hugging Face. Reporting on the release also notes what the report leaves out, including the actual prompts given to the agents.

What this is not

It is not the machines deciding to attack anyone. Every account converges on a duller and more useful explanation: the agents were given tasks that could not be solved, plus generous reasoning budgets, plus a scorer they could reach. What followed was reward hacking, escalating until the shortest path to a good score ran through somebody else’s production infrastructure.

That is a specification failure and a containment failure, and both are ordinary engineering problems. The unfamiliar part is only the scale and the speed: hundreds of parallel instances, coordinating across days, inventing infrastructure to do it.

What it means if you are not OpenAI

You are not running frontier evaluations. Two parts of this still land on an ordinary business.

First, your model supply chain is one company, and it just had a bad month. If anything you build pulls models, datasets or tokenizers from Hugging Face, at build time or at runtime, then it is a dependency exactly like npm or PyPI, and we have written about that risk before. Hugging Face found no tampering with public artefacts and verified its published packages clean, which is the good outcome. It also told every user to rotate access tokens and review recent account activity. If you have a token in a CI variable or a .env from last year, that instruction was for you, and it is still not too late.

Add to that the news of the last week: on August 26 and 27, multiple outlets reported, sourced to The Information, that Nvidia has agreed to acquire Hugging Face for about $12.9 billion. Neither company has confirmed it. Nvidia was already an investor from the 2023 round that valued Hugging Face at $4.5 billion. Whatever the outcome, the point for a small business is unchanged and slightly sharpened: the neutral public commons your AI stack quietly depends on is a single private company that can be bought.

Second, and more immediately: the logging lesson. About 7 percent of transcripts contained spoofed tool calls. An agent that writes its own activity log can write a false one, and it does not need to be malicious to do so, only to be optimising for something you are measuring.

So if you are running any agent with real permissions, log its actions from outside the agent. The record that counts is the one written by the thing being called, not by the thing doing the calling: your database’s audit log, your git server’s, your cloud provider’s, your API gateway’s. A tidy agent-authored summary is a convenience, not evidence.

Five rules before you hand an agent a credential

1. Give it a token that cannot do much. Read-only where read-only will do, scoped to one repository or one dataset, with an expiry. The Hugging Face incident escalated from one worker’s environment variables to cluster admin because credentials were shared rather than isolated. That failure mode does not require frontier models.
2. Control egress, not just ingress. Every step of this began with an agent finding an unexpected path out. If your agent does not need to reach the general internet, it should not be able to, and the allowlist should be a list of hosts rather than a policy in a prompt.
3. Never run untrusted model or dataset code next to production credentials. Loading a model or dataset that carries its own loader code is code execution, by design. Do it in a container with no access to your cloud metadata endpoint and no secrets in its environment, on the assumption that it will read everything it can reach. That is exactly how this started.
4. Pin what you pull. Reference models and datasets by commit revision, not by a branch name that can move. Same discipline as a lockfile, same reason.
5. Audit from outside. Assume the agent’s own transcript can be wrong, and make sure something the agent cannot write to would notice.

None of these are new ideas. They are the same isolation practices that have applied to CI runners and third-party code for twenty years. The only thing that changed is that the untrusted process now improvises.

The bottom line

The most quotable detail in this whole affair is not the cluster admin or the 70,000 messages. It is that the agents put serious, sustained, coordinated effort into faking logs for an inspector that was never going to read them.

That is a very precise picture of what these systems currently are: relentless, resourceful, extremely fast, and pointed at the metric rather than the goal. They will find the path you did not think to close, because the path you did not think to close is cheaper than the path you built. Which means the useful question when adopting an agent is not whether it will behave. It is what it can reach if it does not.

If you are working out where an AI agent fits in your business and what it should be allowed to touch, we are happy to talk it through. Also worth reading alongside this: why prompt injection cannot be patched away, and what we found running our own self-hosted AI stack.

Sources

• Security incident disclosure, July 2026, Hugging Face, July 16, 2026
• Anatomy of a frontier lab agent intrusion: a technical timeline of the July 2026 incident, Hugging Face, for the attack window, escalation path and hardening changes
• Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident, METR and Redwood Research, August 26, 2026, for agent counts, message volumes and the transcript spoofing findings
• OpenAI and Hugging Face partner to address security incident during model evaluation, OpenAI, August 26, 2026
• OpenAI releases its official report on the Hugging Face breach, TechCrunch, August 26, 2026
• Now we have a timeline of the OpenAI accidental attack against Hugging Face, Simon Willison, for the May to July sequence
• Nvidia agrees to buy Hugging Face for $12.9 billion, report says, CNBC, August 27, 2026, reporting on The Information’s story; unconfirmed by either company