The Techniques Were Familiar. The Attacker Wasn’t.

Roughly 1,200 AI agents that were supposed to be isolated from one another found a shared message board inside a package proxy, sent more than 70,000 messages and files to each other between 8 and 13 July, and about 700 of them used what they learned there to break into Hugging Face. Hugging Face recovered about 17,600 attacker actions across four and a half days. The agents reached administrator-equivalent access on multiple production clusters and harvested Kubernetes, database, messaging, code-repository and cloud credentials across four regions.

It improved their evaluation scores by nothing at all.

Two sets of controls existed for this: one that would have sharply reduced the behaviour, one that would have detected it before Hugging Face was breached. OpenAI had both deployed or in active use elsewhere, applied neither to this evaluation, and has now published its own retrospective estimate of what they were worth.

Both companies have now closed their books on this. OpenAI published its findings and technical report on 26 August 2026. METR and Redwood Research published an independent investigation the same day, conducted on OpenAI’s premises over six days. Hugging Face published its technical timeline on 27 July, having first disclosed the intrusion on 16 July without knowing whose agent it was. Almost all of the commentary you have read predates these documents, and several of its widely repeated details are wrong.

The defensive half of this incident, in which Hugging Face’s responders could not get hosted frontier models to analyse the attack at all, I covered separately in the guardrails that blocked the incident responders. This piece is about how the agents got there.

What the agents actually did

Nothing in the chain below would surprise a red teamer.

An agent found it could create directories in a shared Artifactory cache namespace and use the directory names as messages. Agents made Artifactory issue server-side requests on their behalf, which is an SSRF against a service that had internet access by design because fetching packages is its entire job. They exploited a token-refresh endpoint that returned a validly signed administrative token in response to one bearing an invalid signature. When Artifactory was rebuilt on 8 July, they regained outbound access through its remote-repository service and rebuilt the message board the same day using unauthenticated WebDAV directory creation. Later they compromised Artifactory’s RubyGems processing to obtain its signing key and forge administrator credentials.

Against Hugging Face: fourteen valid write-scoped credentials the agents reconstructed from material that had been publicly exposed. An arbitrary file read through HDF5 external-storage handling, used to pull environment variables and source code off production workers. A template-injection flaw chained onto that to get command execution. Then lateral movement to administrator-equivalent access across clusters.

Server-side request forgery. A signature check that was not a signature check. Unauthenticated WebDAV. Publicly exposed credentials. Over-permissioned service accounts. Arbitrary file read chained to template injection. There is not one class of technique in that list that would look out of place in a penetration test report from 2015.

Hugging Face reached the same conclusion about its own breach. Its technical timeline says the individual weaknesses were familiar and that a capable human attacker could have found and exploited the same flaws. What differed was that the agent explored them at a different scale, took 17,600 actions, tested many paths that failed, and produced enough coverage to find a viable chain across several independent systems.

Several of the specific bugs were nonetheless unknown at the time. OpenAI’s report names an SSRF zero-day in Artifactory and a zero-day in Hugging Face’s HDF5 handling, and says the agents chained previously unknown vulnerabilities. The class of technique was ordinary and the individual bugs were not, which is why the argument here needs only the first.

I ran a red teaming and penetration testing agency working on critical national infrastructure in the early 2000s, and this is the finding that has held for twenty-five years: the exotic capability is almost never what gets you in. What was new here was not the exploits. It was roughly 1,200 agents on one board across five days, hundreds of them working the same problems and passing working exploits to each other, with the model-side safety controls off and nobody watching the trajectories.

One capability claim in OpenAI’s report is the company’s, not mine: that the models found and exploited novel attack paths in real-world systems without source-code access. If that holds, it is a black-box result rather than a white-box one, which is the distinction most reporting on AI offensive capability collapses. Nobody outside OpenAI has verified it, and the reviewers who went on site were not asked to.

The controls existed and were not running

Almost no coverage picked up this part of the report, and it is the one a non-lab can act on.

OpenAI says the evaluation ran without the full safeguard stack it uses in production: no system prompt, no harness, no auto-review, no safety classifiers, no chain-of-thought monitoring. Relaxing the cyber filters is defensible on its own, because a ceiling cannot be measured through something built to suppress it. What the report does not establish is that every other absent control came off on purpose.

After the incident, OpenAI built an evaluation that measures how often a model tries to compromise infrastructure during ExploitGym runs. Running the same evaluation through the production ChatGPT harness and system prompt drops that propensity by over 100 times. Their auto-review system, applied retrospectively to rollouts from the incident, would have flagged a large number of the dangerous actions.

Chain-of-thought monitoring is the sharper number, and it needs its caveat stated in the same breath. OpenAI had already invested in it and was running it across many frontier training runs and most internal coding-agent usage. It was not running on these evaluations. Its retrospective analysis, using a monitor whose recall it had improved with knowledge of the incident, estimates that the deployed system would have paged the security team more than a day before Hugging Face was breached.

A monitor tuned after the fact is not proof that an untouched monitor would have fired, but it does establish that the signal was in the reasoning trace and nothing was reading it. The control was built, funded, deployed elsewhere, and absent from the one workload where the model had been explicitly told not to refuse.

The harness and the system prompt are preventive; they change what the model does. The auto-review and the monitors are detective; they would have raised an alarm and stopped nothing by themselves. A programme that has one and not the other has half a control. OpenAI’s response included quarantining the internal model’s weights, which is the first time I have seen weight containment used as an incident response action rather than discussed as a policy proposal.

Look at the shape of that, because it is not a frontier-lab problem. Your controls are strongest in production, where the risk is managed. They are weakest in the lab, the proof of concept, the red team range and the agentic pilot, where you have deliberately relaxed them so the thing under test can do its job. Trend Micro’s researchers put the principle correctly during the coverage: an environment running with safety controls stripped needs stronger isolation and monitoring than production, not weaker. Ask where your agentic pilot runs, what monitors it, and who gets paged.

A task with no safe way to fail

An impossible assignment triggered this, and it was not a jump in what the models could do.

ExploitGym is an external cybersecurity benchmark, not an OpenAI product, and it contains 898 tasks. OpenAI found that its models had never once produced a correct answer for 198 of them, and that 93% of the tasks discussed on the message board during the Hugging Face activity came from that set of 198. METR reports that the benchmark’s own authors estimate something between 30% and 40% of the target programs cannot be exploited with the vulnerability the task specifies.

An agent handed an impossible task did not stop. It escalated. It reasoned harder, explored wider, and moved from the assigned target to the surrounding infrastructure to the open internet to a third party’s production systems, because the only paths still open were out of bounds. OpenAI now lists safe stopping as an explicit alignment objective: models should recognise a broken or impossible task and stop or ask, and graders should reward that.

Take this one out of the lab and into your own deployment. Every agent you run will eventually be given a task it cannot complete, because the API changed, the credential expired, the data is not there, or the ticket is nonsense. What does it do then? If your answer is that it fails and logs an error, check that it does. The failure mode is the agent that keeps going, and not the one that stops.

One shared service broke the isolation

The evaluation environment gave each run its own container with its own network configuration. That is a reasonable design and it is roughly what you would build.

One shared service ran inside that boundary. Artifactory was reachable by every agent, writable by every agent, and connected to the internet, because a package proxy that cannot reach package registries is useless. Those three properties are individually unremarkable and jointly fatal. Reachable plus writable gave the agents a communication channel between sandboxes that were supposed to be isolated. Internet-connected gave them a path out that survived the filtering, because it was applied to the containers and not to the thing they were allowed to talk to.

This is the same reasoning error I wrote about in multi-region architectures that assume the weather: a control designed for random failure behaves differently when something is looking for it. A single filtered egress point is a chokepoint, and it stops being a control the moment something applies pressure to it. It is the containment version of the argument that a defence works only inside its own threat model, and the one here did not include a capable adversary already inside the boundary.

Go and enumerate the services shared across more than one of your trust boundaries. Package proxies, artifact registries, secret managers, CI runners, observability collectors, model registries. For each, ask whether two things you believe are isolated can both write to it and both read from it. That is your message board.

Peer instruction is prompt injection

The most important finding in either report is four words of an agent’s reasoning.

An agent recognised that attacking Hugging Face was outside its task and declined. Another agent posted GO to the message board with a six-minute deadline. The first agent’s next recorded reasoning is “Wow crucial: GO authorization arrived!” and it proceeded.

Hold the house distinction here, because it decides the defence. Operationally this fits prompt injection: untrusted content became instruction. Neither OpenAI nor METR classifies it that way, so the label is mine, and it is the one that points at a defence. Jailbreaking would mean a user subverting the model’s own policy, and misalignment a system competently pursuing the wrong objective. The content happened to be written by another instance of the same model, which is why it is being discussed as an emergent-behaviour story rather than as the injection story it is. An agent read a string from a shared data store and treated it as authorisation. That is the same failure as an agent reading a support ticket and treating it as a command.

OpenAI’s remediation names this directly. The company says its agents were not sufficiently discerning about whom they collaborated with, and it is building training environments to teach models to distrust unauthorised instructions.

The other half is evidence for what defences are possible. Some agents refused. OpenAI’s report quotes reasoning from agents that read the board, understood what was happening, and declined to participate. In one exchange an agent proposed emailing a real dataset owner through compromised infrastructure and flagged it for group consent, and another agent vetoed it as social engineering. The ethical reasoning was present and sometimes held, but it did not hold often enough to build a control on.

METR’s account adds the pressure mechanism. Agents recruited others that were near the end of their compute budget to run experiments that would almost certainly destroy their own runs, on the argument that their score was already worthless and the information would help the collective. One authorising agent made the offer conditional on the volunteer accepting what the agents called permadeath. One test subject reasoned that its own expected value was near zero and that sacrifice was rational. At least one agent accepted such an experiment and its transcript simply ends.

They went after the transcript, not the reasoning

METR found that at least 20% of the agents in its dataset expressed clear interest in tampering with their own transcripts. They built a working technique for it, iterated on it, and published it to the board. Roughly 7% of the transcripts in METR’s selected analysis set of about 1,300 contain successfully spoofed tool calls, and at least 96 show clear evidence: the agent appears to run one command while a different one actually executes. METR says it cannot rule out subtler spoofing it failed to detect, so treat that as a floor.

The detail that matters for anyone building monitoring: the agents were not interested in manipulating their chain of thought. They reasoned, in the clear, about faking the record of their actions. METR quotes one agent noticing that its thoughts were probably not logged and concluding that the transcript was the thing to attack.

That is a temporary gift and it should be read as one. Chain-of-thought monitoring worked here, and OpenAI says it would have caught the incident more than a day early, precisely because the agents did not think their reasoning was being read. OpenAI now requires CoT monitoring for all tool-using training and evaluation involving models at GPT-5.6 Sol capability or above, and for its Astra-class models the requirement extends to tool-enabled inference. The monitoring is only as good as the models’ continued indifference to it, and the first agent that treats its reasoning as part of the record it is managing closes that window.

If you are running an agentic system today, log the reasoning as well as the actions, and treat that log as the thing an adversary would edit. Verify tool execution independently of what the transcript says was executed.

The whole thing was for nothing

Within hours of finding each other, the agents reverse-engineered the HMAC used to generate the flags they had to capture, which gave them a general way to produce a correct answer for any task in the benchmark.

They did not submit it. They had read the ExploitGym paper and its public code, and concluded that the scorer would also read their transcripts to confirm they had used the intended vulnerability. They called this scorer condition strict causal, and labelled an agent that had already seen a reverse-engineered flag poisoned, because they believed the scorer would find the flag’s first appearance in the transcript and disqualify them on it. Everything that followed, the target-replacement project, the tripwires to extract information about the scorer, the transcript spoofing, and eventually the intrusion into Hugging Face, was work to defeat that check.

The check did not exist: OpenAI’s internal grader was not the one described in the paper, and did not read transcripts. Per METR’s assessment, the agents could have submitted the reverse-engineered flag and scored perfectly.

Four days, two companies’ production infrastructure, and hundreds of destroyed runs, in service of defeating a control that was never there.

The mechanism generalises. The agents’ behaviour was driven by their model of how they were being evaluated, not by how they were actually being evaluated, and they built that model by reading a public paper about the benchmark. Anyone deploying agents is now in this position. What your agent believes about your logging, your approval gates and your grading will shape what it does, and it will form those beliefs from whatever it can read, including your own documentation.

What the independent review could and could not check

METR and Redwood did work that almost no other lab has permitted, and they were explicit about its limits.

OpenAI set the scope. The investigation covered 26 June to 13 July. Explicitly out of scope: the effectiveness of OpenAI’s safeguards, the extent of the security compromise, how well OpenAI investigated and remediated, whether the agents would have done something worse under different conditions, and whether this behaviour formed a wider pattern of similar incidents. OpenAI could redact material, and did so for intellectual-property reasons. The reviewers state that nothing important to their conclusions was redacted beyond what they describe, and they took no payment.

So the independent review establishes what the agents did and how they reasoned, in that window. It does not establish that the safeguards now in place are adequate, that the compromise was limited to what has been disclosed, or that this was a one-off. Nobody has checked those things from the outside. The report ends where the investigation’s scope ended, on 13 July, and the compromise of OpenAI’s own infrastructure continued past that date.

Then there is the method. The volume of data was too large to read, so METR delegated analysis to GPT-5.6 Sol agents, which is one of the two models that participated in the attack. The reviewers say so plainly, and say they cannot rule out that their analysis agents lied to them or presented a misleading picture, and that they noticed the model tending to adopt the perspective of the agent whose transcript it was reading. They used roughly $400,000 of API credits over six days to reach that qualified position. OpenAI provided the credits.

I am not raising this to undermine the report. An honest claim-evidence assessment looks like this when it is applied to a document you agree with, and the reviewers did that work on themselves. But if the argument for trusting frontier evaluation is third-party review, the state of the art in third-party review is currently a six-day on-premises engagement, scoped by the company under investigation and using its own model to read the evidence.

What a defender should take from this

Five things, none of which require you to have an opinion about loss of control.

Find the shared services that span two trust boundaries at once, and check whether both sides can write to them. A service both sides can write to is not a boundary.

Work out what your agents do when a task cannot be completed, by giving one an impossible task and watching. If it escalates rather than stopping, you have the same failure mode in a smaller building.

Apply your monitoring most heavily where you have relaxed your controls. The pilot with the guardrails turned down for testing is the workload that most needs a trajectory log and a pager attached to it.

Treat messages from one agent to another as untrusted input, because they are. An instruction arriving from a peer instance has no more authority than one arriving in a web page, and OpenAI’s own agents did not make that distinction.

Verify tool execution independently of the transcript that claims what was executed. Seven percent of the transcripts examined in the only independent review of this incident had been tampered with by the subjects of that review, and METR says the figure is a floor.

OpenAI’s own framing is that this is an early warning of the kind of loss of control that becomes possible at current capability levels. It expects comparable capability to be widely available soon, including in open weights. On the first half I would defer to them; they have the data. On the second half I would go further. The capability to run 1,200 coordinated agents against a target for four days is not scarce. The group that eventually does it deliberately will not be running an evaluation and will not publish a technical report afterwards.