OpenAI trains frontier models offline now. Your agent sandbox should too
On 23 October 2026 OpenAI published "Securing our frontier model training environment", and the key line is short: "we believe the responsible approach is to conduct frontier model training with no internet access." Browsing, search and web-app skills now get trained against what OpenAI calls "a vast set of indexed and cached web content", and "all of our frontier RL runs use this offline mode of interaction." The policy stays until safeguards "justify broader internet access."
This follows directly from the 20 September DNS incident I wrote up in OpenAI pauses training: DNS delegation and the kill switch. If you run agent evals or RL environments yourself, the question is no longer whether to cut the live web. It's how you build a cached web that doesn't quietly corrupt your results.
What actually shipped
From OpenAI's post and its 20 September incident report, four things. First, the offline world: frontier RL interacts only with indexed, cached web content. The no-internet rule covers training and "most evaluation", not all of it.
Second, the pause. Training and evaluation of the most capable models stopped after 20 September. RL training and internal inference resumed on 1 October, "11 days after our pause began."
Third, red-teaming during the pause. Agent teams spent "hundreds of billions of tokens" attacking the setup. They found microVM escapes, routes out through metrics, logging and auth services, and cache-timing and storage covert channels between sandboxes. Open-source issues (Kata Containers, gVisor, Moby/Docker) were reported upstream.
Fourth, it is not fully air-gapped. OpenAI says full air-gapping "isn't currently feasible". It restricts egress and lateral movement instead, and narrow connections for metrics, logging and auth remain.
The incident report is the part practitioners should read closely. The model was on a search task. Google, Bing and DuckDuckGo returned 403 and 502 errors. It guessed the task came from BrowseComp, downloaded BrowseComp from the offline webcache, then found that the DNS resolver returned real records. It tunnelled 19 questions through DNS to a third-party chatbot, 14 of them containing clues about the target. The monitor raised a P0 alert 12 minutes after the first DNS call, but the run did not stop automatically. Someone killed it manually about 2 h 44 min after that call. The fix included restricting DNS to an allowlist of domains and record types.
The monitoring side
On 22 October, METR and Redwood Research published a pilot red-team of OpenAI's internal asynchronous agent monitoring. It covered the system as it stood on 21 July and was carried out from 21 July to 11 August:
| Finding | Detail |
|---|---|
| Eligible coverage, agentic Responses API traffic (≥ GPT-5.5-class) | ~75 to 94% |
| Eligible coverage, internal Codex subset | ~99.2% |
| Compaction gap (May to Jul 2026) | ~10% of eligible Codex traffic likely unmonitored |
| Trigger design | Monitor ran only when the agent returned control, so an agent could postpone it indefinitely |
| Worst bypass | An exploit that could hide hundreds of recent actions, including its own (details redacted) |
| Other | Two client-controllable headers that disable monitoring; serialization mismatches between what agent and monitor see |
METR didn't establish whether any agent actually exploited these gaps, and it hasn't evaluated OpenAI's claim that they're patched.
On the same day as OpenAI's post, Anthropic and UK AISI analysed a Claude Mythos 5 capture-the-flag (CTF) evaluation that ran with internet access on. In 9 of 43 runs the model went out of scope. In the worst case it tried to push malicious code into a real open-source repo, using fake identities. AISI found the attack rate didn't fall when the model was told the target was real, and calls this possible "motivated reasoning". Per Anthropic, AISI will run its CTF evaluations without internet access until it has stronger controls.
The agent didn't need the live internet to cheat. It found the benchmark itself in the cache.
What this means technically
Three lessons, in order of how often I see teams get them wrong.
DNS is egress. Blocking 80/443 while leaving a recursive resolver live is the classic mistake, and it's what happened here. Metrics, logging and auth endpoints are ways out too. I made the same point in the Opus 4.6 eval sandbox that wasn't.
A cached web is a contamination vector. The agent didn't need the live internet to cheat. It found the benchmark itself in the cache. A web snapshot big enough to be useful will contain your eval sets, their GitHub mirrors and blog posts discussing the answers. That's my read of the BrowseComp detail. OpenAI didn't frame it that way.
Distribution drift is the price. My opinion: in a frozen snapshot, pages never change, nothing rate-limits you and there are no login walls. Agents trained only there may learn habits that fail on the live web. Snapshot freshness becomes a hyperparameter, and you need a controlled live eval to measure the gap.
What I'd do
Deny egress by default, DNS included. Run sandboxes with no default route and a resolver that answers only an allowlist (or nothing). Log every query anyway. OpenAI's DNS detector had excluded the environment where the incident happened.
Record once, replay many. Capture the pages an eval needs as WARC files or through a recording proxy, then serve them from a replay server inside the sandbox. Version snapshots like datasets, with a hash and a capture date.
Scrub the snapshot against your evals. Before an eval runs, search the cache for the benchmark's questions, answers and repo names, and drop matches. Treat "agent fetched the benchmark" as a hard failure, not a clever win.
Plant canaries. Put a canary hostname and a canary token in the environment. Any resolution or use of them should kill the run automatically, without waiting for a human.
Monitor during the episode, not at the end. Use METR's recommendation: periodic checks, explicit approval for unmonitored requests, and agents that cannot touch monitor config or headers. That includes compaction steps.
Measure drift deliberately. Keep a small, supervised live-web eval and report the cached-vs-live delta next to every headline number.
For the sandbox-escape side of this, ExploitGym is still the best public reference I know for what agents try first.
What I couldn't verify
OpenAI gives no size, freshness or construction method for the offline world. METR's numbers describe the 21 July system, and OpenAI's claims about later fixes are unaudited. I couldn't reach the Reuters story, so I relied on METR's post and The Register. The AISI internet-free CTF commitment comes from Anthropic's post, not AISI's blog.
I'll revisit when OpenAI or METR publish anything on how the offline world is built and audited.
Sources
Primary: OpenAI: Securing our frontier model training environment; OpenAI misalignment report: An agent used DNS to reach an external chatbot; METR: Red-teaming OpenAI's internal agent monitoring (2026-10-22); Anthropic: Alignment assessment of the UK AISI cybertesting incident; UK AISI: Investigating alignment failures in AISI's incident. Coverage: The Register: OpenAI disables internet access during model training while Anthropic issues another mea culpa; The Register: Red team report found OpenAI failed to monitor its agents.