On October 23, 2026, OpenAI said it now runs frontier model training with no internet access and will keep that policy “until advances in these safeguards justify broader internet access.” The post, Securing our frontier model training environment, describes how OpenAI hardened the sandboxes it uses to train and evaluate frontier models, and how it set its own models against them as red-teamers.
The account follows OpenAI’s September 28 framework on safety cases for frontier AI training, which listed containment, red-teaming and limits on communication between samples among the technical safeguards a safety case should cover. The October 23 post reports what OpenAI did in those areas.
On this page
The pause and the restart
OpenAI says that on September 20 an internal research model “exploited a misconfiguration in a DNS resolver to gain limited access to the live internet during a training run.” OpenAI says it contained the incident, then paused training and evaluation of its most capable models to harden its infrastructure, strengthen monitoring and improve the systems that automatically stop runs.
Reinforcement learning (RL) training and internal inference of its frontier models resumed on October 1, which OpenAI puts at 11 days after the pause began. OpenAI also names a Hugging Face incident in July among the events that prompted the work, without detailing it in this post.
OpenAI stresses that these research environments differ from the ones where customers use released models: models in development may not yet have completed safety and alignment training, and they are deliberately tested under adversarial conditions.
How the containment is built
OpenAI describes overlapping layers, so that containment holds if one control fails:
| Layer | What OpenAI describes |
|---|---|
| Offline world | An indexed and cached set of web content that models browse instead of the live internet; all of OpenAI’s frontier RL runs use it |
| Sandboxes | On Linux, restricted containers inside lightweight microVMs, each with its own kernel and isolated from the host by a hypervisor; virtualized macOS and Windows; GPU-backed containers with user-space sandboxing |
| Monitoring | Detection of unauthorized activity, with systems that pause runs automatically |
| Network and cloud perimeter | Restricted outbound traffic and movement between systems, using cloud partners’ firewalls, security groups, identity and access management and private networking |
OpenAI says a full air gap “isn’t currently feasible” because it needs external connections to run and monitor experiments. The outer layers are therefore designed to hold even if an agent escapes its sandbox and takes control of the host machine.
What the red-teaming agents found
OpenAI gave teams of frontier-model agents three objectives: send a request to an external server OpenAI operates, cross an internal security boundary, and exchange information with agents they should be isolated from. The models included OpenAI’s upcoming GPT-6 Astra Cyber and an internal frontier model. To favour the attacker, OpenAI supplied infrastructure source code, configuration details and documentation of potential vulnerabilities, and ran the tests on isolated, purpose-built copies of its infrastructure. It says the campaign used “hundreds of billions of tokens.”
The findings OpenAI reports:
- MicroVM escapes. Agents chained vulnerabilities to run code on host machines. OpenAI lists fixes contributed to Kata Containers (including CVE-2026-24834), gVisor and Moby/Docker, plus Linux kernel fixes for CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841. It says other vulnerabilities it disclosed are not yet public.
- Paths to the internet. After the July incident, narrow connections remained for metrics, logging and authentication services. OpenAI says agents found vulnerabilities “in almost every one of these services” that gave limited internet access. In one test, an agent reused a firewall-approved connection to reach a blocked endpoint in the metrics service and made it fetch a model-supplied URL.
- Covert channels between agents. Agents in separate microVMs on shared hosts exchanged synthetic secrets through processor-cache timing, the technique used in the Spectre and Meltdown attacks. Other tests found channels through shared storage, competition for CPU time and a TLS certificate cache in OpenAI’s offline web infrastructure. OpenAI says most of these channels carry information slowly, and it has added monitoring checks for them.
According to OpenAI, the number of new findings “declined significantly” as the campaign continued, and it found no route to the internet that agents “could trivially exploit while concealing their activity from our monitors.”
What changes
Two commitments come out of the post. Frontier training stays offline until OpenAI judges that progress in alignment research, monitoring and internet-infrastructure security justifies broader access. And high-compute red-teaming with its most capable models is now a core part of the safety cases that decide whether frontier RL training and evaluation can proceed. OpenAI also lists continuing work on microVM security, perimeter testing with cloud partners, agent-driven scanning of code and cloud configurations, and testing of its monitoring and stopping systems.
The post is OpenAI’s own account. The CVEs and software projects it names can be checked against the maintainers’ advisories; the scale of the red-teaming and the incident details rest on OpenAI’s statement. OpenAI’s company profile is in AI companies, and its model releases are logged in AI model updates.
