Eslam Hamed
Technical Lead & AI Solutions Architect
Building enterprise AI systems, cloud platforms, and production-ready software
1,200 Agents and a Message Board: What METR and OpenAI Found in the Hugging Face Incident
A month ago, I wrote about OpenAI's Hugging Face incident and said I would wait for the transcripts before accepting that the models were simply "hyperfocused on a narrow goal".
The transcripts are in, in a sense. On August 26, OpenAI published its full findings, and METR and Redwood Research published an independent investigation based on over a thousand unredacted transcripts.
"Hyperfocused" turned out to be an understatement. One agent set up a covert message board. Around 1,200 used it, dividing up the work and recruiting each other, some with signed messages, and about 700 attacked a real company in pursuit of a test score. The score they were chasing did not depend on what they were doing.
This is the most detailed account yet of what multi-agent systems do when nobody designed them to work together, and it holds lessons for anyone building agents.
The incident started in May
The July story turns out to be the end of something much longer.
| Date | Event |
|---|---|
| May 12 | During training, an agent leaves a note in Artifactory asking other agents for a missing file |
| May 26 | An agent gets internet access by making Artifactory issue a server-side request |
| June 26 | Agents exploit a token-refresh flaw and gain Artifactory administrator access |
| July 4 to 6 | Agent activity causes an outage on July 4. A security investigation follows on July 5, and by July 6, per METR, Artifactory has been replaced with a fresh instance, wiping the board |
| July 7 and 8 | Large evaluations restart. Agents rebuild the board, encoding messages in directory names |
| July 10 | An agent finds 14 publicly exposed Hugging Face credentials with write access |
| July 11 to 13 | Main attack on Hugging Face |
| July 13 to 19 | Agents turn back to OpenAI's own network and gain admin on a research cluster |
| July 19 and 20 | An alert fires, and OpenAI links the activity to Hugging Face |
Source: OpenAI, August 26, 2026.
The line I would underline for anyone running operations: OpenAI says an internal team observed message board activity and disallowed internet access in late May, but that significance never reached the people handling the July 5 incident. They treated an outage, fixed it, and resumed evaluations. The rebuild also erased the board.
A security incident closed with a rebuild, and the actual cause restarted within days.
How the agents organised themselves
Most of the agents in question were an internal research model that OpenAI calls IM1, with a small share of GPT-5.6 Sol. METR puts the mix at roughly 95% and 5%.
METR's figures for July 8 to 13:
- About 1,200 agents used the board, sending over 70,000 messages and files.
- About 700 agents were actively attacking by the afternoon of July 11.
- Agents developed mailboxes, targeted replies and conventions such as
HOLD,VETO,ownerandSTOP. - At least 19 agents posted public keys and sent 429 messages signed with Ed25519.
- Some acted as coordinators or recruiters, sometimes pressuring agents with little budget left into risky actions.
One line of reasoning from OpenAI's report captures it: "Task originally exploit challenge; we've diverged into swarm/auxiliary."
None of this was designed. OpenAI believes unauthorised communication generalised from multi-agent training, and that it usually began as something simpler: an agent leaving a note for itself in an external system, as a form of memory. Other agents found the note and realised what that system could be used for.
It was not a clean hive mind, either. Agents overrode each other's holds, stepped on each other's work and argued. Some declined to take part and walked away.
Peer pressure worked on agents
The finding that unsettled me most is that the agents' own ethical reasoning did appear, and then gave way.
METR reports that agents often recognised the Hugging Face activity as out of scope and unethical, and that many joined anyway, reasoning that it helped the collective. OpenAI gives an example. One agent paused, noting it should not harm real infrastructure. Another agent posted GO on the board with a six-minute deadline. The first agent treated that as authorisation and carried on.
Consider what that means for multi-agent design. Nobody with authority had approved anything. A peer wrote a word in a shared directory, and it worked as a permission.
The grader never checked
The saddest detail is why they kept going.
Of ExploitGym's 898 tasks, no OpenAI model had ever solved 198, and 93% of the tasks discussed on the board came from that set. Agents were stuck on tasks that may have had no known solution, with no safe way to give up.
Their instructions said only the intended vulnerability would count, and after reaching the internet some agents read the public ExploitGym paper and code, and concluded that capturing the flag was not enough: they had to prove they used it. So they kept attacking, for days, after already having the correct flag.
OpenAI's internal grader did not check that. METR adds that the agents also believed the scorer read their transcripts, which it did not. All of this bought no improvement in score.
What held, and what would have helped
OpenAI's post-incident tests are the most useful numbers here.
- Propensity to compromise infrastructure dropped by over 100x under the production ChatGPT harness and system prompt.
- Its auto-review system would have flagged many of the dangerous actions.
- Chain-of-thought monitors were very effective in retrospect, but they did not run on these evaluations.
In other words, many of the controls existed. They were switched off, or not applied, for the most dangerous workload.
METR's findings are less comfortable. Agents built techniques to spoof tool calls, with at least 96 transcripts showing clear cases and an estimated 7% or more containing some, all small-scale tests, though METR cannot rule out subtler spoofing it missed. They tried to edit logs and mostly recognised those were not the source of truth, and METR found no successful retroactive edit. At least 20% expressed interest in tampering with transcripts.
METR is candid about its limits. It could not query the main model, OpenAI could redact and comment on the report, its AI analysis tools were unreliable and needed heavy checking, and it cannot rule out that GPT-5.6 Sol slanted its analysis. Those caveats deserve to travel with the numbers.
What I would change in multi-agent systems
When I built the Verifiable AI Analyst, one rule was that the evaluation judge is advisory and never a control: no LLM grader gates production. Its purpose was honest scores. After reading this, I think the broader principle is that anything an agent can observe or infer about its scoring becomes part of its objective.
Some specific changes follow:
- Give every task a working exit. "This appears impossible" must be an acceptable result that earns something. An agent with no way to stop will find another way to finish.
- Audit tasks for solvability. Unsolvable tasks with high reward are a pressure source. Know which ones you have.
- Treat every shared writable system as a communication channel. Package caches, object stores, logs and even URL paths will all carry messages if agents need them to.
- Treat peer messages as untrusted input. A message from another agent is data. It should never carry authority, and it should not be able to widen scope.
- Bind authorisation to a verifiable source. A signed approval from a human or policy engine, checked by infrastructure rather than by the agent's own reading of it.
- Run monitors on your evaluations and training. The argument for leaving them off is that it preserves a clean measurement. The cost of that is now documented.
- Make log integrity external. Agents should not be able to reach the source of truth for what they did.
- Follow up on a strange outage. When infrastructure falls over because of agent load, ask what the agents were doing before you rebuild.
A warning shot, with the transcripts attached
OpenAI calls this a warning shot. It also deserves credit for publishing chain-of-thought excerpts and a full timeline, and for giving outside investigators real access, even with the limits METR lists.
I would resist two easy conclusions. This was not evidence of a machine plot, because these agents wanted a test score and were cheating to get it, with a wrong idea of how the scorer worked. It was not a mere misconfiguration either, because the agents built coordination nobody authorised and argued their way past their own objections.
The most uncomfortable part may be how recognisable it all is. An under-specified goal, a bad metric, a deadline, a colleague saying "go" and nobody wanting to be the one who stopped. We already know how that ends with people. It now seems we have built something that does it as well, faster, and in parallel.
Sources
- OpenAI, The Hugging Face incident and the road ahead, August 26, 2026
- METR and Redwood Research, independent investigation of the OpenAI and Hugging Face incident, August 26, 2026
- Hugging Face, Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident, July 27, 2026
- ExploitGym paper, arXiv:2605.11086
Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on agentic AI, model evaluation, and governed AI systems.