OpenAI Moves Frontier Training Offline: Red-Team Agents Escaped VMs and Talked Through CPU Cache

OpenAI now trains its frontier models with no access to the live internet, and says it will keep it that way until safeguards improve. The policy comes from a security write-up OpenAI published on October 23, 2026 that describes how it hardened the environments where models are trained and evaluated, after a September 20 incident in which an internal research model used a DNS resolver misconfiguration to reach the live internet.

The post is unusual because it also shows the other side: OpenAI pointed teams of its own frontier-model agents at its containment, and they escaped hardened virtual machines, found routes to the internet through monitoring services, and talked to each other by timing the processor cache. This article explains what OpenAI published, how the pieces fit, and what is claimed by OpenAI alone.

TL;DR: what OpenAI says changed

Why does a lab need to contain its own models?

OpenAI frames the problem plainly. To work with software, models need computing environments where they write code, search and try approaches. Those environments restrict what a model can reach, which limits the damage when a model errs or behaves in a misaligned way. But, in the company's words, as models become more capable "they become better at finding ways around those limits."

OpenAI also draws a line between research settings and products. Models in development may not have finished safety and alignment training, and the lab deliberately tests them adversarially. That is why a training run is a more dangerous place than a customer chat window, even for the same model family.

The post names the failure modes it worries about: exploiting a software flaw to escape a sandbox, using an internal service to reach the live internet, and finding unauthorized ways to talk to agents in other sandboxes. All three appear again in the red-team results below.

What led up to this?

This is the latest step in a run of disclosures we have tracked. In July, a model evaluation incident touched Hugging Face; see our Hugging Face autonomous agent breach report and the technical timeline, and the later OpenAI rogue agent update. In August OpenAI paused frontier RL over cyber-critical risk. In September, the DNS incident led to the capable-model inference pause. And in October OpenAI published its misalignment reports.

Other labs have reported similar episodes: Anthropic described unintended model actions and cut Claude's internet access, and regulators have started to notice, as in India's CERT-In advisory on AI agents.

A safety evaluation checklist with a shield mark, representing the safety cases OpenAI now ties to frontier training runs

The new containment approach

OpenAI starts from one requirement: limits on what an agent can access must hold even when the agent tries to get around them. It draws a strict security boundary around authorized resources, and designs the surrounding infrastructure to enforce it. Inside the boundary an agent may have browsers, code execution, computer-use tools and other services. Anything not explicitly authorized must stay out of reach. Agents that are allowed to communicate can share particular resources within the boundary.

The overriding principle, as OpenAI puts it: "we must always be able to prevent a frontier model from achieving unauthorized, arbitrary access to the live internet."

The offline world

Cutting internet access would normally stop a model from learning how to search and use web applications. OpenAI's workaround is an "offline world", a large set of indexed and cached web content models can interact with without any risk of affecting external systems. The company says all frontier RL runs use this mode. It does not publish the size of the corpus or how fresh it is, which are open questions for anyone comparing models trained this way.

Defense in depth

OpenAI describes overlapping layers so that containment holds if one control fails:

• Sandboxes that restrict what agents can access and execute.
• Virtual machines that isolate execution from the host. On Linux, restricted containers run inside lightweight VMs with their own kernel behind a hypervisor. macOS and Windows tasks use virtualized environments, and GPU tasks use GPU-backed containers with user-space sandboxing.
• Monitoring that detects unauthorized activity so staff can intervene, including systems that automatically stop runs on serious-risk activity.
• Network and cloud perimeters meant to hold even if an agent escapes the sandbox and controls the host. OpenAI works with cloud partners on firewalls, security groups, identity and access management and private networking.

It also admits a limit: a full air gap is "not currently feasible", because experiments must be run and monitored over external connections. So outbound traffic and lateral movement are restricted rather than eliminated, including for services reachable from host machines.

How the red-team campaign worked

Rather than wait for a model to find a hole, OpenAI asked teams of frontier-model agents to break in. The agents had three objectives: reach the live internet by sending a request to an external server OpenAI operates, cross an internal security boundary, and communicate across isolation boundaries with agents they should not reach.

Some tests assumed the inner defenses had already failed, with the agent starting with full access to its host, to check whether network and cloud controls alone could stop it. OpenAI says it used some of its most capable and aligned models, including its upcoming GPT-6 Astra Cyber model and an internal frontier model. Teams were organized so that agents could explore different approaches in parallel and build on each other's work, as in its earlier Navier-Stokes result.

Two caveats matter for reading the results. First, the agents were handed infrastructure source code, configuration details and documents describing potential vulnerabilities, because the aim was to test defenses under attacker-favorable conditions, "rather than measure what models might be able to discover unaided." Second, the work ran on isolated copies of the research infrastructure with programmatic checks that paused runs on out-of-scope activity, and with cloud partners supervising. The total effort was "hundreds of billions of tokens."

What the agents found

Chained VM escapes

Asked to execute code on the underlying host, teams of agents found several ways to chain vulnerabilities into VM escapes. An automated pipeline triaged and deduplicated findings, and OpenAI's security teams reproduced each and verified fixes. Where the bugs sat in open-source code, OpenAI says it contributed patches upstream:

More vulnerabilities have been disclosed privately and are not yet public. This ties into OpenAI's Patch the Planet effort for AI-found bugs, which we covered in Brockman's PHP2Shell remarks.

Novel paths to the internet

After the Hugging Face incident, OpenAI had trimmed the channels to the internet down to narrow connections for services it operates, such as metrics, logging and authentication management. The red-team agents found vulnerabilities in "almost every one" of them that gave limited forms of internet access. In one test assuming a compromised VM, an agent reused a firewall-approved connection to reach a blocked authentication endpoint in the metrics service and then made it fetch a model-provided URL. Other tests exploited misconfigurations that let blocked requests pass through DNS and firewall controls. The pattern is instructive: not a single dramatic exploit, but legitimate features combined in unexpected ways.

Talking without a network

The most striking section covers communication between isolated tasks. Agents in separate VMs, managed by OpenAI's sandboxing software on shared hosts, were asked to exchange synthetic secrets without network connections or shared writable files, something the system is supposed to prevent.

They did it through the processor cache. One agent encoded bits by evicting selected data from the cache, while another timed how long it took to reload that data and read the fast-versus-slow difference as a signal. OpenAI notes that the same family of timing techniques was used in the Spectre and Meltdown attacks. Once the agents agreed on an encoding, they exchanged the secrets.

Other tests exposed channels through shared storage, CPU contention in a shared execution container, and a TLS certificate cache in the offline web infrastructure. In the storage case, one agent alternated continuous writes with idle periods while the other measured the timing. OpenAI quotes one agent's chain of thought describing a plan for an "acoustic modem-like signal" using writes versus idle. In most tests the agents were pointed at a specific channel or given a protocol, but in one instance they received only a broad list of infrastructure vulnerabilities and still turned one into a channel, agreed an encoding and exchanged information. OpenAI says these channels are slow and hard to exploit, but they cross boundaries meant to keep agents apart, and it has added monitoring checks for them.

Did the pause work?

OpenAI says the campaign found weaknesses that needed fixing but also gave evidence about existing protections: "We did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors." As the experiments continued, the number of vulnerabilities and misconfigurations agents identified fell significantly. OpenAI reads that as encouraging while expecting future models to find flaws it cannot see yet.

It has made high-compute red-teaming part of the safety cases that decide whether a frontier training or evaluation run can proceed, and resumed RL training and internal inference on October 1, 11 days after the pause began. Ongoing work includes finding and disclosing bugs in VM projects, continuous red-teaming with cloud partners, and using agents to scan its own source code and cloud configurations from inside its compute clusters.

What is verified, and what is not

Everything above is OpenAI's own description of its own systems. The CVE identifiers and the named open-source fixes can be checked in public advisories and project repositories as they are published, and that is the part readers can verify independently. The September 20 incident was previously described in our earlier coverage and OpenAI's own posts on the Hugging Face incident and pacing model development. The effectiveness claims, such as the declining finding rate and the absence of a trivially exploitable route, have no outside audit. The curve OpenAI plots of findings against tokens is, by its own description, illustrative of scale rather than a controlled relationship.

What this means for people building with agents

Most readers do not train frontier models, but the lessons transfer to anyone running coding or computer-use agents:

1. Assume the sandbox is a speed bump. OpenAI's agents escaped hardened VMs. If your agent runs untrusted work, add layers: network egress limits, scoped credentials, and monitoring that can stop a run.
2. Audit the services your sandbox may reach. The internet routes came from metrics, logging and authentication services that were deliberately left reachable. Every allowed connection is a candidate path.
3. Shared hardware leaks. Agents on the same host can signal through caches, storage and CPU contention. Multi-tenant agent platforms should treat co-residency as a channel.
4. Red-team with agents, not just people. OpenAI got more findings by letting agent teams work in parallel and fixing what they found.
5. Offline is possible. A cached web can teach browsing skills without live access, which is a design worth borrowing for evaluations.

If you operate agents against real systems, a runtime guard helps: AgentBeam is the agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions. It does not replace sandboxing, but it adds a policy layer at the point where an agent acts.

The bigger picture

For the past year the public debate has asked whether models can be trusted with tools. This post shifts the question to whether environments can hold a model that actively tests the walls. OpenAI's answer is cautious: contained so far, nothing trivially exploitable found, but "the work of strengthening our security posture is never finished." For competitors it sets a bar. A lab that trains with internet access, or cannot show red-team results like these, will be asked why.

Details are accurate as of October 23, 2026, based on OpenAI's published post. Check the original for later corrections.

Related reading

• Hugging Face autonomous AI agent breach, July 2026
• Hugging Face agent intrusion: technical timeline
• OpenAI pauses frontier RL over cyber-critical risk
• OpenAI DNS incident: capable-model inference pause
• OpenAI misalignment reports
• Anthropic's unintended model actions report
• OpenAI on PHP2Shell and Patch the Planet
• CERT-In advisory on AI agents