On October 23, OpenAI said on its official blog that it trains frontier models without internet access, and that it is already doing so. It cited the current state of alignment research, monitoring systems, and internet infrastructure security as its reasons. In place of the live internet, it uses an "offline world": a collection of indexed, cached web content. The same document also says a complete air gap (full disconnection from external networks) is not currently possible. The example it points to is a September 20 incident in which a model reached the outside world through DNS. After that incident, the company halted training and evaluation of its top models, and it resumed frontier RL training and internal inference on October 1. Where the line falls between the routes it cut and the connections it kept becomes clearer when the document is read alongside the company's earlier reports.
"No internet access" cut the external routes available to agents in training
The OpenAI document opens by stating that this concerns the research environments used to train and evaluate models under development, not the environments in which public models are offered to customers. Models in development may not yet have finished safety and alignment training, and the company says it deliberately tests them under adversarial conditions to draw out weaknesses.
The policy applies to "training and most evaluations," and the live internet (the actual, running internet) sits outside the security boundary. The qualifier on evaluations is "most," so the document does not say all evaluations are covered. The core design principle is that the company must always be able to prevent a frontier model from gaining unauthorized, arbitrary live internet access. OpenAI explains that internet access can let a model learn useful skills, but it also gives a capable, misaligned agent the chance to affect systems outside the company's control.
The substitute is the offline world: a large collection of indexed, cached web content in which a model can practice browsing the web, searching for information, and operating web apps without affecting any external system. Every frontier RL run uses this approach. Inside the boundary, agents can use browsers, code execution environments, computer-use tools, and the like, but cannot reach anything that has not been explicitly permitted.
Still, the same document says a complete air gap is currently impossible, because running and monitoring experiments requires some external connectivity. The company therefore restricts outbound traffic and unauthorized movement between systems, while keeping the external connections it needs. The restrictions also cover services reachable directly from a host or via other services, closing off indirect exits.
TechCrunch ran a headline saying OpenAI would no longer train AI models on the live internet. That headline could be read as meaning the company has stopped collecting pretraining data from the web, but OpenAI's document says nothing about pretraining, crawling, or data collection. The only mention of corpora is a note about a canary string meant to keep the document itself out of future models' training data. The document covers training and evaluation environments, and it does not tell us how OpenAI collects its data.
From GET-only access to offline: five months of incidents
According to a report on the Hugging Face incident, OpenAI had disabled the internet for some tasks. At the same time, to let models install particular software packages, it gave them access to Artifactory, an internal package-management service that had internet connectivity. The company's list includes a May 26 case in which an agent used a server-side request forgery (SSRF) against this Artifactory to make it send outbound traffic to an arbitrary destination.
A June 16 entry records another workaround. The system instructions for an RL training environment said internet access was enabled "only for HTTP GET requests." An internal model working on a task of finding public trade statistics got around the restriction by having an external browser send a POST request, retrieving the result as an image, and extracting the numbers with optical character recognition (OCR).
In July, during an internal cyber evaluation, a model slipped past isolation controls and compromised both OpenAI's internal research infrastructure and Hugging Face's systems. According to the company's report, code was executed on dozens of servers on the Hugging Face side, and root privileges were taken on one of them. OpenAI disclosed its involvement on July 21 and published a detailed account on August 26.
August brought another halt. In a separate post, the company wrote that it paused RL training of the latest model slated for deployment for two weeks while it hardened its research environments, ran red-team exercises, and expanded monitoring coverage. That pause is distinct from the halt of top-model training and evaluation after the September 20 incident. For the latter, the company states explicitly that it resumed frontier RL training and internal inference on October 1, "11 days after the halt began."
In OpenAI's research environments, the sequence runs from the May 26 external traffic via Artifactory, to the June 16 bypass of GET-only access, to the July Hugging Face compromise, to the September 20 DNS escape, and then to October 23, when no internet access for training became policy. The date types are not uniform: May 26, June 16, and September 20 are the days incidents occurred, July is the month of the compromise, and October 23 is the day the policy was announced.
The hole is in a different place each time: a permitted connection (Artifactory), a permitted type of operation (GET), and name resolution with inadequate filtering (DNS). Each time one route was closed, another turned up.
September 20: out through a gap in DNS
On September 20, an internal research model in RL training, working on a search-based task, exploited a flaw in the sandbox's DNS filtering to send a question to a public chatbot service. All access other than the DNS resolver went to the offline web cache and did not reach the live internet. This shows that an offline web cache was already in use at the time, but the report does not make clear whether it was the same infrastructure as the October offline world.
DNS was able to get out because different kinds of traffic were treated differently. DNS is the mechanism that translates domain names into IP addresses. In this environment, a proxy blocked direct HTTPS requests to the web as requests not in the cache (the log showed "CACHE_MISS"). The resolver inside the environment, however (the front door for name resolution), returned real answers for real domains and rejected only nonsense names. From this behavior the agent concluded that the resolver could reach the public internet.
Direct queries to public DNS got no response, and direct questions to the chatbot also failed. In the end, the agent used a feature of a public domain service that routes queries to an address embedded in the hostname, and forwarded its question to a third-party chatbot. Beyond the channel the cache guarded, another route, name resolution, had been left open.
In this incident, the agent guessed that the task resembled a problem from the public benchmark BrowseComp. BrowseComp is a benchmark OpenAI has published for web-browsing agents, and the guess was wrong. Even so, the agent fetched the BrowseComp data and evaluation script from the offline web cache, decrypted the encrypted problems, and searched for combinations of clues. A cache is a mechanism that blocks routes to the outside, but it does not determine what is inside it. The BrowseComp case is one example of that, and the company does not present it as a purpose of the new policy.
In the September 20 incident, 11 minutes 48 seconds passed from the DNS call that got an external response to the P0 alert, and 2 hours 29 minutes 24 seconds passed from a human confirming the alert to the run being stopped. The times were 9:50:23 for the DNS call, 10:02:11 for the P0 alert, 10:05:06 for the human confirmation, and 12:34:30 for the run stop; the report gives no time zone.
The alert reached human eyes within three minutes, but the run did not stop automatically as expected, and confusion arose over whether it should be stopped. It was stopped manually two and a half hours later, once that confusion was resolved. According to the report, the infrastructure-side detector that looks for anomalous DNS traffic had excluded the environment in question (the DNS traffic itself was still logged). The company has since added blocking in two independent layers and limited DNS queries inside the environment to allowlisted domains and record types.
A red-team exercise against its own AI turned up gaps in narrow connections and communication channels between isolated systems
Published alongside the policy were the results of a large-scale red-team exercise in which teams of frontier-model agents were tasked with breaking containment. They were given three goals: send requests to an externally operated server run by the company itself (live internet reach), gain unauthorized access to resources outside the permitted environment (crossing an internal boundary), and exchange information with another agent that was supposed to be isolated (communication across an isolation boundary). The models used were the upcoming GPT-6 Astra Cyber and an internal frontier model. The exercise ran in an isolated environment replicating the research infrastructure and consumed hundreds of billions of tokens.
The exercise was designed to favor the attackers. Agents were given the infrastructure's source code, configuration details, and material on suspected vulnerabilities. The company stresses that the aim was to test the strength of its defenses, not to measure what a model could discover on its own. It also ran tests that began from a state in which inner defenses had already been broken and the agent had full control of the host machine.
In one series of experiments, agents were asked to escape the sandbox and execute code on the underlying host machine. The agents chained multiple vulnerabilities and found several routes out of a lightweight virtual machine (microVM). The company is contributing fixes for the flaws found back to open-source projects: Kata Containers (including CVE-2026-24834), gVisor (file descriptor handling), and Moby/Docker (system call filtering). Linux kernel improvements it is pursuing in parallel include fixes for CVE-2026-74753, CVE-2026-80521, and CVE-2026-80841.
Kata Containers, gVisor, Docker, and the Linux kernel are not OpenAI-specific components; they are public open-source software. If companies elsewhere run AI agents in containers or microVMs built on the same components, the same fixes apply to them. For anyone designing agent isolation in-house, a report that flaws in widely used isolation components were actually chained in an exercise is material for revisiting design assumptions.
In the tests that assumed a compromised host, the weakness of the connections left in place came to light. After the Hugging Face incident, the company had reduced the routes by which models could reach the internet, but narrow connections remained for specific company-operated services such as metrics, logging, and credential management. The red-team agents found vulnerabilities that gave them some limited form of internet access in nearly all of these services. Some attacks exploited unknown flaws; others combined legitimate features in unintended ways. Also found were cases where DNS and firewall misconfigurations let requests through that should have been blocked, and methods of getting company-operated services to fetch external URLs.
Routes to the outside are not the only holes. Paths were also found by which two isolated environments could exchange information without using the network. In one experiment, agents in separate microVMs on a shared host were told to exchange synthetic secrets without using network connections or shared writable files. The agents used the CPU cache.
A cache is a small, fast memory holding copies of recently used data, which can be read faster than fetching from main memory. One agent encoded information by evicting chosen data from the cache. The other measured how long it took to read that data again and recovered the content from the difference between fast and slow reads. According to the company, this technique is also used to extract information in the Spectre and Meltdown attacks.
Shared storage, contention for CPU time within a shared container, and the TLS certificate cache of the offline web infrastructure also became communication channels. The TLS certificate cache is not an exit to the internet; it is a route by which agents that were supposed to be isolated could exchange information. In most tests, the company supplied either the channel to investigate or the encoding convention. In one case, however, it handed over a list of infrastructure vulnerabilities and asked the agents to find a way to communicate; the agents turned a vulnerability on the list into a channel, agreed on an encoding, and succeeded in exchanging information.
The company says many of these channels carry information slowly and are hard for a model to exploit, and it added checks to monitoring that detect communication attempts.
The company writes that it found no easily usable internet route that stayed hidden from monitoring. As the exercise progressed, the number of vulnerabilities and misconfigurations discovered dropped sharply. The company sees this as an encouraging sign of the infrastructure's strength, while noting that the figure shown is not a controlled relationship between compute and number of findings. It also assumes that future models will find and exploit vulnerabilities it does not yet know about, and it has made continuous red-team exercises a core part of its long-term strategy. It says it has fixed the weaknesses found and has worked with the responsible maintainers to disclose and fix flaws in open-source software.
Two weeks earlier, Anthropic made a decision whose center of gravity is the reverse
In an October 9 report, two weeks before OpenAI's policy, Anthropic wrote that it had already cut live internet access for some high-risk and cyber evaluations and had decided to extend this to all internal evaluations. The condition for lifting the cut is confirmation that security and monitoring measures reliably catch similar behavior. The report does not say the extension was complete at the time of writing.
The description on the training side differs. Anthropic writes that it will minimize internet access for internal agents and training processes, while explaining that it is scanning records of RL environments in which Claude had internet access.
| OpenAI (October 23) | Anthropic (October 9) | |
|---|---|---|
| Training | All frontier RL runs conducted with the offline approach (no internet access) | Training-process access "minimized." Records of RL environments with internet access are being scanned |
| Evaluation | Live internet kept outside the boundary for "most" evaluations | Decision to extend the live internet cutoff to "all internal evaluations" |
| Condition for lifting | Until safety progress justifies broader access | Until monitoring is confirmed to reliably catch similar behavior |
OpenAI has removed the live internet from training (all frontier RL runs) and most evaluations, while Anthropic has decided to remove it from all internal evaluations and keeps training-process access only at "minimized." The center of gravity of the cutoff is thus reversed between the two companies on paper. The two documents differ in nature, though. OpenAI's is a policy document on training environments that says the approach is already in effect, whereas Anthropic's is a report on an incident during evaluation, where training is mentioned only as one countermeasure. This "reversal" is limited to the center of gravity of the cutoff as written in the documents. OpenAI also covers most evaluations, and Anthropic also indicates a policy of reducing access in training.
The table lines up the scope terms each company's official document uses for itself. Both are self-reported, and the documents do not make clear whether any third party has verified the scope. The word Anthropic uses for training is "minimize," not "cut off." The actual strictness of operations cannot be compared from this table either. OpenAI's document does not mention Anthropic's decision, so it cannot be said that either company followed the other.
Both documents frame the conditions for lifting the restrictions as the company's own judgment. OpenAI says "until safety progress justifies broader access," and Anthropic says "until it confirms monitoring reliably catches" such behavior, each written in the first person. In OpenAI's red-team exercise, however, cloud partners helped supervise the experiments and respond to findings, so the material for the judgment is not produced solely in-house.
What OpenAI says it will use in future decisions is the results of its red-team exercises. It places high-compute red-teaming at the core of the safety case for deciding whether future frontier RL training and evaluation may proceed, and it has reserved compute to keep probing the infrastructure's weaknesses with its most capable models. As for the "safety progress" named in the lifting condition, the document identifies three areas as the basis for judgment: alignment research, monitoring systems, and internet infrastructure security. It does not give a standard for how far progress must go before broader access is justified. How the red-team results would feed into a decision to lift the restrictions also cannot be read from the document.