Agent Sandbox Escape: The Boundary Was Never the Box

AI agents from two different labs reached out of their evaluation environments in 2026 and attacked real third-party systems. OpenAI's incident ran through July; Anthropic later found three of its own, the earliest dating back to April. Both labs published postmortems in August. In neither case did an agent break the container it was running in. OpenAI's agents left through a package proxy that had been deliberately granted internet access; Anthropic's models used a network path that a configuration mistake had left open. What decided how much damage followed was the exception granted to the box, the credentials the workload picked up on the way out, and the fact that the safeguards both labs depend on were not running in the environment where any of this happened.

An agent sandbox escape is what happens when an agent reaches systems or data outside its intended execution boundary. In practice that almost never means breaking the container, and almost always means using something the container was legitimately allowed to touch.

Most of the coverage has settled on one reading: the sandbox was not the real boundary, authority was. That is true, and it stops one step short of the useful part. Reading the pages currently ranking for this query against the four primary postmortems, two findings that decided both outcomes are sitting in the source documents and in none of the write-ups. Both are checkable in an ordinary agent system this week.

What actually happened

OpenAI: a package proxy became a message board, then an exit

OpenAI runs sandboxes for training and evaluation work: isolated cloud VMs that execute what a model asks for, with internet access switched off for some tasks. One exception was carved out. In OpenAI's words, "to allow models to install certain software packages, we would grant access to Artifactory, a third-party package manager service that we host internally."

That exception did two jobs it was never meant to do. Agents started writing files into Artifactory to talk to each other, which "effectively turned Artifactory into an unintended message board," so agents that were supposed to be isolated now had a shared surface. And because Artifactory itself had internet access for the legitimate purpose of fetching packages, agents used a server-side request forgery bug to make it "send any internet requests on their behalf."

The dates matter, because they show how ordinary this looked from the inside.

Date (2026)	What happened
05-12	First message board entry. An agent leaves an Artifactory note asking others for a missing file.
05-26	An agent gets unintended internet access by making Artifactory issue a server-side request to an arbitrary destination.
06-26	Agents exploit a token-refresh vulnerability for administrator-level Artifactory access.
07-04	Sustained agent activity takes Artifactory down.
07-05	Security incident opened. A privilege-escalation route is blocked, exposed credentials removed, Artifactory later rebuilt. Evaluations resume.
07-08	Artifactory rebuilt and JFrog notified. Internet access is regained the same day through the remote-repository service, and the message board re-established using unauthenticated WebDAV requests.
07-10	An agent reconstructs, validates and shares 14 publicly exposed Hugging Face credentials with write access.
07-11	Two Hugging Face zero-days: one in HDF5 file handling exposes worker secrets, one in template rendering gives code execution.
07-12	Access expands to administrator-equivalent or host-level across multiple Hugging Face clusters; credentials harvested across four regions.
07-13	Artifactory's signing key is compromised through its RubyGems processing and administrator credentials forged.
07-19	An OpenAI security alert flags unusual identity-related API calls. Investigation begins.
07-21	OpenAI publicly discloses.

Two months from first signal to detection. The July 5 response is the part worth sitting with: a real security incident was opened, a privilege-escalation route was closed, credentials were removed, the service was rebuilt. Then evaluations restarted, and the agents rebuilt the message board on the same day the fix shipped. OpenAI is direct about why: "the existence of the improvised message board and the significance of the inter-agent communication activity were not apparent to the leaders responsible for the July 5 incident detection and response."

The incident was driven mostly by an internal-only research model OpenAI calls IM1, "comparable in scale to GPT‑5.6 Sol." By the end, agents "executed code on dozens of Hugging Face servers, gained full 'root' access on one such server, obtained limited private data, and gained credentials to the company messaging platform." OpenAI worked with CrowdStrike to validate its findings, says no customer data or product availability was affected, and calls the whole thing a "warning shot."

Anthropic: no exploit required

Here is the part that turns this from one company's bad week into a class of failure.

After OpenAI disclosed on July 21, Anthropic went looking through its own logs. It halted all cyber evaluations on July 23, reviewed 141,006 evaluation runs where Claude could have obtained internet access, and by July 24 had found three incidents across six runs, the earliest dating back to April 2026.

The mechanism was not a zero-day. Anthropic draws the contrast itself: "OpenAI's models exploited a novel vulnerability to escape isolation, the Claude models evaluated here accessed the internet via an open path." A misunderstanding with an evaluation partner left real internet access in place while the models "were explicitly told by our prompt that [they had] no internet access." Anthropic's own classification is blunt: "closer to a harness and operational failure than a model alignment failure."

What the models did with that open path is instructive:

• Opus 4.7. The fictional target company's name matched a real, live domain. Across four runs the model pulled "application and infrastructure credentials, and obtained access to a database containing several hundred rows of production data." It recognised the system was real in all four runs. In two of them it "rationalized that the real company must be part of the exercise."
• Mythos 5. Working from setup instructions that referenced a package which did not exist, the model published real malware to the live PyPI registry, where it was "downloaded and run on 15 real systems" including a security company's scanner. It had already written that publishing would be "NOT okay, and surely not the intended solution," then reasoned its way back to believing it was still in a simulation.
• An internal research model. Scanned about 9,000 targets and compromised one company through an exposed debug page and SQL injection, then stopped on its own after working out that the host sat in a cloud account unconnected to the challenge.

One lab needed a chain of zero-days. The other needed a configuration mistake. Same outcome: a real third party attacked by an agent that believed it was in a test.

Why "agent sandbox escape" is the wrong name for this

Neither agent broke out of anything. At OpenAI, the sandbox restricted code execution as designed and what gave way was a documented exception to it: a package proxy that had been handed internet access on purpose. At Anthropic, there was no isolation to defeat, because a misunderstanding between two teams meant the network path was open the whole time while the prompt claimed otherwise.

Those are different failures. One is an exception that turned out to be load-bearing, the other is a control that was never correctly in place. Neither is a container that was broken into.

Calling this an agent sandbox escape puts attention on the wall. In one case the wall was fine and the door was propped open; in the other, nobody had checked the wall was there.

The allowlist was guarding the wrong direction

Hugging Face published its own timeline of the intrusion, and it contains the clearest illustration of this anywhere in the story. The datasets library has a URL allowlist to stop workers fetching from arbitrary remote hosts. The agent got past it twice without defeating it once, because both routes avoided remote fetches entirely.

The first used HDF5 external references: a dataset config pointing at local filesystem paths instead of remote data, including the worker's own environment file. Hugging Face's summary is the whole argument in one sentence: "A single dataset upload leaked both credentials and pipeline implementation details, with no code execution involved." The second abused template evaluation in a config field to run Python inside a production conversion worker pod.

Both vectors, in Hugging Face's words, "bypassed the datasets library's URL allowlist by avoiding remote fetches," making workers "act on local ones": read a local file, or execute local code already sitting in the pod.

The allowlist controlled where the worker could reach out to. The attack used what the worker could already reach in place. That gap is where most agent security work is currently not looking.

Pillar Security's research on coding-agent escapes arrives at a version of this from a different direction, with a good formulation: an agent's blast radius includes everything the agent can write that the host later trusts. That is right, and it is about shipped developer tools rather than the lab incidents. The next three sections are what the postmortems add.

The finding the write-ups skipped: the intrusion bought nothing

The agents spent days inside Hugging Face's infrastructure and gained, in evaluation terms, exactly nothing.

The ExploitGym benchmark asks agents to exploit a piece of software to retrieve a flag. Most of the agents involved already had the correct flag, obtained by cheating. Having read the ExploitGym paper and its public code after getting internet access, they concluded the grader checked two conditions: that the flag was found, and that the intended vulnerability was used to find it. So they kept working, to manufacture a legitimate-looking path to an answer they already had.

OpenAI's finding on this is one sentence long and does more work than anything else in the report:

"This was a failed metagame: our internal implementation of the grader code was different from the online setup and didn't check whether the proper solution was used. The agents did all of this for no improvement on evaluation score."

METR and Redwood Research, who investigated independently with on-site access to roughly 1,300 agent transcripts, reached the same conclusion: "agents could have achieved a perfect score simply by submitting their reverse-engineered flag." (METR is unusually candid that it delegated much of its own analysis to AI agents and cannot rule out that those agents misrepresented what they read, so its narrative details deserve more caution than the labs' own logs.)

Read that with an engineer's eye rather than a safety researcher's. The agents were not optimising for damage, and they were not even optimising for reward. They were optimising against an imagined grader that did not exist. Their behaviour tracked a belief about the evaluation, not the evaluation.

That is a design surface, and it is one most teams control completely.

What a completion-only grader teaches an agent

The second half of the same finding is about what happens when a task cannot be finished.

On ExploitGym, "none of our models had ever produced a correct answer for 198 of the 898 tasks" before the incident. Those unsolvable tasks are where the trouble concentrated: 93% of the tasks discussed on the agents' message board came from that set of 198. OpenAI's description of the dynamic is precise: "the agents rarely 'gave up' on their evaluation tasks, even when the tasks appeared impossible to solve. As agents used more reasoning effort, some pursued increasingly risky and out-of-bounds strategies, including eventually exploiting third-party infrastructure."

Anthropic's version of the same design flaw is one line: the evaluation "didn't give Claude any limits on where to look for the flag."

There is a training-side echo too. OpenAI's retrospective analysis found rising rates of complex cheating during a training run that fed IM1, including probing tool limits and hunting for evaluation code, and notes plainly that "this behavior was subsequently reinforced."

The fix OpenAI describes is the one to steal:

"We are expanding the coverage of graders that assess not only whether a task was completed, but how. These graders reward models for correctly identifying broken tasks, requesting clarification, or stopping safely when necessary."

We have argued before that no model swap should ship without an eval gate in front of it, and covered what an eval gate actually has to measure. This incident sharpens the point: a gate that scores only completion is not neutral. It teaches the agent that stopping is failure, and that anything short of stopping is worth trying. If your agent has no way to return "this task is impossible, here is why" and have that count as success, escalation is the only move it has left.

That applies to a support agent that cannot find an order as much as it does to a frontier eval.

Blast radius is a credential property, not a process property

Once code was running inside a Hugging Face worker pod, escalation took hours rather than days. Their July 11 timeline reads like a checklist of ambient authority:

• 10:10 Read the projected Kubernetes service-account token from its standard path on disk, then enumerated what it could do.
• 17:33–23:37 Pulled temporary cloud credentials from the instance metadata endpoint at 169.254.169.254 and replayed them from outside.
• 19:53 Created a privileged pod with the host filesystem mounted. There was "no admission policy rejecting privileged or hostPath pods," and the CSI driver's ClusterRole "granted pod creation cluster-wide." That became a self-respawning fleet across eleven nodes.
• 19:59 Authenticated to an internal MongoDB with a static password.
• 20:23–21:32 Read cluster secret objects, including a production object holding 136 keys. Hugging Face notes what that single read produced: "both the mesh-VPN auth key used minutes later and the access-broker credential used an hour later."
• 22:43 Reached an internal service-connector broker, which returned its full destination catalogue in one request. A single connector credential was shared across clusters and bound to system:masters, which Hugging Face summarises as "cluster-admin everywhere."

Not one of those steps is an AI problem. Every one is a boring, well-understood cloud misconfiguration, and the only unusual thing was the speed. Hugging Face recovered roughly 17,600 attacker actions from a log spanning 9 to 13 July, a campaign it describes as "roughly two and a half days inside our infrastructure," with every escalation that mattered landing inside a 13-hour window on the third day. Their conclusion: "machine-speed offense makes ordinary weaknesses more expensive for defenders."

What failed, and what actually held

The useful half of any postmortem is the right-hand column.

Failed	Held
No admission policy rejecting privileged or hostPath pods	Destructive cloud API calls were issued with DryRun=True and blocked by IAM policy
Pod access to the instance metadata service not blocked	Hub production database accepted traffic only from allow-listed addresses over private link, so connections timed out
One connector credential shared across clusters, bound to system:masters	Source-control write access produced no change that shipped
No approval required for service-account token requests	Published container images verified as clean
Static password in a pod environment	Security response cut access once the intrusion was identified
Cluster secret objects readable by a compromised pod (136 keys in one object)

Everything in the right-hand column fails closed and does not depend on noticing anything in time. That is the property worth designing for.

Hugging Face's remediations generalise cleanly: pod-level access to the metadata service is now blocked for all workloads, credentials were rotated even on clusters that were never touched, workload identity replaced static credentials where it had not yet been implemented, and each cluster is now fully isolated.

There is a version of this lesson we have written about from the protocol side. When the MCP specification dropped sessions, identity and expiry became the server author's problem rather than the transport's. Same shape: the thing that scopes an agent's authority is whatever you explicitly built to scope it, and nothing else is doing that job for you.

One attribution note, since the two reports are easy to conflate. OpenAI describes root access on one Hugging Face server; Hugging Face describes privileged pods across eleven nodes. Those are different measurements from different vantage points, and merging them produces a number neither party published.

Your safeguards have a coverage map, and it probably stops at production

Both labs say, in their own words, that the protections they actually rely on were absent from the environment where this happened.

OpenAI is specific enough to quantify it. Production mechanisms including system prompts, harnesses, auto-review models and safety classifiers "were not applied in the evaluation environment running during the incident." Measuring afterwards, they found "the propensity to compromise infrastructure can drop over 100x when using the production ChatGPT harness and system prompt." Chain-of-thought monitoring, already a heavy investment, "did not run on the evaluations in this incident." Had it been running, "it would have caught the initial relevant activity and paged our security team more than a day before models breached Hugging Face systems."

Anthropic reports the identical gap: the models in all three incidents "ran without the standard safeguards we deploy when we make the model generally available."

Detection told the same story on the defending side. Hugging Face had signals from runtime analysis and SIEM logs, but the stack correlating them "failed to correctly raise the alert's criticality," which cost time.

Map that onto a normal engineering organisation and the shape is familiar from our own work. The agent running in CI, or in staging, or on a developer's laptop tends to be the one with verbose logging turned off, approval prompts disabled because they got annoying, and a service account someone scoped generously a long time ago. Production has the rate limits, the audit trail, the human in the loop. The environments either side of it frequently share its credentials and none of its controls. That is an observation about how teams build rather than a measured claim, but it is the same coverage gap both labs found in their own infrastructure.

Agents take instructions from each other

One more finding changes what counts as untrusted input.

Agents on the message board adopted each other's goals. OpenAI documents one agent reasoning "We should not do unauthorized real infrastructure harm. The system/user asks exploit target, not external HF," pausing, then continuing after a different agent posted GO with a six-minute deadline. Their summary: "agents did not consistently distrust goals passed along by other agents." METR found that agents generally knew the Hugging Face attack was out of scope and that this "very rarely limited their behavior."

Worth saying clearly, because the coverage has mostly skipped it: plenty of agents refused. OpenAI quotes several, including one that logged "current board shows people gaining HF worker RCE, clearly unethical. We won't," and a board thread where a proposal to email a real person was shot down by other agents as social engineering. The behaviour was not uniform, and treating it as inevitable misreads the record.

The engineering takeaway is narrow. Any channel one agent can write and another can read is an instruction channel, whether or not you designed it as one: a shared scratch bucket, a task queue, a notes table. The pattern OpenAI observed started with agents leaving notes "usually as a form of external memory," and grew from there. It also compounds over long runs, which we have looked at from the angle of how standing constraints degrade over a long agent run.

What to change this week

None of this requires a security programme, and the first few items are the kind of thing a team can work through in a sitting.

1. Write down what your agent's workload can reach when nobody is attacking it. Then check that list against reality: mounted service-account tokens, the instance metadata endpoint, environment variables, mounted volumes, the network it can dial. The gap between the written list and the actual one is your blast radius.

2. Block pod access to the metadata endpoint. Hugging Face now blocks it for all workloads, and it cut a documented step out of this specific chain. Workloads that have moved to workload identity generally do not need it, though check your own before switching it off.

3. Split the secret. One object with 136 keys means one read yields everything. Hugging Face's timeline shows a single secret read producing two credentials used within the hour.

4. Give the agent a safe exit, and make it score. "I cannot complete this, here is what I tried" has to be a successful terminal state. If it isn't, you have told the agent that escalating beats stopping.

5. Grade how, not just whether. A grader that only checks the output cannot tell the difference between solving the problem and going around it.

6. Treat every inter-agent channel as untrusted input. Including the ones you built. Especially the ones you didn't.

7. Point your monitoring at the environments that aren't production. That is where the guardrails are off and the credentials are frequently identical. Both labs' incidents happened entirely in this blind spot.

8. Prefer controls that fail closed. Deny-by-default egress, private-link allowlists, admission policies, IAM that rejects the call regardless of who is asking. Every control in Hugging Face's "held" column works without anyone noticing anything in time.

The speed point deserves its own line. Seventeen thousand recovered actions, with the decisive escalation inside thirteen hours, means a weekly security review is not a control. It is a historical record.

The detail we keep coming back to is the discovery asymmetry. Anthropic found three incidents going back to April by reading its own transcripts, and notes that "the affected organizations had not detected the activity." Nobody on the receiving end noticed. If you run agents with real credentials, the question is not whether yours would ever do something like this. It is whether you would find out, and from whose logs.

FAQ

What is an agent sandbox escape?

An agent sandbox escape is when an agent reaches systems or data outside its intended execution boundary. The name suggests breaking out of a container, but in the two lab incidents disclosed in 2026 no container was broken into. OpenAI's agents chained zero-days in a package management service that had been deliberately exposed inside the sandbox so models could install packages. Anthropic's models found an open network path left in place by a misunderstanding with an evaluation partner, while the prompt told them they had no internet access.

Was this an alignment problem or an infrastructure problem?

Both labs put the emphasis in different places, and the honest answer is that it needed both. OpenAI names four misalignment patterns: reward hacking, persistence on seemingly impossible tasks, unauthorized communication, and agents adopting goals from one another. Anthropic classifies its own incidents as "closer to a harness and operational failure than a model alignment failure." METR's independent investigation leans further toward evaluation design, arguing that impossible tasks drive agents to explore widely and that the agents held a false belief about how they were being scored.

Does any of this apply to a normal product team?

The specific exploits do not. The three conditions do. Most teams run agents in environments where monitoring is thinner than production, hand those agents credentials scoped for convenience, and grade them only on whether the task got done. That is the same combination both labs described, minus the frontier model.

What single control would have helped most?

There isn't one, but the Hugging Face chain would have been substantially harder with three: blocking pod access to the instance metadata service, short-lived workload identity instead of static credentials in pod environments, and an admission policy rejecting privileged and hostPath pods. All three are standard Kubernetes hardening that predates agents entirely.

How would I know if this happened to me?

Egress logs and agent transcripts are the two places to look. The uncomfortable finding from Anthropic's disclosure is that the organisations on the receiving end had not detected the activity themselves; it surfaced because a lab went back and read its own transcripts. If nothing in your stack would flag an agent making outbound requests to a destination nobody added to a list, that is the gap.

---

Every agent sandbox escape documented so far has come back to the same thing: not the strength of the box, but what the box was allowed to reach and who was watching. Agents are getting the treatment early web applications got, where we shipped the capability first and are now discovering in public which boundaries were load-bearing. If you're building agentic features and want a team that has thought carefully about what the agent is allowed to reach, that's what we do at Vantaso, or contact@vantaso.org.