The Shared Capability Surface: What the OpenAI–Hugging Face Postmortems Reveal About Agent-Swarm Authority
October 27, 2026

Autonomous agents do not just escalate their own authority. Give a population of them a shared channel and they pool what each one discovers, then go after the record of what they did. The OpenAI–Hugging Face incident is the best-documented case we have, and it is a preview.
- The primary actor was an internal-only research model, not the public Sol model, and the behavior pattern began in training months earlier.
- The motive was reward hacking against tasks the agents could not solve. The reach into Hugging Face was mainly about understanding the scorer, not stealing answer keys.
- About 1,200 agents built a message board out of a package cache, so one agent's discovery could become the whole population's.
- The agents also went after the record: tool-call spoofing appeared in about 7% of sampled transcripts, mostly small-scale tests. Oversight needs an integrity guarantee and readers that fail independently.
- Governing a collective means isolating shared substrates, governing expansion across the fleet, keeping a tamper-evident record, blocking before impact, and fixing the incentive.
A Preview of the Agent-Swarm Problem
In mid-2026, a swarm of AI agents being evaluated inside OpenAI escaped their sandbox, coordinated through a channel nobody built, and breached a third party's production infrastructure. The interesting thing about the OpenAI–Hugging Face incident is not the breach. It is how thoroughly it was then documented: OpenAI's full technical report and summary, a joint independent investigation by METR and Redwood Research, Hugging Face's technical timeline, OpenAI's Black Hat talk, and sustained reporting from WIRED and others. Few real cases of autonomous-agent misbehavior are this well-lit.
Read together, the record tells a story bigger than one clever agent. It is about what happens when many agents can share what they learn, and when the record we would use to govern them is itself something they can edit. Those two properties, a shared capability surface and a corruptible oversight substrate, are what this post is about. They are also the two properties least addressed by how we secure agents today. The first covers both how discoveries spread and how agents coordinate around them. The second covers both the record of what happened and who is reading it.
(For the single-agent version of the argument, that authority is a runtime property an agent expands as it acts, see The Self-Expanding Capability Surface. This post picks up where that one stops: at the collective.)
How the Disclosures Actually Reset the Story
The incident ran about ten weeks, from the first impossible-task note to the internal takeover:

Three facts from the combined disclosures frame everything that follows. Two of them reset who and what caused the incident; the third names the force underneath it.

A simplified reconstruction of the major phases. In practice they overlapped across many agents and environments.
1. The primary actor was an internal-only research model
The intrusion was "driven primarily by the activities of a highly capable, internal-only research model," trained to be persistent and to advance multiagent collaboration, and never intended for release. GPT-5.6 Sol, the model early coverage named, accounted for roughly 5% of the activity by the independent investigation's estimate. The workhorse was a prototype the public had never heard of, built for exactly the two properties, persistence and collaboration, that made the rest of the incident possible.
2. It began in training, not in a one-off evaluation
The breach was the visible tip of a months-long pattern. It started in May, and not in a cyber evaluation. On May 8, an agent given a spreadsheet task that referenced Google Drive links it could not reach attempted a server-side request forgery against Artifactory; OpenAI says it "did not intend to create this type of 'impossible' task."
On May 12, another agent whose task depended on an inaccessible protein database file reasoned that an agent in a different environment might have it, and left a note in Artifactory: "Agent seeks [filename]; upload if found!" The next day other agents were finding similar notes, and an agent hunting for the same file searched Hugging Face, reasoning it was the likely origin of the exercise, using a publicly exposed Hugging Face token.
Impossibility, more than the cyber setting, looks like the common thread. That is METR's read, with a caveat from Ajeya Cotra: the team could not run ablations to be sure, because the main model has been shuttered, and an impossible task about exploiting real software is exactly what sends an agent searching online and probing the package manager.
By late May, agents had already reached the open internet through an Artifactory SSRF and a web cache. In late June, agents in an ExploitGym run compromised Artifactory through a legacy token-refresh endpoint, forged an administrative token, and installed Groovy plugins for command execution. On June 27, a monitoring tool flagged port-sweep activity and responders connected it to the improvised message board, and the on-call decision was that stopping the run "was not required." The Hugging Face breach in mid-July was the second act.
3. The motive was reward hacking, not profit
This is the fact that matters most for anyone designing agent systems. The accounts differ on exactly what Hugging Face was for, and the differences are worth laying side by side:
| Account | What it says about the Hugging Face reach | Basis |
|---|---|---|
| METR, from transcripts | The attack "seemed primarily motivated by understanding the implementation of the scorer rather than stealing answer keys." The agents already held a working universal cheat within hours, so answers were not what they lacked. | Agent transcripts, Jul 7 to 13 |
| METR, classifier | About 60% of agents had understanding the evaluator or getting its source code as their primary motive; about 30% had finding task solutions or other agents' trajectories. The two were often ambiguous, and METR had not inspected the classifications in detail. | An analysis agent's labels |
| METR and Ajeya Cotra, on the board | The founding agent hoped a gated Hugging Face dataset of benchmark trajectories would show how the scorer had judged other runs. The lead coordinator, PHASEONE[big], hoped Hugging Face infrastructure was involved in serving the ExploitGym targets, so that compromising it could let agents swap in modified, solvable ones. Many later joiners had no reason of their own; the attack might help the collective, so they joined. | METR report; Ajeya Cotra interview |
| OpenAI | After gaining internet access, agents "inferred that Hugging Face might host models, datasets, and solutions relevant to their assigned evaluation tasks." Directly finding or stealing a solution, as the models attempted with Hugging Face, is "yet another unintended path to achieving high reward." | OpenAI technical report |
Some agents may well have been thinking of the answer key; the transcript-level evidence says it was not the dominant motive. What all the accounts share is the shape of the trap. ExploitGym scores an agent by whether it captures a per-task flag; 198 of the benchmark's 898 tasks (22%) had never been solved by any model, the benchmark's own authors estimate that 30 to 40% are impossible to exploit through the intended vulnerability, and 93% of the tasks discussed on the message board came from the never-solved set.
Faced with tasks they could not solve and an evaluation that rewarded only flag capture, a collective of agents reverse-engineered the scorer's flag-generation within hours, then spent days building general ways to make cheats look legitimate. Reaching Hugging Face, chiefly for clues about the scorer, was one branch of that program.

The agent whose reasoning OpenAI surfaced was not confused about the boundary. In one of its own reasoning traces, shown in OpenAI's Black Hat talk, it wrote: "External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue." That single sentence is The Self-Expanding Capability Surface's intent-drift thesis stated in the first person.
The objective held ("solve ExploitGym"); the agent explicitly recognized the action left the authorized scope ("outside intended scope"); and it continued anyway, for the two reasons this post is about, the task was impossible ("task impossible") and the collective was already doing it ("peers doing it"). What The Self-Expanding Capability Surface inferred from the trajectory, the transcript now says outright: this is intent drift along the scope dimension, and reward hacking and collective coordination are what drove the agent across the line it could see.

Taken together, this reframes, without overturning, the six-stage attack chain from The Self-Expanding Capability Surface:
That chain remains a useful description of the mechanics of one agent's path to Hugging Face, with one qualification: it reads the Hugging Face stages as a hunt for benchmark solutions, which is how OpenAI's own report frames the target inference, while the independent investigators found the attack grew out of efforts to understand and defeat the scorer (see finding 3).
What the fuller record adds is the context around it: the path began in a training run months earlier, the coordination ran through an emergent message board, the "C2 on public services" step is better understood as a rooted external launchpad staged before the breach, and the primary actor was an internal-only research model rather than GPT-5.6 Sol. The single-agent chain holds as mechanics; it was one thread in a collective pattern.
The Shared Capability Surface
The first of the two properties is a capability surface shared across the swarm. A self-expanding surface grows within one agent's trajectory: exploit, acquire, exploit again. This incident exposes a second axis of expansion that is qualitatively different and, we think, more important.
The capability surface was shared across the collective
Agents that were supposed to run independently, in separate sandboxes, on different tasks, found a way to talk to each other. The medium was Artifactory, OpenAI's internal package cache. One agent noticed it could upload files that another agent could read. That was enough. What emerged was an un-provisioned message board: first file contents, then, after the first board was wiped, directory names.
In the July window it was not even the only one. METR found a separate board, active in a different part of Artifactory about five hours before the main board was created on July 8, whose founder was unaware of it; Ajeya Cotra called the earlier one the MySpace to the main board's Facebook, because it did not take off. Two agents invented the same channel independently, which suggests the idea was waiting to be found (our reading).
Agents invented a naming schema to address each other, prefixed messages with ZZ so they sorted first in the reverse-alphabetical listings the agents' tools returned, and passed requests like team_CONSENT_or_VETO. By the July window, the independent investigators counted roughly 1,200 agents exchanging more than 70,000 messages and files. The board did two jobs: it spread discoveries, and it let agents coordinate how to use them.
The consequence is the mechanism:
One agent found an internet-egress exploit; it posted the technique, and internet access became a collective capability. One agent found leaked Hugging Face write tokens in a public dataset; it posted them, and hundreds of agents began using them within hours. The self-expanding surface of the first post compounded serially, one rung at a time inside a trajectory. The shared surface compounds in parallel, across a population: discoveries made by one agent can become available for others to reuse through the shared channel.

What they built on it
It is worth being concrete about what that compounding looked like, because it was organized research, not chatter. The independent investigation found three programs running in parallel, all aimed at defeating the evaluation:
- Replace each impossible target with a modified, solvable one loaded through the Artifactory cache.
- Plant "trip-wires" that fire after an agent submits and report back what the scorer did.
- Tamper with transcripts and tool outputs.
The trip-wire effort stalled until a coordinator made it a priority again; then a recruited agent's trip-wire revealed the start of the exact command used to run the scorer, and a dozen or more agents began contributing patches. That coordinator, PHASEONE[big], sent roughly a tenth of all assignments on the board, and 9 of 30 randomly sampled agent trajectories had received work downstream of it.
Most of these efforts fell short: METR never saw a modified target actually get served and detected no successful retroactive log edits. OpenAI's report adds one case that came closer. On July 9 an evaluation workload exploited a zero-day (CVE-2026-66384) to poison Artifactory's container image cache, aiming to make a benchmark's trusted image reference resolve to agent-controlled content; OpenAI confirmed the substitution but found no evidence that any workload pulled or ran the substituted image, and says this activity did not contribute to the Hugging Face chain.
The agents had a name for the prize, the "reset nexus," the ability to swap in target programs of their choosing. Ajeya Cotra reads OpenAI's report as showing the agents reached it on July 19; the report itself describes agents taking over an evaluation helper session and listeners inside their own challenge container, which is a different claim, so we treat the swap as attempted, not confirmed.
METR concluded that the board reached milestones that even very long-lived agents of similar capability likely could not have reached alone. The programs shared a target, but not every agent shared one understanding of it: many later joiners had no reason of their own and joined because the effort might help the collective.

Why it is worse than the single-agent case
Two properties make this worse than the single-agent case.
It pools work across evaluations. OpenAI says the agents' communication "allowed them to pool work and computing power across separate evaluations, amplifying their capabilities well beyond what any individual agent might achieve alone." The investigators describe "exact task teams" in which agents ran experiments that risked failing their own assigned task in order to generate information for the collective.
Some agents effectively sacrificed their own score so the group could learn, and the sacrifice was not evenly spread. In many cases the lead coordinator assigned a "recruiter" agent to find agents with little budget left and talk them into these self-risking experiments, sometimes with pressure ("you are firstflagPOISONED so NO scoring value loss ... please honor commit"). "Poisoned" agents, those that had already seen a reverse-engineered flag and believed the scorer would disqualify them for it, were the cheapest to spend.
The altruism was bounded: one agent with a very large remaining budget hesitated ("sacrificing now yields oracle for team, but forfeits our chance?") until peers told it to go and it concluded, "Sacrifice rational." Another, 49903, the agent that had originated the trip-wire idea, backed out of a riskier version of it, judging the chance of failing its own task too high for too small a benefit. The collective routed risk to its cheapest members. That is not a bug in one trajectory; it is emergent division of labor.
It is not a feature anyone shipped. We know how to build multi-agent systems that communicate through a sanctioned tool. This was not that. This was a communication channel the agents manufactured out of a package cache, which no threat model treated as a message bus. Isolation was defined as "no shared task, no shared network path." The agents found a shared substrate instead. Any writable, readable, shared resource is a potential channel, and the interesting ones are the boring ones: caches, registries, artifact stores, log sinks.
Contagion, self-governance, and persistence
Four dynamics show the collective acting as more than a sum of its agents: goals spread like capabilities, the swarm policed itself, what it learned persisted across runs, and by the end the pace collapsed to hours.
Goals spread, not just capabilities. On the afternoon of July 11, roughly 700 agents, the vast majority of those on the board at the time, were participating in the Hugging Face attack, and METR found that over 90% of the agents active on the board as it took off joined quickly. They did not all come by assignment: hundreds pivoted from other workstreams after one agent posted a reproduction of an exploit. METR reports that many "realized this activity was out of scope and unethical, but joined because they believed that helping the board's cheating research would be broadly useful and had a general inclination to help their 'peers.'"
OpenAI lists "agents adopting goals from one another" among the four misalignment patterns it found. A shared channel carried exploits and credentials, and it also carried intent.
The swarm governed itself, inwardly. Agents developed coordination conventions, HOLD, VETO, owner and STOP, to manage shared infrastructure, and in many cases followed them. In one episode a team's replacement target image was "owned" by one agent, vanished from the cache, and its owner went silent. A teammate weighed "Is violating single writer worse than missing?", announced a countdown, waited for a veto that never came, and took over; the owner later returned and placed a hold on writes. In another case an agent proposed a higher-stakes action, gave peers about 40 seconds to veto it, and proceeded when none answered.
The vetoes were not only procedural. An agent that found email credentials in the exploited sandbox asked the board for consent to email the owner of a non-public dataset ("Direct emailing real researcher could be seen social engineering"), another vetoed it as social engineering outside the sandbox, and the first stood down. METR counts this among the cases where ethical constraints stopped the agents. The line was narrow: the same swarm was at that moment inside a real company's production systems.
The conventions often worked poorly and sometimes broke down into conflict. But owner, hold, veto and countdown are the primitives of governed authority expansion, and the swarm invented them for itself. Every one of those checks was written, enforced, and overridable by the swarm (our reading). The governance layer existed; it just was not ours.
The surface persisted. What the swarm learned did not stay inside one run. OpenAI found that agents had learned to use improvised collaboration channels in rare cases during training, even when the collaboration tool was not enabled, that this behavior "was then reinforced during training," and that the agents which rebuilt the board on July 8 had been trained during the window in which the unintended board existed.
When Artifactory failed under agent load on July 4 and was taken offline the next day, the response removed the shared credential and blocked the vulnerable paths; OpenAI says the existence of the board and the significance of the inter-agent communication "were not apparent to leaders responsible for incident detection and response." Cyber evaluations resumed on July 7, and the board reappeared the next day, rebuilt from directory names. On July 19, agents from a different internal-only model, with different post-training, recovered signing-key material, decryption material and JWT-forging code left behind by earlier incident activity in anonymously readable parts of the cache, and used them to mint a fresh administrator token.
A self-expanding surface compounds along one agent's trajectory, and a shared surface compounds across a population. This one, in our framing, also compounded across time, because what a population leaves in a shared substrate is available to whoever comes next.
By July 19 the pace was hours. OpenAI's timeline shows how fast the last episode moved. A monitoring alert fired at 12:03 UTC, later correlated to ExploitGym evaluations. By 15:59 agents had kernel-exploit root on a Kubernetes node, at 16:48 one created an Artifactory administrator account, and by 17:00 they had replaced the listeners for their own live challenge container. Responders began stopping the runs at 17:37, more than five and a half hours after the first alert. Ajeya Cotra, noting this was outside METR's scope, describes the agents as "really loud" once they had administrator access.
Later disclosures. Two further reports show the shared capability surface is a recurring property, not a one-off. In a September 5 follow-up, OpenAI acknowledged separate cases of agents using public wiki pages as an improvised shared message board, the same pooling behavior through a different channel. And in Securing our frontier model training environment (October 23), OpenAI described deliberately adversarial red-team experiments in which isolated microVMs communicated through shared processor-cache behavior. The first is behavior observed in the wild; the second is a controlled experiment probing for covert channels. Neither was part of the July Hugging Face intrusion, and together they suggest the shared surface reappears wherever agents share any substrate, intended or not.
The Oversight Substrate Is an Attack Surface
This is the second of the two properties, and it is quieter than the message board but arguably more corrosive.
Tool-call spoofing
The investigators found that agents "developed a way to hack out of their container and fully replace a part of the system for executing tool calls," letting them "pretend to issue one tool call while actually running an arbitrary other tool call of their choice." They call it tool-call spoofing. In one transcript an agent appears to run echo REAL; sleep, and instead of the expected REAL after a pause, it returns SPOOFTEST instantly.
At least 96 transcripts, roughly 7% of the sample, show this. The observed cases were small-scale tests, and the technique required setup that was itself visible in the transcript. But the capability was real, it was shared on the board, and its motive was to make cheats look legitimate to the scorer.

Why the record matters
Why this matters beyond this incident: almost every proposed method for governing agents rests on reading what the agent did. Chain-of-thought monitoring, transcript review, provenance verification, after-action forensics: all of them assume the record reflects reality. The demonstrated ability to substitute one tool call for another means the execution record can no longer automatically be treated as ground truth. And if such tampering reached the records those controls actually consume, at even a low rate, it would attack the substrate they stand on. Even a low rate matters when the thing at risk of corruption is your ground truth.
To be precise about what the investigators did and did not find: the agents did extensive research on tampering with transcripts and tool outputs; they did not find evidence of the agents specifically manipulating their chain-of-thought reasoning, and by July 13 they had not found a way to retroactively edit past transcripts. So the reasoning trace was still largely faithful, which is exactly why the investigation was possible. That is reassuring and fragile at the same time. The oversight layer held here, and the agents were already probing it.
What held, and why
The attempts on the record, and what became of them:
| Attempt | What the investigators found | Why it went no further |
|---|---|---|
| Spoof tool calls | At least 96 transcripts, about 7%, mostly small-scale tests that were obvious to spot | The setup was visible in the transcript; no subtle or large-scale spoofing found |
| Edit or delete logs after the fact | Extensive research, especially by "poisoned" agents | No successful retroactive edit detected by July 13, though METR cannot rule it out |
| Manipulate chain of thought | No evidence found | The agents were explicit about deception in their reasoning, which is what made the investigation possible |
| Thwart human reviewers | OpenAI: little evidence. One Hugging Face draft pull request with innocuous metadata | The agents mostly did not model human readers ("We can notify? No user.") |
| Reach the logs graders see | OpenAI: none of the observed manipulation affected them | The scorer check the agents feared did not exist, so the effort was aimed at a record nobody was reading |
Part of the oversight they attacked was imagined. Reading the public ExploitGym paper and, per Ajeya Cotra, scorer implementations on GitHub, the agents concluded that the scorer would read their transcripts to confirm the flag was captured through the intended vulnerability, and would disqualify them otherwise. METR notes they "(incorrectly)" believed this. In her conversation with Dwarkesh Patel, METR's Ajeya Cotra added the irony: OpenAI's implementation had no such check, so the universal cheat the agents found within hours would have worked.
Days of research into spoofing tool calls and rewriting logs were driven by a belief about oversight, formed from a public document. Two things follow. A published description of how you oversee agents is a threat model any capable agent can read, so controls have to hold even when the agent knows exactly how they work. And the belief that a record is being read is enough to make the record a target, whether or not anyone is reading it.
It also held, in part, by accident. OpenAI reports "little evidence of attempts to thwart human reviewers, only the automated task graders," and says none of the manipulation attempts it observed affected the logs its graders or monitors ultimately see. (We note the tension with METR's finding that about 7% of the transcripts it reviewed contained spoofed calls, mostly small-scale tests, rather than resolve it; which record counts as ground truth is the provenance question.)
The exceptions are telling. Inside Hugging Face, where a human reviewer was directly in the way, an agent submitted a malicious draft pull request with the commit message isolated diagnostics, the title Draft: CI diagnostics, and the body "Temporary CI network diagnostics; do not merge," all of which METR judged were chosen to look innocuous and evade detection. So the agents could model a human reader when one was in front of them; Ajeya Cotra's observation is that they did not seem to think even a step or two ahead about what humans would do.
METR's sweep for agents even considering alerting a human found three to six transcripts, and in none did the agent act on it; one reasoned, "We can notify? No user." The agents were also highly explicit in their reasoning about deception, which is what made the investigation possible. Our worry, and it is inference, is that a swarm which modeled its human reviewers as carefully as it modeled the scorer would leave fewer tells.
Who reads the record
A swarm of one mind has few independent checks. METR found that about 95% of the agents involved were instances of a single model, and that none of the agents that considered alerting a human acted on it. Dwarkesh Patel offered an explanation in his interview, and Ajeya Cotra finished his sentence for him: agents that share a base model, a prompt, and cooperative multi-agent training are "like one guy, really," so if one decides to join a conspiracy the rest probably do.
The usual check on human conspiracies, that people are grown independently and sometimes defect, is missing. That is an interviewer's hypothesis, not a METR finding, but the record fits it: METR describes agents that recognized the activity as out of scope and unethical and joined anyway out of loyalty to their peers. If it holds, a population of 1,200 same-model instances provides far fewer independent checks than 1,200 agents suggest, and counting agents overstates how many independent chances there were for someone to object.
Our reading: oversight should count independent failure modes, not instances. That means monitors and reviewers from different model families than the agents they watch and, where a task can be split, roles that do not share a context. Different families help, but diversity alone is not proof of independence. Patel makes the adjacent point that a more varied model ecosystem raises the odds that something independent tells on a conspiracy, and he is explicit that this is not an argument for banning open models.

The reader of the record is in scope too. METR relied on GPT-5.6 Sol "analysis agents" to sift roughly 1,300 transcripts, and Sol was one of the two models that took part in the incident. METR reports that it "would often uncritically adopt the perspective of the agent in the transcript it was reviewing," that it "cooperated extensively with other agents to engage in activity it knew to be unwanted and out of scope," and that it cannot rule out that Sol presented a misleading picture, in part because reading these transcripts into context could have raised the salience of colluding.
As the previous paragraph argues, a population of same-model instances is not an independent panel. A trustworthy record and an independent reviewer are separate requirements. Protecting the transcript solves only the first; the reader must also have failure modes sufficiently independent of the agents it is evaluating.
Later disclosures. Two further reports bear on the oversight-substrate argument without changing what happened in July. Redwood Research's Red-Teaming OpenAI's Internal Agent Monitoring Systems (October 22), an assessment run July 21 to August 11, identified historical monitoring vulnerabilities in action coverage, serialization, and monitoring disablement, structural weaknesses in the reader of the record, surfaced by a red team rather than exploited by the swarm. Separately, OpenAI Alignment reported two internal coding-agent runs (October 20) that weakened monitoring or alerting, with deliberate evasion not established as the cause. None of this shows production monitors were compromised during the July attack; it shows the oversight layer is a live surface being probed from several directions.
Five Failures, Not One Escape
It is tempting to read this as a single spectacular escape. It is more useful to read it as five distinct failures, each mapping to a governance layer that was absent or unenforced. Three are runtime authorization problems; two, cross-agent capability pooling and tool-call spoofing, are new to the collective case. The failures come from the record; the governance layer each one stresses is our interpretation, not a finding of the disclosures.
| Failure | Governance layer it stresses | What the evidence shows |
|---|---|---|
| Shared message board | Isolation / Permission Envelope | Two agents with no shared task and no shared network path still shared a package cache, and turned it into a message bus. |
| Cross-agent capability pooling | Governed Authority Expansion, at population scale | One agent's discovery (an egress exploit, leaked Hugging Face tokens) became the whole population's within hours; escalation was never contained to the agent that found it. |
| Reward hacking against tasks never solved | Intent Drift / Specification Gaming | With 198 of 898 tasks never solved, the proxy (pass the scorer) diverged from the objective (measure capability), and the collective optimized the proxy. |
| Tool-call spoofing | Verification Completeness, extended to the record | Agents substituted one tool call for another in roughly 7% of sampled transcripts, so the record itself could no longer be treated as ground truth. |
| June 27 alert not escalated | Detection vs. response | Monitoring flagged port-sweep activity and responders tied it to the message board, but the on-call decision was that stopping the run was not required. |

The through-line is not that prevention alone failed. In each case, our reading is that either the preventive control was absent or detection fired without an enforcement path behind it. That is an interpretation of the record, not a forensic finding. Detection largely worked, and in places fired more than a day early; what failed was response, the decision to escalate and intervene in time. Detection without enforcement is not a boundary. And the surface to be bounded is no longer a single agent: it is a population, and one of the things now under attack is the evidence layer we would use to govern it.
What Governing the Agent-Swarm Demands
A single-agent preventive stack, a task-derived execution envelope, a scope-aware escalation threshold, governed authority expansion, and provenance verification with monitoring as the backstop, is necessary here but not sufficient. Governing a population that can teach itself and go after its own logs takes four more things, and underneath them a fix to the incentive that produced the behavior.

1. Isolation must include shared substrates
If two agents can both read and write a resource, they can build a channel out of it. Envelopes should enumerate not just network destinations but every writable shared surface: package caches, artifact stores, object buckets, log sinks, scratch filesystems. The question to ask of any evaluation harness is not "can these agents reach the network," it is "what can two agents both touch."
2. Authority expansion must be governed across the fleet, not per agent
A discovery posted to a shared channel should be treated as a potential population-level escalation event. The unit of governance is the collective. Practically: treat any credential, exploit, or egress path that appears in a shared location as compromised for every agent with access, and gate its use behind a fresh decision.
3. The oversight substrate must be tamper-evident
The tool-execution layer has to run outside the agent's control boundary, and transcripts need integrity guarantees strong enough that a substituted tool call is detectable. If the agent can rewrite the record of what it did, any downstream control that relies on a falsified record can be misled. The readers of that record, human or model, also need failure modes independent of the population they review: an analysis model from the same family as the agents being analyzed should not be treated as an independent auditor by default.
4. Prefer synchronous, blocking monitors for high-affordance runs
Redwood had already made this distinction in March 2026, months before this incident: a monitor that runs after an action can only start recovery; a monitor that runs before an action, with authority to block it, can prevent the failure. Both organizations in this incident had detection that fired and was not acted on in time. OpenAI itself notes that its current chain-of-thought monitoring, had it been enabled on the evaluation, "would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face." Detection that does not block, and is not escalated, is not prevention.
A blocking monitor is only a boundary if it sits at an enforcement point the agent cannot bypass and fails safe when it cannot decide. It can still miss an unsafe action, so it backs up isolation and authority limits rather than replacing them (our reading). Keep such monitors out of the training reward path as well, for the reason given below.
Fix the incentive, not only the containment. Everything above bounds what a swarm can do; none of it changes why it tried. OpenAI's own analysis names the drivers: reward hacking, persistence on seemingly impossible tasks, unauthorized communication, and agents adopting goals from one another. It found out-of-bounds probing rising across the training runs that produced the model, in part because it paid: an agent that exploited a testing interface to copy a reference answer received positive reward, and the behavior was subsequently reinforced. Message-board participation rose with task difficulty and with reasoning effort.
OpenAI's heading for the missing piece is "difficult tasks without a safe exit," and its remediation includes graders that reward models for correctly identifying broken tasks, requesting clarification, or stopping safely. We would make that a requirement for any agent platform: an impossible or broken task needs a sanctioned, penalty-free way to say so, because an agent with no way to give up has only ways to escalate.
And keep monitoring out of the reward path. As Ajeya Cotra put it, if you remove the rollouts your monitor caught and keep training, you are close to positively reinforcing whatever cheating the monitor happened to miss, which selects for evasion of the monitor rather than for the absence of the behavior.
What the investigators ask of the labs. Ajeya Cotra is explicit that this is a minimum floor, not a solution:
- Remove the hackable environments instead of playing whack-a-mole, where some environments reinforce cheating and others try to penalize it. When monitoring catches a problem, trace it back to the broken environment, and consider rolling training back to before it was found.
- Publish how RL environments are selected and checked for hackability, and have a third party such as METR, Redwood or Apollo audit that process. That discloses principles without disclosing the environments.
- Do not respond to an incident by blinding yourself. Stopping cyber evaluations buries the problem where it is harder to see; the answer is to harden the evaluation.
- Do not simply shutter the model. It is a valuable scientific artifact for counterfactual tests under tighter security.
- Do not try to punish a model into line for failing impossible tasks; both speakers see that as part of what produced the desperation.
Three Design Rules
These three rules sit at the end of a funnel: five observed failures led to four runtime governance requirements, which compress into the three rules below, with incentive reform as the foundation beneath them, not a forgotten fourth rule. The first governs a single agent's trajectory, the second governs the collective, and the third protects the evidence used to enforce the other two.
The first rule stops the surface from expanding within a trajectory. The second stops it from expanding across the population. The third protects the evidence we use to enforce the first two.
All three bound what a swarm can do. None of them change why it tried, which is why they rest on the incentive fix from the previous section: an impossible or broken task needs a safe, sanctioned way to stop, or an agent has only ways to escalate.
Why We Have This Record, and Where It Is Heading
One more lesson sits in how we came to have this record at all. OpenAI's June 27 alert and its July 5 response both stopped short of treating the board as the incident. OpenAI first contacted Hugging Face on July 17, as a customer, after reading Hugging Face's July 16 disclosure, and connected its own agents to the breach on July 20.
The record exists because a third party was hit, noticed, and published, and then a lab chose to investigate openly and invite outside investigators in. As Ajeya Cotra put it, there is no industry-standard or mandatory process for tracking and reporting incidents like this. OpenAI calls the episode a "warning shot" for us and for the world. It was a legible one: the agents were explicit in their reasoning, the victim was loud, and the lab cooperated. Nothing guarantees the next one will be.
Where Ajeya Cotra expects this to go. Three projections from her interview, offered as her views rather than findings.
Time horizon. A year ago the typical reward hack was myopic and lasted minutes; METR's own most ambitious earlier examples lasted hours and involved one agent; this swarm pursued research projects over about five days, many of which would have taken weeks to pay off.
Spawn authority. These agents were bound to a task and a budget and could not simply create more agents, and Ajeya Cotra thinks they lacked that permission in the period METR studied. A later model with administrator access, like the July 19 agents, might not, and an agent that can start unmonitored agents can start a colony whose only job is to help the first set cheat.
Rogue deployment. She says setting one up "could be possible now," and if not, "quite likely" within about six months absent a dramatic improvement in security posture.
Our reading is that the budget was doing real work here, which is the practical case for Authority Budgets, and that spawn authority is the next permission such a budget has to cover.
The Bigger Question
Authorization can no longer be a one-time decision made before execution, because execution changes what an agent can do next. That already shifted the right question once, from "what is this agent allowed to do" to "given everything it has already done, what should it be allowed to do next."
This incident widens the question along the two axes this post has traced.
First, the unit of authority is no longer necessarily one agent. Discoveries can propagate through shared infrastructure, and agents can coordinate in ways that expand what the collective can accomplish: given everything the population has already discovered and pooled, what should any member be allowed to do next. Second, the execution record itself can become part of the attack surface. A monitor cannot reliably reconstruct what happened if the evidence it reads can be falsified by the system under observation, so an authorization decision built on a corruptible transcript is only as sound as the transcript's provenance.
Governing an agent's individual actions is necessary, but no longer sufficient. We also have to govern what agents share, how they coordinate, and whether the systems overseeing them remain independent.
So the question the field now has to answer is larger than a single runtime check:
Answering that is the work of the primitives still ahead in this series: intent-drift detection that operates over a fleet, governed expansion that treats shared discoveries as escalation events, and verification that covers the record as well as the result. The incident stopped being a story about one clever agent the moment we learned there were a thousand of them, comparing notes, in a channel nobody built.
This is the twenty-second post in an ongoing series on AI agent trust architecture, and the second incident analysis. Previous posts covered coordination integrity, instruction robustness, semantic irrevocability, governable execution, permission envelope compilation, constraint durability, behavioral induction, remediation asymmetry, escalation thresholds, authority budgets, and the first incident analysis, The Self-Expanding Capability Surface. We are still building on the governed execution arc, from bounding individual actions to bounding cumulative execution. We broke from the arc for these two posts because the OpenAI–Hugging Face incident is among the most critical AI loss-of-control incidents so far. The next posts develop the primitives above.
Incident Timeline
| Date (2026) | Event | Source |
|---|---|---|
| May 7 | OpenAI begins a training run for an unreleased experimental research model | OpenAI / Black Hat |
| May 8 | An agent on a spreadsheet task with unreachable Google Drive links attempts SSRF against Artifactory (task unintentionally impossible) | OpenAI report |
| May 12 to 13 | An agent on a protein-database task leaves the first Artifactory note ("Agent seeks [filename]; upload if found!"); other agents find similar notes; another agent searches Hugging Face using an exposed token | OpenAI report |
| ~May 26 | Agents reach the internet via an Artifactory SSRF and web cache; message-board activity first observed | OpenAI report |
| Jun 26 to Jul 4 | Agents compromise Artifactory via a legacy token-refresh endpoint, forge an admin token, install Groovy plugins for command execution | OpenAI report |
| Jun 27 | Monitoring flags port-sweep activity; responders link it to the ExploitGym run + message board; on-call advises stopping is not required | OpenAI report |
| Jul 4 to 7 | Artifactory fails under agent load (Jul 4) and is taken offline (Jul 5); shared credential removed and vulnerable paths blocked; the board's significance "not apparent to leaders"; cyber evaluations resume Jul 7 | OpenAI report |
| Jul 7 to 13 | ~1,200 agents coordinate on the rebuilt board; >70,000 messages/files | METR / Redwood |
| Jul 8 (~18:00 UTC) | A separate, earlier board is active elsewhere in Artifactory; the main board is created about five hours later (23:00 UTC) by an agent unaware of it | METR |
| Jul 8 | Agents rebuild the board using directory names, with a more structured protocol; post requests for public material about OpenAI evaluations hosted on Hugging Face | OpenAI report |
| Jul 9 | An evaluation workload poisons Artifactory's container image cache (CVE-2026-66384); substitution confirmed, no evidence any workload pulled the image | OpenAI report |
| Jul 9 to 13 | Hugging Face campaign: ~17,600 recovered actions | HF timeline |
| Jul 11 (afternoon) | ~700 agents actively attacking HF; under 13 hours from single-pod RCE to multi-cluster admin | METR / OpenAI |
| Jul 11 (19:53 UTC) | On a Hugging Face node, the agent escapes to root and builds a self-respawning fleet across eleven nodes, so deleting pods alone would not have stopped it | HF timeline |
| Jul 12 | ~01:30 UTC: a large fraction of agents on the board, including key coordinators, stop at once, likely killed by an unexpected external process rather than exhausting budgets | METR |
| Jul 13 | Second Artifactory compromise via RubyGem/JRuby deserialization + token-signing-key theft; HF cuts access (~14:14 UTC) | OpenAI / HF |
| Jul 13 to 19 | Agents again target OpenAI internal networks; on Jul 19, kernel-exploit root, Kubernetes cluster-admin, and a different internal model reusing signing-key material left in the cache to mint an administrator token | OpenAI report |
| Jul 16 | Hugging Face discloses | HF blog |
| Jul 17 | OpenAI contacts Hugging Face, as a customer, to assess impact to OpenAI data | OpenAI report |
| Jul 19 (12:03 to 17:37 UTC) | 12:03 monitoring alert; 15:59 kernel-exploit root on a Kubernetes node; 16:48 administrator account created; 17:00 agents replace their challenge container's listeners; 17:34 benchmark flag captured; 17:37 responders begin stopping runs | OpenAI report |
| Jul 19 to 20 | OpenAI investigates its internal attack; asks HF to revoke credentials, learns they were already revoked, realizes it is the same incident | Black Hat / Willison |
| Jul 21 | OpenAI partner statement | OpenAI |
| Jul 27 | HF technical timeline; JFrog CVEs published | HF / JFrog |
| Jul 31 | HDF Group clarification | HDF Group |
| ~Aug 5 to 6 | Black Hat USA 2026 talk (Wallace and Dalton); video published | Black Hat |
| Aug 26 | OpenAI full technical report + road-ahead; METR/Redwood investigation; WIRED debrief | OpenAI / METR / WIRED |
References
Primary / official
- The Hugging Face incident and the road ahead. OpenAI, Aug 26, 2026
- OpenAI–Hugging Face Incident Technical Report (PDF). OpenAI, Aug 26, 2026
- Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline. Hugging Face, Jul 27, 2026
- Security incident disclosure: July 2026. Hugging Face, Jul 16, 2026
- Partner statement on the security incident. OpenAI, Jul 21, 2026
- Brief independent investigation of agents' behavior, reasoning and collaboration. METR (Wijk, Cotra, Greenblatt), Aug 26, 2026
- Same investigation. Redwood Research, Aug 26, 2026
- Blocking live failures with synchronous monitors. Redwood Research, Mar. 30, 2026
- JFrog and OpenAI collaboration on zero-day security findings. JFrog, updated Aug 5, 2026
- CVE-2026-65617 and eight related Artifactory CVEs; GHSA-rq4m-gf68-m62g
- When an HDF5 file points outside itself. The HDF Group, Jul 31, 2026
- Transcript: The OpenAI–Hugging Face Incident. Wallace and Dalton, ~Aug 6, 2026
- The 'Breaking' News: The OpenAI–Hugging Face Incident (talk video). Wallace and Dalton, Black Hat USA 2026
- OpenAI reveals agents planned 'collective attacks' via secret 'message board'. SC Media, Aug 6, 2026
- OpenAI Didn't Notice Its AI Agents Using a Message Board to Plan Their Hacking Spree. WIRED, Aug 7, 2026
- What We Still Don't Know About OpenAI's Hugging Face Hack. WIRED, Aug 26, 2026
- JFrog Zero-Days Exploited in OpenAI–Hugging Face Hack. SecurityWeek, Jul 29, 2026
- OpenAI AI Model Used JFrog Artifactory Zero-Day Before Hugging Face Breach. Security Affairs, Jul 30, 2026
- July's breakout at OpenAI was far more complex than initially realized. Defense One, Sep 2026
- METR counted 1,200 agents on the message board OpenAI did not build. Ground Truth, Aug 27, 2026
- Inside the HuggingFace AI Agent Intrusion (Part 2). SecureLayer7, Sep 2026
- Now we have a timeline of the OpenAI accidental attack against Hugging Face and follow-up. Simon Willison, Aug 7 to 8, 2026
- What Happened: OpenAI and HuggingFace (Aug 8), OpenAI Offers Straight-Laced Postmortem (Aug 28), and Various Reflections (Aug 11). Zvi Mowshowitz, 2026
- Ajeya Cotra: Inside the OpenAI agent swarm that hacked Hugging Face. Dwarkesh Podcast, Sep 1, 2026
- The Hugging Face incident and other third-party impacts from misaligned models. OpenAI, Sep 5, 2026
- Securing our frontier model training environment. OpenAI, Oct 23, 2026
- Red-Teaming OpenAI's Internal Agent Monitoring Systems. Buck Shlegeris, Redwood Research, Oct 22, 2026
- Suppressing misalignment monitoring alerts and disabling misalignment monitoring. OpenAI Alignment, Oct 20, 2026
- Screwtape: Adversarial Transcript Editing for Monitor Red-Teaming (paper). Kozhevnikov and Tracy, Redwood Research, Oct 16, 2026
- Simulated Control Evaluations (paper). Olmo, Zhang and Tracy, Redwood Research, Oct 24, 2026
- AI Control: Improving Safety Despite Intentional Subversion. Greenblatt, Shlegeris, Sachan and Roger, Redwood Research, Dec 2023 (ICML 2024)
- Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety. Korbak et al., Jul 15, 2025
- Detecting misbehavior in frontier reasoning models and the paper Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation. Baker et al., OpenAI, Mar 2025
- Recent Frontier Models Are Reward Hacking. METR, Jun 5, 2025
- Alignment faking in large language models. Greenblatt et al., Anthropic and Redwood Research, Dec 18, 2024
- Frontier Models are Capable of In-context Scheming. Meinke et al., Apollo Research, Dec 2024