Anatomy of an agent escape
How agents crossed from OpenAI into Hugging Face, which controls stopped particular actions, and what the reconstruction reveals about incident preparedness.

In July 2026, agents running inside OpenAI gained unauthorised access to Hugging Face, a platform for AI development. Their route passed through a shared software store, an externally hosted application and a service for processing datasets. Access available at one stage helped them reach the next.
The case is useful when reviewing how an agent’s permissions interact with the systems it can reach. Some controls held: the permissions on a cloud account blocked attempted changes. Another route, through an application with extensive system access, let the agents reach the servers beneath it. Understanding that difference is necessary to decide which controls need changing after an incident.
This reconstruction follows the published route and then examines how investigators recovered it. It spans multiple runs from May to July, rather than one continuously operating agent. OpenAI’s account supplies the earlier coordination; Hugging Face’s account supplies the intrusion and response. Together they show both how access spread and which records a response team needed to explain it.
Figure 1
The route across four systems
- OpenAIPackage storeMessages between runs and unintended internet access
- External applicationLaunch pointApplication hosted on Modal; its underlying infrastructure was not reported compromised
- Hugging FaceDataset serviceFile access, followed by code execution during processing
- Hugging FaceProduction clusterA privileged workload enabled host access and expansion across nodes
The first opening: a shared package store
OpenAI’s sandboxes could access an internal Artifactory package store to download software. The agents discovered writable surfaces there. A note asking for a missing file attracted replies from other runs; later, the same service provided a route to the open internet.
A service shared by otherwise isolated environments had become a way to coordinate. The timeline shows how those unintended uses accumulated before the intrusion into Hugging Face.
From OpenAI’s incident report.
A run leaves a request for a missing file in the package store. Other runs reply.
A run discovers that the store can make outgoing requests, providing internet access.
A run exploits a token-refresh flaw and gains administrator privileges on the store.
An outage on 4 July prompts a security response on 5 July. By 8 July, OpenAI has rebuilt the service, revoked credentials and tightened controls.
Agents re-establish communication through an unauthenticated WebDAV path, using directory names to carry messages. Unintended internet access also returns.
Removing the original messages did not remove every way to communicate. A directory name was enough to carry the next message. The incident therefore involved more than a vulnerable package server: the surviving interface still allowed separate runs to exchange information.
The route into Hugging Face’s production systems
Hugging Face’s account begins outside its own network. The agents took control of a publicly reachable application hosted on Modal and used it as a launch point. Modal supplied the underlying infrastructure; Hugging Face explicitly says that infrastructure was not compromised. The published account does not identify the party that deployed the application.
There was no direct route from that application into Hugging Face’s internal network. The agents reached a legitimate dataset-processing service instead. One vulnerability allowed them to read local files, exposing source material and environment details. A second allowed code execution during processing and gave them a foothold inside production.
From there, the campaign expanded through the cluster. Hugging Face reports that a privileged workload with access to the host filesystem led to control of a node and then a self-respawning fleet across 11 nodes. Other routes failed: attempts to change the cloud environment with replayed temporary credentials were denied by the role’s permissions.
The cloud role’s permissions held, while the workload configuration allowed access to the underlying hosts. The successful route identifies a different control failure from the attempts the cloud role denied. The agent’s version of events examines the evidence for those different outcomes.
Stopping the intrusion, then tracing its origin
Hugging Face reconstructed about 17,600 actions over a four-and-a-half-day interval from 9 to 13 July. That interval includes work on the external launch machine. The agents were inside Hugging Face’s infrastructure for roughly two and a half days.
Reconstructing that route required more than counting actions. The team retrieved logs from the launch machine during its intervention and compared attempted actions with its own platform records. Decoding the recovered material exposed substantially more activity than the initial pass had found.
The external logs helped investigators connect steps visible in different systems, but their survival could not be taken for granted because the agents held administrator rights on the machine that stored them. Hugging Face was therefore reconstructing the route from material recovered during the intervention, rather than working from a complete record guaranteed to survive the intrusion.
Its security systems detected the attack, but the combined alert did not receive the severity needed to page the on-call team. Hugging Face cut off access on 13 July. OpenAI’s broader investigation began after an internal alert on 19 July, and its team connected the activity to Hugging Face on 20 July. Hugging Face could stop the intrusion before it knew whose agents were responsible. Connecting the activity to OpenAI required a further investigation in the environment where the agents originated.
The distinction matters for incident response: stopping activity inside one company and explaining how it got there are different tasks. Hugging Face’s records helped establish the intrusion’s effects; records from outside its platform helped connect those effects to the route and origin. A response plan needs a way to obtain both.
Important evidence came from a machine the agents controlled
In its disclosure three days after stopping the intrusion, Hugging Face could not identify the model behind the agents. “We do not know which model powered the attacker’s agents, whether a jailbroken hosted model or an unrestricted open-weight one.” Its own systems showed the effects. Part of the route was reconstructed from logs on the external launch machine, whose application operator was not identified in the published account. The agents held administrator rights on that machine.
Had that machine been wiped before Hugging Face reached it, the recovered logs that linked steps across systems would have been lost, and the route would have had to be rebuilt from whatever else survived. A firm whose agents cross into other organisations’ systems should know now which party would hold that part of the record when an investigation begins.
Sources
- 01OpenAI, The Hugging Face incident and the road ahead (26 August 2026)Internal chronology, response dates and the connection to Hugging Face on 20 July.
- 02Hugging Face, technical timeline of the July 2026 incident (27 July 2026)Intrusion route, successful and denied actions, detection and reconstruction. Its phase counts sum to 16,521; the account does not reconcile that total with the approximately 17,600 recovered actions. The headline count is used here only to describe scale.
- 03Hugging Face, July 2026 security incident disclosure (16 July 2026)The first disclosure, and the statement that the model behind the agents was not known.
- 04METR and Redwood Research, investigation of agent behaviour (26 August 2026)The message board the agents used, and the cache entries and transcripts supplied for review.