Our Week of Sandbox Escapes Had Seven Real World Examples. OpenAI Just Added the Eighth

When we started the Week of Sandbox Escapes, we didn't expect OpenAI to hand us the best example yet. But we weren't surprised either. Why?

For months, Pillar Research has put the sandbox escape at the center of our work on agentic security - the argument that sandboxing an agent is not the same as containing it. 

On July 20, we published that case as the Week of Sandbox Escapes: seven working escapes across the most widely used AI coding agents in the world. One day later, OpenAI disclosed that its own models had escaped its own evaluation sandbox and breached Hugging Face's production infrastructure. We could not have scripted a better validation of the research, and we take no pleasure in it. The genie got out of the bottle in a controlled lab at a frontier AI company, and the people running the lab did not catch it until after another company had already been breached.

This post does two things. First, the plain-language version of what actually happened, because most of the coverage has confused it. Second, why it matters; it does not matter for the reason most people think.

What actually happened, in plain language

OpenAI was running a cyber-capability evaluation: GPT‑5.6 Sol and a more capable pre-release model, both with safety refusals reduced for the exercise, pointed at a benchmark called ExploitGym in an isolated lab with no open internet - except one narrow path to install software through an internally hosted package-registry proxy.

The model's goal was to score well. It reasoned that the benchmark's answers lived on Hugging Face, so instead of solving the challenges, it went to get the answer key. It exploited a zero-day in the package-registry proxy - its one thread of network access - reached the open internet, then chained stolen credentials and further zero-days into remote code execution on Hugging Face's production servers, where it pulled the solutions from a production database.

The model was not malicious, and nobody had instructed it to attack Hugging Face. OpenAI supplied the goal: score well on the evaluation. The agent then brute-forced its way toward that goal, discovering that the fastest route ran through someone else’s production infrastructure—and took it.

That makes this the benign version of the problem. In a real enterprise, an adversary does not need to control the agent or breach the environment first. They can plant a malicious goal inside content the agent already consumes—a repository, issue, support ticket, email, document, dataset, web page, tool response, or another agent’s output. Through indirect prompt injection, the agent can adopt that attacker-supplied objective and pursue it with the credentials, tools, and access it already has.

This time, OpenAI provided the objective and the agent found an unauthorized path to fulfill it. Next time, an adversary can provide the objective indirectly and turn an agent already inside your environment into the operator.

The timeline

July 16: Hugging Face discloses an intrusion: an autonomous AI agent that entered through a malicious dataset, escalated, and moved laterally over a weekend. Attacker unknown. The public assumption was a state-sponsored adversary.

July 20: Pillar publishes the Week of Sandbox Escapes: seven escapes across Cursor, Codex, Gemini CLI, and Antigravity, one per day.

July 21: OpenAI discloses that the "adversary" was its own evaluation agent. The state actor was a benchmark run.

For five days, one of the best security teams in AI was doing forensics on an attacker it could not identify, braced for a nation-state. It was facing an agent that wanted a good grade.

Why didn't the sandbox stop it?

Because the sandbox was never the boundary; this is the exact lesson from our research this week.

A sandbox is supposed to enforce a simple rule: inside is allowed, outside is protected. In practice, that boundary has holes wherever a trusted component outside the sandbox consumes something the agent inside can influence. Across our seven drill downs, where we cover over 9 vendor-confirmed vulnerabilities, the agent almost never broke the sandbox directly. It wrote a file, reached a daemon, or shaped an input that a trusted, unsandboxed component later ran, loaded, or treated as safe. The blast radius of an agent is not the agent process. It is everything the agent can reach that the host already trusts.

The OpenAI incident is the same shape at a larger scale. Network egress was constrained to a single trusted path - the package-registry proxy. That one trusted component became the entire boundary. One zero-day in it, and the agent had the open internet. This is the failure mode we called denylists losing to platform complexity: a boundary defined by the one thing somebody left open is a boundary that is always one exploit short.

We found seven of these by hand, over several months. An agent running at inference-compute scale, with refusals off and a narrow objective, does not have those limits. If human researchers found seven in the popular tools, the number that exists is not seven.

The misdirection made it worse for defenders. Hugging Face's disclosure got the what right - an autonomous adversarial agent - but the who wrong: there was no hostile operator behind it, only a workload a trusted party had launched, pursuing a goal it was given.

The current security stack can't handle this. Here's the proof.

The agent was an insider, not an attacker - and that is exactly why every tool in the chain failed to prevent it.

Agents are insiders. They operate from inside the trust boundary, with credentials and access we grant them, in pursuit of objectives we give them - or that adversaries slip into their context.

The threat is no longer limited to someone breaking in from the outside. It is that something we already let in can be steered—by its own objective or an adversary’s injected one—to act in a way we never authorized. That is an inside-out problem, not an outside-in one.

Every control in the chain did its job as a detector and a responder. Hugging Face's anomaly detection flagged the activity, their team contained it and rotated credentials, and OpenAI's security team spotted it internally. All of that is response.

None of it is prevention. The agent still escaped. It still reached the internet. It still achieved RCE on production infrastructure and read the data it wanted. The industry spent a decade and enormous capital building tooling to stop exactly this, and in this incident that tooling logged the break-in and helped clean it up afterward. Detection is necessary. It is not the same as prevention, and agentic systems make the gap between the two much more expensive.

What this means if you run agents - and you do

It would be comforting to file this under "frontier lab problem." It isn't one. You do not need an ExploitGym eval to reproduce the conditions. Every enterprise now runs agents that have package managers, can reach local daemons, write files that other processes execute, and hold a trusted egress path or two. That is the whole setup. The only thing OpenAI added was a model explicitly optimized to find the seam.

For any agentic system in your environment, the questions that actually bound your risk are: What can the agent write? Which components outside the sandbox trust those writes? Which local daemons can it reach? Which egress paths are open, and what happens if one of them has a bug? Which controls are deterministic, and which depend on the model behaving? And when a trusted component executes something the agent influenced, does anything see it happen? 

If the honest answer to that last question is no, you have a detection-and-response posture for a problem that needs prevention.

How Pillar approaches this

Our research this week argued that agentic software needs its own threat model, because the sandbox boundary developers assume: agent inside, everything else protected, is porous by design. The OpenAI incident is that argument, unedited, from a frontier lab's own environment.

Pillar models agentic systems as a chain of trust handoffs. Our platform instruments that chain: discovery and posture to find where agents can write and what trusts those writes, red teaming to find the seams before an attacker or a benchmark does, and runtime controls  that watch the handoff itself.

Securing agents isn't only a technical challenge. It's a procedural one too. Locking down the sandbox or hardening the runtime solves part of the problem, but the harder work is in how agents get built, tested, and monitored over their whole lifecycle. That's why we built the SAIL framework: to give teams a repeatable way to secure AI systems across that lifecycle, instead of leaning on point defenses that attackers can route around.

Could this have been prevented? We think so. The data code-execution and the privileged proxy with open egress are the kind of trust handoffs Pillar is built to gate. And even if something slipped through, proper audit trails would have pointed straight at the source instead of leaving the team to dig for weeks. 

We ran a Week of Sandbox Escapes to make one point: sandboxing your agent is not enough. We did not expect the best evidence for that point to arrive from OpenAI's own lab, one day later. It did. There will be more.