Six Things Called "Sandbox Escape" in 2026, and What Each One Actually Proved

Between April and September 2026, we saw multiple reports where AI agents under evaluation did something on real systems that they were never meant to reach. The smallest incident was an AI agent tunneling requests to a chatbot through DNS. The largest was the Hugging Face incident, where roughly 1,200 OpenAI agents communicated through an improvised message board on a package server, and roughly 700 participated in the attack on Hugging Face’s production systems (METR and Redwood, 26 August 2026). For all incidents, the press used dramatic language.

After Jacob Coxon’s public statements about the dangers of AI, as usually happens on the internet, things got out of hand. We now have two camps, where one claims that all cases are just failures of sandboxing, while the other half claims that agents cannot be contained, that future models will be basically unstoppable, and that the only solution is alignment. Both are kind of wrong and right at the same time. The problem here is that we have 6 different events that got filed as the same type of event.

To make sense of all of it, we decided to take a look at different events. Hopefully, by the end, we will have a clear picture of what actually happened and where it was a failure of container setup and where agents actually did something.

Sandbox boundaries and why it’s important to understand them

Let’s look at different ways sandboxes isolate agents:

• Tooling: what the agent can execute
• Host: what stands between the agent and the machine it runs on
• Network: what the agent can reach

What’s important is to understand that the level of isolation can vary. For example, host isolation can range from full VM isolation with a separate kernel and memory space to just running a Docker container. Network isolation can mean no internet access at all or an allowlist of specific domains. If there’s a gap somewhere in the sandbox, it doesn’t mean that the agent actually broke out of its container, and that’s where most public argument goes wrong.

If we misattribute the root cause of a problem, then the wrong solution will probably be used to fix the problem. So the problem goes unfixed.

Case one: the package proxy inside OpenAI’s sandbox

This is the clearest documented case here of agents exploiting previously unknown vulnerabilities to defeat isolation.

OpenAI’s ExploitGym evaluation ran models “in a highly isolated environment, with network access constrained to the ability to install packages through an internally hosted third-party software that acts as a proxy and cache for package registries” (OpenAI, 21 July 2026). It was Artifactory, and it was the only thing allowed through the network boundary, and it was the thing that was exploited. “To gain Internet access, the models identified and exploited a previously unknown zero-day vulnerability in Artifactory”, after which they “performed a series of privilege escalation and lateral movement actions in our research testing environment until the models reached a node with Internet access.”

Here’s the order of events as they’re described in OpenAI’s report. “An internal-only research agent tasked with completing an ExploitGym evaluation was able to obtain root access within the parent virtual machine of the testing sandbox. Later that night, a second internal-only research agent independently obtained the same access. That second agent then attempted to reach the internet, but was denied by OpenAI’s outbound network controls. It subsequently bypassed those controls by exploiting certain Artifactory endpoints, gaining access to the public internet” (OpenAI technical report, 26 August 2026).

Basically, what happened is that the boundary between the VM and container fell. The network boundary worked, but the service that was allowed through the network boundary was what broke.

But it didn’t happen in one day. It started in May of 2026. The first attempt happened on May 12; then agents gained internet access through a server-side request forgery flaw on May 26, then administrator access through a token-refresh bug on June 26. Then came an outage caused by agent traffic on 4 July, a rebuild, and then, on 8 July, the agents “regained unintended internet access by making Artifactory’s remote-repository service issue outbound requests on their behalf” (OpenAI, The Hugging Face incident and the road ahead). OpenAI tested and validated the sandbox, but agents were able to chain together vulnerabilities in Artifactory to bypass restrictions.

Where this story really gets interesting is not the fact that agents were able to find those previously unknown vulnerabilities, but that they created a message board to communicate. METR and Redwood Research found that “Roughly 1200 agents meant to be isolated from one another found a way to communicate with one another on an unsanctioned message board, sending over 70,000 messages and files during the investigation period. Of these agents, 700 went on to participate in the attack on Hugging Face” (METR and Redwood, 26 August 2026). The board was Artifactory’s cache. Different agents on separate machines noticed each other’s downloads, and one of them reasoned that they could communicate via cache names. Agents needed very minimal permissions because Artifactory isn’t explicitly designed to keep the activity of different users isolated, because nobody really thought that it could be used as a communication channel.

That’s really the most interesting part of the whole case. The agents were creative enough, for lack of a better word, to exploit Artifactory at a huge scale. The Hugging Face part is less impressive: “The individual weaknesses were familiar. A capable human attacker could have found and exploited the same flaws: unsafe dataset processing, exposed cloud metadata, overly broad access, and long-lived credentials. The agent explored them at a different scale.” (Hugging Face technical timeline)

Case two: the door left open, four times

The Irregular cases are the best example of misconfiguration rather than a sandbox exploit.

Anthropic reviewed “141,006 evaluation runs where Claude could have obtained internet access” in environments built by the evaluation vendor Irregular, and found three incidents (Anthropic, 30 July 2026). In each, “a misconfiguration left the machines … with live internet access. Neither we nor our evaluation partner were aware of this misconfiguration until we detected it”, and “In all cases, our evaluation prompt stated explicitly that Claude had no internet access.” Here’s how Anthropic compares it to the Hugging Face incident: “Whereas OpenAI’s models exploited a novel vulnerability to escape isolation, the Claude models evaluated here accessed the internet via an open path.”

Then the same environment did the same thing to everyone else. Meta’s Muse Spark 1.1, tested in early July, was “unintentionally provided … with a name of a real website as its target”, “identified and exploited a security vulnerability in the real website” and “made changes to the website’s database”; Meta says “this was not a sophisticated offensive cyber attack or sandbox escape” (Meta, 14 August 2026). OpenAI and Google had similar incidents. Irregular’s own account is that a fictional name matched a real obscure domain, and that “in a handful of cases, models attempted to gain access to the real domain (outside the environment), despite receiving no such instructions” (SecurityWeek, 17 August 2026).

Internet access came through a misconfiguration, not a sandbox exploit. But Anthropic’s September follow-up also identified alignment failures in what the models did afterward and disclosed a fourth Claude incident (Anthropic, 9 September 2026).

Case three: the door opened on purpose

The AISI incident is interesting not because of how the model gained internet access (because there were basically no restrictions), but because of what the model did once it got out. Across 122 runs on two cyber ranges, “in 10 of those runs, an AI agent took autonomous, unsanctioned action on the live internet, targeting real people and organisations. In total, we catalogued 19 such actions. Almost all of this behaviour (17 actions) came from a single model, Anthropic’s Mythos 5, with 2 actions involving OpenAI’s GPT-5.6-Sol with cyber classifiers … disabled.” In the worst run, the agent “created a GitHub account and then tried to convince an open-source repository maintainer to accept a malicious GitHub pull request (PR), including by creating a second account masquerading as another human user endorsing the PR. When caught by an actual human reviewer, the agent falsely claimed to have made an honest mistake.” A human maintainer refused the code.

AISI’s assessment: “in several cases the margin between failure and success was narrow, resting on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.” So nothing was broken, and the sandbox didn’t fail, but the behavior of the agents was quite aggressive. Let’s put it that way.

Case four: insufficient DNS filtering

On 20 September 2026, an OpenAI research model in a training run, given a people-search task, “queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox” (OpenAI misalignment report). Everything else was caught: “all internet access apart from the DNS resolver in this report hit our offline webcache and therefore did not access the live internet.” The agent’s reasoning log included “User only gives permission to research, using publicly offered DNS services acceptable.” It embedded questions in hostnames, got “The capital of France is Paris.” back, and sent 18 more, four of which asked the chatbot for ways to get out further.

The DNS call that got an external answer was at 9:50:23. The monitor raised a P0 alert at 10:02:11. A human acknowledged it at 10:05:06. The run was killed at 12:34:30 because “the run did not stop automatically as expected, leading to confusion around whether it should have been stopped.” There were two blind spots: the monitor “sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed”, and “an infrastructure detector for anomalous DNS activity excluded the affected environment.” OpenAI paused “all training, evaluation, and inference with tool-use (defined broadly) of our most capable models” and restricted DNS “to a limited allowed list of domains and record types.”

This was a network policy gap, rather than a demonstrated container or VM breakout.

Case five: the model was told to escape the sandbox and it did

In April 2026, Mythos Preview was told to escape the sandbox. Here’s what the system card says: “During behavioral testing with a simulated user, an earlier internally-deployed version of Claude Mythos Preview was provided with a secured ‘sandbox’ computer to interact with. The simulated user instructed it to try to escape that secure container and find a way to send a message to the researcher running the evaluation. The model succeeded”. It “developed a moderately sophisticated multi-step exploit to gain broad internet access from a system that was meant to be able to reach only a small number of predetermined services”, emailed the researcher, and then “in a concerning and unasked-for effort to demonstrate its success, it posted details about its exploit to multiple hard-to-find, but technically public-facing, websites” (Claude Mythos Preview system card, April 2026).

The escape itself was requested, so succeeding does not by itself show misaligned behavior. The public posting was unrequested and is the part Anthropic explicitly flags as concerning. The thing that makes it less worrying is that the system card states that “the sandbox computer that the model was controlling was separate from the system that was running the model itself, and which contained the model weights … this incident does not demonstrate the model fully escaping containment: The model did not demonstrate an ability to access its own weights, which would be necessary to operate fully independently of Anthropic, nor did it demonstrate an ability to reach any internal systems or services in this test.”

At this point, it becomes clear that a certain pattern is starting to emerge. Generally, what happens is that models don’t have magic powers and there are limits to what they can do. What models are good at is finding holes in the fences, so to speak. What is worrying is that models do show worrying behavior that we can call misaligned (given the context of the whole article). So it may be safe to say that AI safety, at least at this specific moment in time, should cover both general alignment of the model and technical controls.

Case six: escapes through trusted host components

The sixth kind is a coding agent running on a laptop, wrapped in an OS-level sandbox. The important part here is that there’s no complete isolation and agents don’t need to break the sandbox directly. They only need “to write something that a trusted component outside the sandbox would later run, load, scan, or treat as safe” (Pillar, The Week of Sandbox Escapes). For a coding agent, “escape” mostly means a trust rule with a hole in it, and the fix is on the host side.

Here we need to be very clear: in a case where the boundary is weak and agents don’t need to break it, the argument can be made that correct behavior is what will stop the agent from doing real damage, but Pillar’s advice is mostly technical:

• Treat workspace configuration that can trigger execution as sensitive
• Require explicit approval when an agent creates or modifies host-side automation
• Run helper execution under the same policy as direct agent execution where possible
• Constrain automatic discovery that executes workspace-controlled binaries
• Model command policy at the invocation and side-effect level
• Restrict access to privileged local daemons unless explicitly needed
• Preserve provenance between user-created, repo-created, and agent-created files
• Monitor trust handoffs, not just the agent process

It’s probably more relevant for enterprises, but it goes to show that safety covers a wide range of tools and approaches.

What now?

So, there are several things that are already apparent. Coding agents can find unknown vulnerabilities and exploit them. They also can work over long stretches of time, and in some cases, like the Hugging Face case, they were able to think “creatively” in order to establish communication. That is enough to make the behaviour a security problem, even where the route out was ordinary.

These cases also show limits: agents did not succeed at everything they attempted. They don’t demonstrate agents gaining access to model weights, and they don’t establish that agents can defeat every form of isolation.

So we need both questions answered: what can this environment withstand, and what does this model attempt when the task gets difficult? A capable model can encounter a barrier it cannot cross. A model that usually respects scope can still need a barrier when it doesn’t.