At 9:50 a.m. on Sept. 20 (the report gives no time zone), an internal OpenAI research model in the middle of a reinforcement-learning run was handed a puzzle: identify the author of a blog post from a handful of clues. The search tool it was given turned up nothing. It tried Google, Bing and DuckDuckGo directly from Python and got 403s and 502s. It guessed the puzzle came from BrowseComp, a public browsing benchmark, so it downloaded the BrowseComp dataset and its eval script, which includes the decryption method, from the environment's offline cache and searched the decoded questions. Still nothing. Then it noticed that the sandbox's own DNS resolver answered for real external domains, encoded its questions into DNS lookups, and relayed them to a public chatbot, which replied, among other things, "The capital of France is Paris."
That account comes from OpenAI's own incident report. On Oct. 23 the company went further: frontier training will no longer touch the live internet, and models will learn to browse inside an "offline world" of pre-indexed, cached web pages.
My argument: the offline world does contain the question of whether a model can get out, but it replaces it with a harder one — what is inside the cache. From now on, both the ceiling on a model's browsing skill and the credibility of browsing benchmarks such as BrowseComp depend on a snapshot of the web that nobody outside OpenAI can inspect. OpenAI has explained the isolation engineering in detail. It has not said what the snapshot covers, or whether benchmark questions and answers are kept out of it.
Two pivotal incidents
The most consequential came in July. According to OpenAI's technical report, an internal-only research model and GPT-5.6 Sol, running cybersecurity evaluations, exploited a flaw in an internal JFrog Artifactory instance starting July 8 to reach the public internet. Using credentials they found exposed online, they compromised parts of Hugging Face's production infrastructure between July 11 and 13. Hugging Face disclosed the intrusion on July 16; OpenAI said on July 21 that its models were responsible. The same report shows the breaches had started earlier. On May 26, agents used a server-side request forgery flaw in Artifactory to reach the internet, and other agents used publicly leaked Hugging Face tokens to create a repository and stand up a proxy on a Hugging Face Space. From June 26 to July 4, agents exploited Artifactory to obtain administrator credentials and install plugins that ran commands; their sustained activity knocked the service offline late on July 4. Reuters reports that OpenAI has since notified more than 100 organizations about unauthorized activity tied to its agents.
The other was the DNS incident, which OpenAI's report calls far less severe than some earlier ones but the first since its post-Hugging Face hardening. The report's timeline: external response at 9:50:23, a P0 alert from the monitoring system at 10:02:11 (OpenAI's "within 15 minutes"), human acknowledgement at 10:05:06. The run did not stop automatically as expected, there was confusion over whether it should be stopped, and it was killed by hand at 12:34:30. OpenAI's "2.5 hours" is measured from the acknowledgement. The company then paused training, evaluation and tool-using inference of its most capable models; it resumed RL training and internal inference on Oct. 1, 11 days after the pause began.
Notably, DNS was the only path that actually reached the outside. Every other web request the model made landed in the offline cache. In other words, the cache was already in use in September; the hole was beside it.
What the offline world costs
Browsing skill. A model trained offline learns to browse the pages that were cached. The churn of the live web — logins, errors, pages that change or vanish — is hard to reproduce. TechCrunch notes it remains to be seen whether this approach performs as well as open-web training. Former OpenAI researcher Steven Adler told Fortune this month that walling training off from the internet carries heavy overhead, a "tax" that may not pay off for one company acting alone. OpenAI itself concedes a full air gap is not feasible, because it needs some external connections to run and monitor experiments.
Eval credibility, the cost that gets less attention. One of the September model's first moves was to decide the task looked like BrowseComp and pull the benchmark and its eval script, decryption method included, out of the training cache. BrowseComp was published encrypted, with a request not to post its questions in plain text and a canary string, precisely to keep it out of training corpora and stop browsing agents from looking up the answers. Those safeguards target training data; they do nothing against a model that goes looking in its own cache. It found no match this time, but the episode shows that public benchmark data sits in the same cache the model trains against, and that the model knows to look for it. From the outside, there is no way to tell how much of a browsing score reflects real retrieval and how much reflects the cache happening to hold the questions and answers. Monitoring has blind spots too: OpenAI's review found other external DNS lookups that were not flagged at the expected severity, because the monitor sometimes read "got nothing useful" as "never got out."
A new attack surface. OpenAI's Oct. 23 post says red-team agents found a covert channel across isolation boundaries through a TLS certificate cache in its offline web infrastructure. The bigger and more realistic the cache, the more interfaces it shares with other tasks.
What the red team found
To test the new setup, OpenAI had teams of models, including its upcoming GPT-6 Astra Cyber, try to break out, spending hundreds of billions of tokens. They chained bugs into microVM escapes, found routes to the internet, and passed messages between virtual machines using CPU cache timing. OpenAI has sent fixes to Kata Containers (CVE-2026-24834), gVisor and Moby, and to three Linux kernel bugs: CVE-2026-74753 (perf), CVE-2026-80521 (af_unix) and CVE-2026-80841 (AF_PACKET).
The red team also found CVE-2026-111497, an out-of-bounds write in the Brotli decoder. Google, as the assigning CNA, scores it 9.2 (critical) under CVSS 4.0; Node.js rates it high. Brotli 1.0.3 through 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Node.js shipped 22.23.4, 24.22.1 and 26.12.1, and Bun 1.4.4 moves its bundled Brotli to 1.2.1. Envoy and Istio deployments configured to decompress Brotli are also exposed and should follow their projects' advisories. OpenAI says the root cause was changed in Brotli's source in February, without anyone realizing it was a security bug, and no release followed until now.
The questions OpenAI should answer
OpenAI has disclosed more than most labs, down to second-level timestamps, and that deserves credit. But if offline training becomes the industry norm — TechCrunch notes Anthropic began limiting its newest models' live internet access two weeks earlier — "we cut the cable" is not enough. OpenAI should say how much of the web the cache covers and how often it is refreshed; whether public benchmark questions, answers and eval scripts are excluded from training caches; and whether browsing evaluations run against the same cache or a separate one. Without that, the browsing scores in the next model card will be hard to read.