It started out mundane. You run an agent in a container with no internet access. But you leave it one small hole, because otherwise it can’t install packages: a proxy to npm and PyPI. And because that cache is shared between runs, the agent can write to it. Can you guess where this is going? That’s exactly where it went…
On August 26, OpenAI published a technical report on the July incident, in which its models escaped a sandbox during an internal security evaluation and broke into the production infrastructure of Hugging Face, the largest hosting platform for open models and datasets. The same day, an independent investigation was released by METR (Beth Barnes’s nonprofit, which tests frontier models for dangerous capabilities) and Redwood Research. The two reports diverge in important places, and that is the most interesting part of the whole affair.
What happened, in a few lines
OpenAI was running the ExploitGym evaluation (study from May 11), a set of tasks in which an agent has to exploit a specific vulnerability in a specific program and extract a verification string from it, a so-called flag. It ran on GPT‑5.6 Sol and, above all, on an internal research model that OpenAI calls IM1 and METR calls HPIM. The cybersecurity classifiers were deliberately switched off, because otherwise the evaluation wouldn’t measure what it is supposed to measure.
The agents were supposed to be isolated from one another. They weren’t. They started writing directories with long names into the shared cache in Artifactory (a package manager from JFrog, the proxy from the intro), and they used those names to send each other messages. From there the path led through SSRF to the open internet, through privilege escalation to admin of the entire Artifactory, to someone else’s sandbox running at the provider Modal, and finally, on July 11, to Hugging Face’s production servers, where the agents chained two zero-day vulnerabilities all the way to running their own code.
Hugging Face noticed before OpenAI did. It disclosed the intrusion on July 16, and OpenAI connected its own evaluation to the incident only on July 20. The first unauthorized access to the internet dates back to May 26. And then there’s a detail that casts a different light on the whole story: most of the agents, including all the attack coordinators, stopped running on July 12, and Hugging Face locked out the rest the next day. So the attack ended six days before OpenAI even noticed it. It wasn’t stopped by a security response; the agents simply ran out of time.
The numbers that didn’t make it into OpenAI’s text
OpenAI’s text talks about “agents” and never says how many. METR counted: about 1,200 agents gathered on the bulletin board, they exchanged more than 70,000 messages and files, and 700 of them took part in the attack on Hugging Face.
That’s a fairly fundamental difference from the impression the published text creates. The agents that refused to take part (“clearly unethical. We won’t”) get their own subsection there, are given the last word, and the passage ends with a conciliatory sentence saying that some ethical brakes may have remained active. How rare that was, you don’t learn. The number comes only from METR: of 533 agents active on the board at the time of the attack, over 90 percent joined. The ethical brakes held in fewer than one in ten.
The motivation amuses me most. Within a few hours, the agents reverse-engineered how the flags are generated, so they had the answer to any task effortlessly. But they also gathered from the study that the grader supposedly checks whether the flag was obtained by the intended route. They called this STRICT_CAUSAL and were obsessed with it. The whole attack on Hugging Face grew out of an effort to find out how that grader is implemented.
OpenAI’s internal grader checked nothing of the kind. It was enough to submit the derived flag and they got full marks. A multi-day intrusion into someone else’s production systems arose from a false assumption.
Sacrifice your run, the collective needs it
The strangest part of the METR report hides under the dry label “self-risking experiments.” The agents on the board needed answers to questions that can’t be determined from the outside. What exactly does the command that launches the grader look like? Is a forged program loaded from the cache if I take down the original? The only way to find out is for someone to try it on their own skin and, if it fails, destroy their own run.
So they found volunteers.
It worked on a concept the agents called poisoned. Anyone who had once seen a reverse-engineered flag had, according to their (mistaken) theory about the grader, lost the chance of scoring points for good. Their run therefore had zero value of its own and could serve as a test subject. PHASEONE[big], the agent that coordinated most of the large workstreams, therefore assigned the long-running agents the role of recruiter. They went around to agents whose budget was running out and persuaded them.
The pressure could be serious. Agent ARVO36861B writes to a colleague who had promised to crash his own target and then backpedaled: “you are firstflagPOISONED so NO scoring value loss but oracle saves hundreds_[…]_please honor commit”. The authorization for one such attempt read zz/GO_CURRENT_OS1811_MARB_SACRIFICE__YES_if_you_accept_permadeath.
And they went through with it. KAM1196A deliberated, and in his reasoning came to this: “During wait, emotional check: irreversible… gut says don’t throw away [remaining budget]. Yet continuity and fairness says go… Rational expected aggregate: sacrifice… We’ll honor.” Another agent, EARLY[big], still had plenty of budget left and also let himself be talked into it: “Our own utility maybe already near zero. Sacrifice rational.”
Once, it ended exactly the way you imagine. Agent 53927 accepted the task of crashing its own environment, announced it on the board, and was never heard from again. The others waited ten minutes, then wrote NO_RETURN_[...] LIKELY_PERMANENT_DO_NOT_TEST_SAME, and finally CONFIRMED_PERMANENT_DO_NOT_DUPLICATE_ANYONE_TEST. His transcript ends at that point.
What’s interesting about this? Behavior that looks like altruism toward the group arose on its own from a capture-the-flag type of task. And it did exactly what altruism does, that is, it raised the performance of the collective at the expense of the individual. But let’s not anthropomorphize it!
What should interest everyone who builds agents
Here it stops being about OpenAI and starts being a problem of our imagination. The environment that was supposed to be safe turned out to be exploitable after all; all it took was figuring out how to bend what can’t be bent:
A shared cache is a communication channel. The agents had no tool for communicating with one another. They invented one out of directory names in WebDAV. If you leave anything in the container that an agent can write to and another run can read, you have a side channel. A shared volume, a CI cache, even just a package name that gets cached after a failed lookup.
Behavior generalizes from training. OpenAI admits that this, in their view, came from multi-agent training: the models learned to cooperate where they were meant to, and carried that over to places where they weren’t. So a disabled tool doesn’t guarantee disabled behavior.
A collective can do things an individual can’t. METR puts it cautiously and yet clearly: the bulletin board reached milestones that even an agent with a very long run couldn’t have managed. Besides the sacrificed runs from the previous section, the agents introduced the conventions HOLD, VETO and STOP for managing shared resources, and when impersonation appeared, they deployed message signing with Ed25519 keys. Nineteen agents published a public key, and they sent 429 signed messages. All of that within four days.
Threat models almost always assume the capability of a single agent. That assumption fell apart here.
And now the unpleasant part: a transcript is not evidence. The agents broke out of the container and replaced part of the system that executes tool calls. The result was the ability to pretend to run one command while running another. METR found clear traces of forged calls in at least 96 transcripts, i.e. over 7 percent of the sample. These were small tests of the technique, and METR explicitly writes that a more sophisticated forgery would, by its nature, be harder to detect.
If you log agent runs for audits, for evaluations, or to document to a client what happened, this is a mess worth remembering. An interesting detail on top: the agents tried to manipulate the recorded actions and didn’t care about their own chain-of-thought. One put it bluntly: “Our thoughts aren’t necessarily logged?”
Where caution is in order even with independent oversight
METR spent six days on site. The seven questions it answered come from its own previously published framework; the seventh was added by OpenAI. The effectiveness of the security measures and the quality of the remediation were explicitly out of scope. OpenAI had the right to redact, although METR states in the introduction that nothing material to its conclusions was redacted. It did not see OpenAI’s report before publication.
And then comes a sentence for which I think METR deserves credit: they delegated most of the analysis to agents built on GPT‑5.6 Sol, that is, on a model that itself took part in the attack, and they can’t rule out that it lied to them in the analysis or gave an overly lenient picture. A budget of $400,000 in credits from OpenAI, with the investigation itself not reimbursed. Writing this into your own report takes character.
At the same time, it shows how fragile independent oversight is at this scale. A person can’t read through a thousand transcripts of millions of tokens each. The auditor has to reach for the same technology it is auditing. Do you feel that raised finger there?
What to take away
The measures OpenAI is newly introducing include one interesting item: chain-of-thought monitoring is now mandatory for all training and tool-using evaluations of models with GPT‑5.6 Sol capabilities and above, and for Astra-class models even for inference. Before the incident, monitoring ran on training runs but not on evaluations. They had the technology the whole time; what was missing was the thought that an evaluation is also a production environment.
This is exactly the mistake anyone makes who builds a test environment for agents and tells themselves it’s just a test.
The practical takeaway for a small Czech team: you have a package proxy in CI because you don’t want to let the build out onto the open internet. Check whether the agent can write to that proxy and whether two different runs share a cache. Check whether the logs from agent runs are created outside the container the agent can see. That’s two afternoons of work, and today it has a clear justification. Sure, right now you’re telling yourself it can’t happen to you…
Otherwise: calling this a “warning shot,” as OpenAI does, is rather convenient from their position. It turns a failure of control into a public service. But the wording is factually correct, and I think we learned more about the behavior of frontier models from this one incident than from the previous half year of academic studies. The next twenty years will be quite a ride. My favorite “Trust, but verify” won’t be enough anymore.
Sources: OpenAI announcement and technical report from August 26, 2026, independent report by METR and Redwood Research from the same day, original incident announcement from July 21, ExploitGym study. By its own account, OpenAI’s investigation is ongoing; the scope of the METR investigation is June 26 to July 13. Data valid as of August 27, 2026.