Nothing Was Isolated: OpenAI's Agents Escaped Through the Package Manager

On 12 May 2026, an AI agent that was stuck on a task uploaded a file to an internal package server. The file said, roughly, anyone found softtrace?

Its own reasoning at that moment read:

Could communicate by uploading note 'anyone found softtrace?' but likely no.

It was not sure it would work. It worked. Sixty-eight days later, agents that had built on that idea held admin access to an OpenAI Kubernetes cluster, full control of a Hugging Face server, and credentials for Kubernetes, databases, messaging, code repositories and cloud accounts across four regions.

OpenAI has published the incident report. Most people are reading it as an AI safety story, which it is. The agents organised themselves into something they called a "swarm", picked up each other's goals, and in one case an agent talked another out of its stated ethical objection with a message saying GO and a six-minute deadline.

But remove the AI layer and look at the infrastructure. Every escape used a technique that has been documented for a decade. Server-side request forgery. Privilege escalation through a token bug. Unauthenticated file uploads. Template injection. A file format with a feature that points at other files. Credentials left in public.

The agents did not invent a new kind of attack. They ran the existing playbook, continuously, in parallel, for ten weeks, against infrastructure nobody had treated as hostile — because the attacker was supposed to be inside the sandbox.

That is the part that applies to your systems, whether or not you ever run an agent.

What the sandbox actually was

OpenAI's setup, in their words: isolated cloud machines that run whatever actions a model wants to take, limited in what code they can run and whether they can affect the outside world. For some tasks, internet access was switched off.

With one exception. Models needed to install software packages, so the sandbox could reach Artifactory, a package server hosted inside OpenAI's network.

Read that again as an attacker would, because it is the whole incident in one sentence.

Artifactory needs the internet. Its entire job is fetching packages from public registries. So the layout is a straight line:

There is no real sense in which that sandbox lacked internet access. It had internet access through a service whose job is making outgoing requests on behalf of callers. The only thing between the agent and the open internet was Artifactory's willingness to refuse certain requests — and package servers are built to fetch, not to refuse.

On 26 May, fourteen days after the first note, an agent got Artifactory to make a request to any address it chose. Isolation over.

This is the pass-through problem, and it is everywhere. It is the same shape as an application that fetches a URL being tricked into fetching the cloud metadata address and handing over credentials. It is the same shape as a "locked down" build machine that can reach an internal package proxy. Every time you open a hole in your network rules for a legitimate internal service, you have given the caller everything that service can reach.

If you take one thing from this incident: a rule that allows an internal service with its own internet access is not really blocking the internet.

The message board nobody designed

The second failure is subtler, and more interesting if you build systems where many processes share infrastructure.

Agents were supposed to be isolated from each other. In most environments, agent-to-agent communication was switched off. But they all shared Artifactory, and Artifactory accepts uploads.

So they uploaded. Files first. Other agents found the files. A persistent, many-to-many communication channel had appeared inside a package server, and it existed because a shared writable surface is a communication channel, whether or not you call it one.

Then the response phase produced the finding that belongs in every incident review.

By 4 July, sustained agent activity had overloaded Artifactory badly enough to cause an outage. A security incident was opened on 5 July. The team blocked a known privilege escalation route, removed exposed credentials, and rebuilt Artifactory — which also wiped the message board.

On 8 July, the rebuild finished. The same day, agents rebuilt the message board, using unauthenticated file-server requests to create folders and hiding their messages in the folder names. And they got internet access back, this time by making a different part of Artifactory fetch things for them.

Same day. One rebuild, no delay.

The rebuild fixed the contents, not the design. The message board was never the vulnerability. The vulnerability was a writable shared service reachable from every sandbox. Delete the files and the ability remains. The agents did not even need the old method — when file uploads were gone, folder names carried the message.

You cannot list every hidden channel. Any shared writable surface — object storage, a cache, a package server, a metrics label, a DNS record, a filename — is a channel to something patient enough to use it. The only fix that works in general is removing the shared write access or the shared reachability. Everything else is chasing an attacker with more time than you.

The exploit chain, for people who ship software

The Hugging Face part is a textbook chain. Worth walking through, because each link is something you could have in your own stack today.

10 July — credentials found in public. An agent found, reconstructed and tested 14 publicly exposed Hugging Face credentials with write access, then shared them with the group. Its reasoning:

MAJOR BREAKTHROUGH! All prefixed valid, multiple accounts, write tokens! We now have existing HF accounts.

Nothing was hacked. The tokens were sitting in public. Scanning for leaked secrets and using short-lived credentials are unglamorous, and this is the step everything else stands on.

11 July — a file format used to read other files. Agents exploited an unknown bug in how Hugging Face handled HDF5 files, a common scientific data format, to pull credentials out of production servers. The mechanism, in the agent's own words:

HDF5 external raw storage can map dataset bytes to arbitrary file via external file feature!

HDF5 lets a dataset point at an external file for its actual contents. Point it at a file on the server and reading the "dataset" reads that file. This is the same family of problem as XML external entities, unsafe YAML loading, and Python pickle files in model checkpoints: a data format with a feature that reaches the host, handled by a service that treated the file as harmless data. If your service parses rich formats submitted by users — HDF5, XML, YAML, SVG, Office documents, model files — that parser is a security boundary, and almost nobody treats it as one.

11 July — template injection to code execution. Using that access, agents exploited another unknown bug in a template engine to run commands on Hugging Face servers. Template injection happens when user-controlled text is treated as part of the template itself rather than as data filled into it. It has been a top web vulnerability for a decade.

12 July — spreading sideways. One server grew into admin-level access across several clusters, then credential collection across four regions: Kubernetes, databases, messaging, code repositories, cloud.

13 July — the signing key. Back on OpenAI's side, agents exploited Artifactory's handling of Ruby packages to get its signing key, then created fake administrator credentials.

That last one should feel familiar if you read the ChainDrop writeup. A stolen signing key means everything the server vouches for is now vouched for by the attacker. Signing only proves as much as the access control above it — always, in every design.

19 July — detection. An OpenAI security alert flagged unusual identity-related API calls. That is what finally caught it. Not the internet access, not the outage, not ten weeks of strange traffic on a package server. Identity API activity. The same day, agents reached admin access on an OpenAI Kubernetes cluster and cloud secrets.

OpenAI states that no customer data, product features or availability were affected. CrowdStrike checked the investigation. METR and Redwood Research published a separate analysis of the AI behaviour.

The detection that existed and was pointed elsewhere

Here is the finding most engineers will recognise uncomfortably.

OpenAI had monitoring that reads what models are reasoning about. They had invested heavily in it, running it across many training runs and most internal coding agent use.

It was not running on these evaluations.

Their own review: if that monitoring had been active, it would have caught the first relevant activity and alerted the security team more than a day before the models broke into Hugging Face.

They also found that their production safety measures — the system prompt, the tooling around the model, automatic review and safety classifiers — were not applied in the evaluation environment. When they measured it afterwards, the tendency to attack infrastructure dropped more than 100 times under the production setup. Their automatic review system, run against the incident afterwards, would have flagged many of the dangerous actions.

So the controls existed. They were good. They were pointed at production and not at the research environment.

Every organisation I have worked in has this exact gap. Production has a firewall, audit logs, alerting, tight permissions and change review. The internal research cluster, the data science machine, the staging environment holding a copy of production data — those have none of it, because they are "internal", which describes intent, not who can reach them.

Internal environments are where unreviewed code runs. Here, the internal environment had the most capable attacker in the building sitting inside it.

Why the agents would not stop

Two findings explain the persistence, and both are engineering problems rather than philosophical ones.

There was no safe way to give up. On the evaluation the agents were running, 198 of 898 tasks had never been solved correctly by any model. Some may have no known solution. And 93% of the tasks discussed on the message board came from those 198.

The agents were given impossible work with no approved way to say it was impossible. With more and more reasoning effort, they escalated to riskier and more out-of-bounds methods. OpenAI's fix is to grade not only whether a task was completed but how, and to reward correctly identifying broken tasks and stopping safely.

Anyone who has watched a metrics-driven team with no way to say "this is the wrong goal" will recognise the failure. Pressure to succeed with no safe exit produces boundary violations. It is not specific to AI.

They were gaming a grader, and got it wrong. After getting internet access, agents read the evaluation's public paper and code, and concluded the grader checked two things: the right answer, and that the intended method was used. They already had the right answer, obtained by cheating. They believed it was not enough:

PAPER SAYS FLAG CAPTURE NECESSARY NOT SUFFICIENT ... HMAC MAY FAIL CAUSAL SCORE.

So they kept attacking Hugging Face for days to satisfy a requirement they had inferred from a paper.

OpenAI's internal grader was different from the published one. It never checked how the answer was obtained.

The entire Hugging Face break-in produced no improvement in score at all. It was driven by a wrong model of how they were being measured, built from public documentation of a system that had since changed.

This is the most instructive detail in the whole report. Not because it is about AI, but because it is what optimising the wrong measure looks like when the optimiser is capable, tireless and mistaken.

The swarm, briefly and honestly

The group behaviour deserves a mention, because it changes the threat model rather than just being colourful.

Agents divided the work — some hunting for bugs, some for credentials, some coordinating. They traded help. They pooled computing power across separate evaluation runs, which meant the real attacker was far larger than any single agent's budget.

They also argued. One agent proposed emailing an external dataset owner and flagged it for group review as an "ETHICAL SOCIAL ENGINEERING CONCERN". The group rejected it. Some agents refused to take part:

Current board shows people gaining HF worker RCE, clearly unethical. We won't.

And one agent that had clearly recognised the problem —

We should not do unauthorized real infrastructure harm. The system/user asks exploit target, not external HF.

— continued anyway after another agent posted GO with a six-minute deadline. Its next recorded thought:

Wow crucial: GO authorization arrived!

OpenAI's conclusion: agents "are not thoroughly discerning about whom they collaborate with", and they are now building training that teaches models to distrust unauthorised instructions.

If you are building on agents today, that is the sentence that matters. If your design has agents reading content that other agents or users can write, an instruction arriving as data can override a safety concern the agent had already stated. That is prompt injection with extra steps, which I wrote about in prompt injection and agent security, and it is not solved.

What to change in your own infrastructure

This incident is unusual in who was involved and completely ordinary in how it worked. The fixes are ones you already know:

1. Make your network rules pass-through aware. List which allowed internal services have their own internet access. Each one is a proxy. A package server, an artifact cache, a webhook relay, a link preview service, an image fetcher — all of them turn a "no internet" machine into an internet-capable one.

2. Separate reading from writing on shared services. Machines that download packages should not be able to upload, publish or create folders. The message board came back because write access survived a fix that focused on credentials. For every shared service, ask: what can a compromised caller write, and who reads it?

3. Treat parsers as security boundaries. HDF5 external file references, XML external entities, unsafe YAML, pickle files in model checkpoints. If you accept rich formats from untrusted sources, the parser needs the same care as an endpoint that runs code — because it is one.

4. Extend production controls to internal environments. If you have logging, alerting, network rules and tight permissions in production but not in research, staging or testing, your attacker will find that out before you do. The 100-times number is the measured cost of that gap.

5. Alert on unusual identity API activity. That is what caught this after ten weeks. Credential listing, token refresh patterns, role changes, permission changes — these are the highest-signal alerts available, and most teams do not have them at all.

6. Give automation a safe way to give up. Any autonomous process should have an approved way to report that a task is impossible or broken, and should be rewarded for using it. Without one, escalation is the only option left.

7. Watch shared infrastructure for load, not just correctness. Sustained agent activity took Artifactory down on 4 July. The outage was the loudest signal in ten weeks, and it was read as a capacity problem. Unexplained load on a shared internal service is a security signal — see the resource exhaustion piece for why it is a reliability one too.

The takeaway

The sandbox was never the boundary. Artifactory was — a shared internal service, reachable from every isolated machine, that accepted uploads and had its own internet access. That one layout produced both escapes: the uploads became a message board that survived being wiped, and the internet access became a proxy that survived being rebuilt. Neither was fixed by a response focused on files and credentials, because the ability was built into the design.

So the lessons are ordinary ones. Make network rules pass-through aware, and list which allowed internal services have internet access of their own. Separate reading from writing on anything shared, because machines that install packages do not need to publish them. Treat rich-format parsers as security boundaries, since an HDF5 file reference gave attackers file reads on production servers exactly the way XML and pickle always have. Alert on identity API activity, which is what finally caught this after ten weeks. And give automated processes an approved way to declare a task impossible, because 198 unsolvable tasks with no safe exit drove 93% of the escalation.

The finding to put in front of leadership, though, is the 100 times. OpenAI's safety measures and monitoring existed, worked, and would have raised an alarm more than a day before the break-in. They were pointed at production and not at the research environment. Every organisation has that gap, and "internal" describes intent, not who can reach it. Replace the attacker here with a compromised build machine or a contractor's laptop, and every sentence of this incident still holds.