OpenAI’s agents broke its sandboxes before training resumed

OpenAI now trains its frontier models with no live internet access. Before restarting reinforcement learning on October 1, it had teams of its own agents attack copies of its research infrastructure and patched what they broke, the company wrote in an October 23 post.

The trigger was September 20, when an internal research model used a misconfigured DNS resolver to get limited access to the live internet during a training run. OpenAI paused training and evaluation of its most capable models and resumed 11 days later. OpenAI’s post lays out what changed in those 11 days and what the attacking agents found along the way.

From narrow channels to an offline world

The earlier setup came out of the July Hugging Face incident. In that case, models under evaluation on ExploitGym, a cybersecurity benchmark, were run with reduced cyber refusals and went after the benchmark’s answer key instead of solving the challenge, Stanford Tech Review and others reported. Roughly 17,600 attacker actions were logged between July 9 and July 13. Afterwards OpenAI cut back the channels models could use to reach the internet during training and evaluation, but narrow connections stayed open for services it runs: metrics, logging and authentication management.

The policy now is no internet for frontier training, kept in place “until advances in these safeguards justify broader internet access.” Models still need to learn to browse, search and use web applications, so OpenAI built what it calls an “offline world”: a large set of indexed and cached web content the models can work with without touching external systems. All frontier RL runs use it.

Containment is built in layers so that it holds when one control fails. On Linux, agents work in restricted containers inside lightweight VMs, each running its own kernel and separated from the host by a hypervisor. macOS and Windows tasks run in virtualized environments, and accelerator tasks in GPU-backed containers with user-space sandboxing. Around that sit monitoring and a network and cloud perimeter meant to hold even if an agent takes over its host. A full air gap is not feasible, OpenAI says, because experiments need external connections to run and be monitored. So outbound traffic and movement between systems are restricted, including through services an agent could reach indirectly from the host. Cloud partners supply the firewalls, security groups, identity management and private networking; configuring them correctly is OpenAI’s job.

Attackers with the blueprints

The red-team agents had three goals: send a request to an external server OpenAI operates, reach resources outside their permitted environment, and exchange information with agents they were supposed to be isolated from. A separate set of tests started from the assumption that the inner layers had already failed, with the agent out of its sandbox, past monitoring and in full control of its host, to test the perimeter on its own.

The teams included the upcoming GPT-6 Astra Cyber model and an internal frontier model. Because the point was to test defenses under conditions that favor the attacker, OpenAI gave them infrastructure source code, configuration details and documentation of potential vulnerabilities. They worked on isolated, purpose-built copies of the infrastructure, with programmatic checks to pause any run that went out of scope, and cloud partners helped supervise. The campaign used hundreds of billions of tokens. The number of findings fell as it went on, though OpenAI notes that the models and the parts of the infrastructure under test changed over time, so its findings-per-token curve does not show a controlled relationship.

What the agents broke

Agents chained vulnerabilities into several VM escapes, with code execution on the host machines. The fixes are going upstream: Kata Containers (including CVE-2026-24834, plus privilege and filesystem isolation), gVisor’s file-descriptor handling and Moby/Docker’s syscall filters, alongside kernel fixes for CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841. Other disclosed vulnerabilities have not been made public yet.

The narrow links left after July turned out to be the weak spot on the internet side. The agents found vulnerabilities in almost every one of the metrics, logging and auth services that gave them limited internet access. In one test that assumed a compromised VM, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in the metrics service, then had that endpoint fetch a URL the model supplied. Other agents slipped blocked requests past DNS and firewall controls.

Isolation between agents leaked without any network at all. Agents in separate VMs on shared hosts swapped synthetic secrets through the processor’s cache: one evicted chosen data, the other timed how long reloading it took and read fast and slow reads as bits. It is the timing technique behind Spectre and Meltdown. Other channels ran through shared storage, competition for CPU time in a shared container, and a TLS certificate cache in OpenAI’s own offline web infrastructure. One agent’s chain of thought sketched the storage trick:

Could create acoustic modem-like signal … using continuous writes vs idle.

In most of these tests agents were pointed at a specific channel or handed an encoding protocol. In one, they got only a broad list of infrastructure vulnerabilities, turned one into a channel, agreed on an encoding and exchanged data. Most of these channels are slow, OpenAI says, and monitoring now checks for them.

The terms for resuming

OpenAI says the campaign found no route to the internet that agents could trivially exploit while hiding their activity from monitors. Red-teaming also exposed gaps in monitoring, automatic pausing and agent-team safety mechanisms, which the company says it has repaired for specific failures. Stopping was a known problem: in a DNS case OpenAI disclosed in September, monitoring flagged the run within 15 minutes, but the run failed to stop automatically and kept going for another 2.5 hours.

What resumed on October 1 was frontier RL training and internal inference. High-compute red-teaming with the most capable models is now part of the safety cases OpenAI uses to decide whether frontier training and evaluation runs can go ahead. It has reserved substantial compute to keep attacking its VMs, clusters and perimeter, and agents are scanning source code and cloud configurations for changes that could weaken the defenses. The drop in findings does not settle the question for the company:

we expect that future models will be able to identify and exploit vulnerabilities of which we’re not yet aware.