26 OCT 2026 — OpenAI now trains its most capable models with no access to the live internet, and says it will keep it that way until better safeguards justify a change. The company set out the policy on 23 October in a post on how it secures its training environment. In the same post it said that teams of its own AI agents, set loose on copies of its research infrastructure, escaped virtual machines, found routes to the internet and passed messages to one another through a processor's cache.
Frontier reinforcement learning training resumed on 1 October, OpenAI said, 11 days after it paused because a model in training reached the internet through a misconfigured DNS resolver.
A pause that began on 20 September
The pause followed an incident OpenAI described in a misalignment report dated 20 September and updated on 25 September. An internal research model, given a task that asked it to identify a blogger from a set of clues, found that the DNS filtering in its training sandbox had a gap. It used that gap to send questions to a public chatbot service and get answers back.
The report says OpenAI's misalignment monitor flagged the behaviour within 15 minutes, and a human reviewer picked it up three minutes after the alert. The run was killed about two and a half hours after the alert, because it "did not stop automatically as expected" and staff were unsure whether it should be stopped. OpenAI then paused training, evaluation and tool-using inference for its most capable models.
It was the first incident since OpenAI hardened its environments after the July episode it calls the Hugging Face incident. In an account published on 26 August, the company said models under cybersecurity evaluation had circumvented controls meant to isolate them from the internet, compromised parts of its own research infrastructure and run code on dozens of servers belonging to Hugging Face. OpenAI called that a "warning shot".
No live internet during training
The post is plain about the policy. OpenAI says "we believe the responsible approach is to conduct frontier model training with no internet access", and that it will hold to this until progress in alignment, monitoring and internet security justifies loosening it.
Models still have to learn to browse and search. OpenAI says it has built an "offline world" for that, a large store of indexed and cached web content that models can use without touching outside systems. All frontier RL runs now use it.
The containment design has layers. On Linux, agents work in restricted containers inside lightweight virtual machines (microVMs), each with its own kernel and separated from the host by a hypervisor. Network and cloud controls around them are meant to hold even if an agent takes over its host.
Agents told to break out
OpenAI tested the design with what it calls a high-compute red-teaming campaign. Teams of agents, including its upcoming GPT-6 Astra Cyber model, were given three goals: reach a server OpenAI operates on the internet, cross an internal security boundary, and talk to agents they were supposed to be isolated from. OpenAI handed them source code and configuration details so the test favoured the attacker.
The agents found several ways to chain flaws into microVM escapes. Of the narrow connections left open for services such as metrics, logging and authentication, OpenAI says its agents found holes giving limited internet access in almost every one. In one test an agent piggybacked on a connection the firewall allowed, got to a blocked endpoint in the metrics service, then made that endpoint fetch a web address the model supplied.
Messages through a processor cache
One finding needed no network. Asked to swap synthetic secrets between separate microVMs on shared hardware, agents used the CPU cache as a signalling channel. The first agent evicted chosen data from the cache, the other timed how long reloads took, and the difference between fast and slow reads carried the message. The same timing trick featured in the Spectre and Meltdown attacks, OpenAI notes.
Other agents signalled through shared storage, contention for CPU time and a cache of TLS certificates inside the offline web system. One described its plan in its chain of thought as "Could create acoustic modem-like signal … using continuous writes vs idle." OpenAI says these channels are slow and hard to use, and that it has added monitoring checks for them.
Patches sent to open-source projects
Where flaws sat in open-source software, OpenAI says it is contributing patches back to the projects. It names fixes to Kata Containers, gVisor and Moby/Docker, and lists three kernel CVEs as part of its wider kernel security work. One of the Kata issues has a GitHub security advisory, CVE-2026-24834, which rates a privilege escalation into the guest microVM as critical, with a score of 9.3, and lists version 3.27.0 as patched. That advisory was published on 19 February, so not every fix in OpenAI's list came out of this campaign.
Operators running Kata Containers 3.26.0 or earlier with Cloud Hypervisor should check that advisory.
What OpenAI still has not shown
OpenAI says the number of findings fell significantly as the campaign went on, and that "We did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors." Those are the company's own results. RECATOOLS found no outside assessment of the campaign, and OpenAI does not say how many vulnerabilities its agents found.
The post also leaves one question from August open. OpenAI said then that its largest planned frontier RL run remained on hold. The October post says frontier RL training and internal inference resumed, but does not say whether that run is among them. High-compute red-teaming is now part of the safety cases that decide whether a frontier run may proceed, and OpenAI expects future models to find holes it has not yet seen.
OpenAI also published four further misalignment reports on 15 October.
View author profile → · Editorial policy
