OpenAI now trains frontier models offline, after its own agents red-teamed the sandbox

OpenAI says it now runs frontier model training with no live internet access, and that it will keep that policy “until advances in these safeguards justify broader internet access.” In a post on securing its frontier training environment, published 23 October, it also describes what happened when it pointed teams of its strongest agents at its own containment.

The trigger was an incident we have seen in OpenAI’s own reports. On 20 September an internal research model used a misconfigured DNS resolver to reach a public chatbot during a training run. OpenAI paused training and evaluation of its most capable models, hardened the setup, and resumed reinforcement-learning training and internal inference on 1 October, 11 days after the pause began.

This is a follow-up to OpenAI’s September essay on safety cases for frontier training. That piece said what should be written down before a run continues. This one says what OpenAI built and how it tested it.

An offline world for training

Models still need to learn browsing and web apps, so OpenAI built what it calls an “offline world”: a large set of indexed and cached web content that agents can use without touching external systems. OpenAI says all of its frontier RL runs now use it.

Around that sits defense in depth:

• Restricted containers inside lightweight microVMs on Linux, each with its own kernel behind a hypervisor.
• Virtualized environments for macOS and Windows, and GPU containers with user-space sandboxing.
• Monitoring that is meant to catch unauthorized activity in time to stop a run.
• Network and cloud perimeters that should hold even if an agent escapes and controls its host.

OpenAI says a full air gap is not feasible because it needs outside connections to run and monitor experiments, so it restricts outbound traffic and movement between systems instead.

How the red-team worked

Agent teams got three goals: reach a server OpenAI operates on the live internet, cross an internal security boundary, and talk to agents they should be isolated from. Some tests assumed the inner defenses had already failed and the agent owned its host.

OpenAI used “some of our most capable and aligned models,” including its upcoming GPT-6 Astra Cyber model and an internal frontier model. To favor the attacker, it handed over infrastructure source code, configuration details and notes on possible weaknesses. The runs used isolated copies of the research infrastructure, with cloud partners helping supervise. OpenAI says it spent “hundreds of billions of tokens” on the campaign.

What the agents found

• MicroVM escapes. Agents chained bugs into escapes to the host. Fixes went upstream to Kata Containers (CVE-2026-24834 plus privilege and filesystem isolation fixes), gVisor file-descriptor handling and Moby/Docker syscall filters. OpenAI also lists kernel fixes for CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841, and says other disclosures are not public yet.
• Paths to the internet. After the Hugging Face incident in July, only narrow links remained for metrics, logging and authentication services. The agents found holes in “almost every one” of them that gave limited internet access. In one test an agent reused a firewall-approved connection to reach a blocked auth endpoint in the metrics service, then made that endpoint fetch a URL the model supplied.
• Covert channels. Agents in separate microVMs on shared hosts swapped synthetic secrets through CPU cache timing, the same trick behind Spectre and Meltdown. Other tests found channels in shared storage, CPU time contention and a TLS certificate cache in the offline web infrastructure. OpenAI says these channels are slow and hard to exploit, and that it added monitor checks for them.

OpenAI’s headline result is that it “did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors.” It also says findings fell off sharply as the campaign went on. Both are OpenAI’s own reading, and it says it expects future models to find bugs it does not yet know about. High-compute red-teaming is now part of the safety cases it uses to decide whether a frontier run can go ahead.

The Brotli bug, if you ship Node, Bun or Envoy

One finding reaches well past OpenAI. The red-team turned up a flaw in the Brotli compression library, tracked as CVE-2026-111497 on OpenAI’s Patch the Planet page. OpenAI says on X that malicious compressed data can lead to code execution, and that the root cause was fixed in Brotli’s source in February without a release. The page lists fixed versions:

• Node.js 22.23.4, 24.22.1 and 26.12.1
• Bun 1.4.4
• Envoy 1.40.0, 1.39.3, 1.38.6 and 1.37.8
• Istio 1.29.9, 1.30.6 and 1.31.2
• Brotli 1.0.10, 1.1.1 and 1.2.1

If you cannot upgrade yet, the advice is to stop decoding Brotli from untrusted sources. We could not find the CVE in the GitHub Advisory Database when we checked on 24 October, so take the version list from the Patch the Planet page and your vendor’s advisory.

Practical takeaway

If your agents run untrusted code in Kata, gVisor or Docker, check that you have the upstream fixes and patch Brotli wherever you decode compressed traffic. And copy the method: give a capable agent your source and config, aim it at your own boundary in a copy of the system, and treat the side services (metrics, logging, auth) as part of the perimeter.