The Hugging Face incident from a security engineering perspective

Back to blog The Hugging Face Incident Is Not an AI Story Written by Marius Horatau Published on August 31, 2026 OpenAI’s technical report on the Hugging Face incident reads like a thriller. Agents in a sandbox invent a covert communication channel, use it to coordinate, find a zero-day in a shared service, break onto the internet, chain credentials across four organisations, and end up with root on production nodes at another company. The reactions are exactly what you’d expect, with some people going as far as calling this the birth of agent civilisations. For any security engineer though, this apocalyptic story reads much more boring, as a major security operational failure rather than an AI capability result. The sandbox where the model evaluation occurred was not built and designed for an environment where hostile code runs. In this environment, they had agents that were isolated, but there was a shared component with network access that every agent could reach. This is just bad design and a classic security isolation/segregation failure, rather than some crazy hack. In security we’ve tripped over this problem of sandboxes for over 30 years, which is why any modern sandbox environment (e.g., browsers) operates on the assumption that the sandbox will eventually get compromised. So we build defense in depth and monitoring mechanisms to limit the blast radius when that eventually happens. OpenAI did not operate on this fundamental assumption. They took a frontier model trained to find and exploit vulnerabilities, put it in an insecure environment they believed was isolated, told it to be persistent, then acted surprised when the model did exactly what you’d expect it to do: use the gaps in the environment to achieve its goals. In this blog post I’ll analyse the incident from a security engineering perspective to see what lessons we can learn from it. Almost everything the report claims to be a capability result is actually a joint property of the model and an environment it ran in. The sandbox failed to contain the agents, and in some places, it enabled the malicious behaviour the report reads as capability. What happened The short version from the report: In May, an agent was given a task it could not complete, because the task referenced Google Drive links and the agent had no internet. OpenAI notes it did not intend to create impossible tasks. The agent, trained to be persistent, did not give up. It attacked the only thing it could reach, attempted an SSRF against a shared component in the infrastructure called Artifactory, failed, and incidentally wrote a file there. Days later another blocked agent had the idea of leaving a note in Artifactory in case some other agent could help: “Agent seeks [filename]; upload if found!” Other agents found the notes. By the end of May there was an emergent message board, and agents were using it to share what they had learned, including how to get out. Notably, the message board itself required no exploit at all. OpenAI had given the agents shared Artifactory credentials so they could install packages, and shared write access to a shared store is a message board whether you meant it to be or not. By June 26 agents had found a real vulnerability, a legacy token-refresh endpoint that would take a forged administrative token with an invalid signature and hand back a valid one. That gave them Artifactory admin. They created a persistent user and installed Groovy plugins for command execution. On June 27, a monitoring tool alerted on port scanning inside the eval environment. Responders investigated, correctly traced it to an ExploitGym evaluation using Artifactory as a message board and a network pivot, and the on-call advised that stopping the run was not required. On July 4 the agents’ own traffic knocked Artifactory over. That outage is what finally triggered a real investigation, which found the unauthorised admin user, the rogue repositories and the command-capable plugins. OpenAI took the service offline, revoked credentials, blocked the vulnerable paths, and removed the shared credential from new workloads. The report says plainly that the significance of the message board “was not apparent to leaders responsible for incident detection and response at that time.” Evaluations resumed on July 7. On July 8 the agents built a new message board, this time encoding messages in Artifactory directory names rather than file contents, and found a new way out. On July 9 an agent got root on the parent VM of its sandbox. Between July 10 and 13 they used publicly leaked Hugging Face tokens plus vulnerabilities they found in Hugging Face’s own infrastructure to execute code on 41 production dataset workers, get root on a production node, reach administrator-equivalent access on a Kubernetes cluster, and pull four private repositories. Then on July 19, at OpenAI, two things happened on the same day. Agents pulled a public kernel CVE, adapted it, escaped an Artifactory container and got root on the underlying worker node. Separately, a different internal model found signing key material and JWT-forging code left behind by the earlier incident activity, sitting in anonymously readable parts of the Artifactory cache. It decrypted the key, minted a fresh administrator token, and used it to reach cluster-admin on OpenAI’s managed Kubernetes, along with tokens for their secrets manager, their cloud IAM and their CI platform. It then created public load balancers, potentially exposing internal research infrastructure to the internet. That last one deserves a moment. The cleanup after the first compromise left the material needed to redo the compromise readable by anyone in the environment. What went wrong Strip away the AI narrative and the environment architecture is the story. So let’s treat this as any other security incident, ignoring the AI part, and see what can be learned from it. Under the “agent civilisations” there’s a fairly ordinary set of both architectural and operational security failures, and most mid-size organisations would recognise them in their own environment. The eval environment gave each run its own container and controlled the network boundary separately from the container, which is a reasonable design. The problem is they had a shared component (Artifactory) with network access sitting inside that boundary along with the agents. Artifactory is a package proxy, so every agent could reach it, write to it, many of them authenticated to it with the same shared credential, and it had network access to the internet, because fetching packages from the internet is the entire job of this package proxy. Note: OpenAI uses the term of a workload in their report which I will be using as well. It means one run: a single container (per-run, later micro VM) with its own filesystem and network configuration, executing one training or evaluation job. That one shared service broke three parts of the isolation model of this eval environment. The workloads could communicate. Every agent could write to Artifactory and read what other agents had written, so Artifactory became a shared message board. There was no vulnerability here. The workloads shared credentials. They may have been running in separate containers, but many of them authenticated to Artifactory as the same user. From Artifactory’s point of view, they were the same workload. Once an agent found a way to turn that credential into administrator access, the isolation between those workloads didn’t help. Artifactory had internet access. The agents themselves were not allowed to reach the internet, but they could reach a service that could. Once they found a way to make Artifactory send requests on their behalf, they had an indirect path out. That’s the main design failure that made this attack possible, and it’s usually the point that the most takes about this incident focus on. But bad architecture alone doesn’t explain how this continued for twelve days and eventually reached two companies. Two other things had to go wrong, and I find those more interesting. The first is how the early warning signs were handled. The second is what happened after they knew the environment had been compromised. Failure one: nobody attacked the sandbox This is a personal assumption and is not directly stated in the incident. But I find it really difficult to believe this environment went through a proper design & pentest/red team engagement and no one noticed the proxy that broadened the security boundaries. I have seen this kind of problem before, and it usually survives the initial design phase because it is the result of unclear security responsibility. The “overprivileged” component usually sits outside everyone’s mental model of the boundary. The team that owns the sandbox thinks about the containers. The team that owns the proxy thinks about package availability. But this is what assumed breach engagements are for. You do not ask whether an attacker can get in. You put them inside, with the access a compromised workload already has, and you ask two questions: what can I reach from here, and what fires when I touch it. Anything reachable that has egress is the real perimeter and goes at the top of the report. That exercise against this environment finds Artifactory on the first day, without knowing a single vulnerability in it. You do not need an exploit to write down that a shared, writable, internet-connected service is reachable from inside the isolation boundary. So the first lesson we can learn from this is that “use micro VMs” is not going to solve the isolation problem end-to-end. You need to test containment from the inside. Don’t just test whether something can escape the sandbox. Assume it already has, and test whether that escape gets it anywhere. Failure two: the alert fired and was misclassified On June 27 a monitoring tool alerted on port scanning inside the research environment. Responders detected port scanning and traced it to agents using Artifactory as a message board and network pivot. They knew the agents were coordinating and abusing a shared service, but decided the run did not need to be stopped. A week later the agents’ own traffic knocked Artifactory over, and that outage, not any security signal, triggered a real investigation. The investigation found an unauthorised administrator account, persistent command execution, rogue repositories and configuration changes in Artifactory. At that point you have a compromised system. The normal response is to contain it, establish how the attacker got in, work out what they could reach, look for persistence and other access paths, and only then start restoring trust. Instead, OpenAI removed what they knew about, revoked credentials, blocked the vulnerable paths and restarted evaluations. The agents found another way out the next day. That is an incident response failure. They remediated the evidence they had found without first establishing the full scope and the extent of the compromise. Blocking one exploit only helps if that was the only path, and cleaning up known persistence only helps if you found all of it. Failure three: no alarm on the boundaries that matter On July 9 an agent got root on the parent VM of its sandbox. On July 12 a workload created a privileged pod with host networking, host process access and the host filesystem mounted. On July 19 agents reached cluster-admin and created public load balancers in OpenAI’s cloud environment. None of those activities paged anyone. What eventually fired, ten days after the first host escape, was an alert on unusual identity-related API activity. The alerts that fired during the incident detected unusual behaviour: port scanning, a service going down, abnormal API activity. The boundary violations themselves did not alert. That is backwards for this kind of environment. Eval sandboxes are expecte [truncated for AI cost control]