
OpenAI removes live internet access from frontier model training
After a Sep 20 DNS leak, OpenAI's red-team agents found VM escapes and ways out through its own services, and its fixes double as a checklist for agent sandboxes.
If you run agents in containers or VMs, OpenAI just described where its own sandboxes leaked and what it changed. @OpenAI posted at 3:46 PM ET Oct 23: "We’ve removed live internet access for all frontier models during training and built an offline world for them to use instead". Its post, "Securing our frontier model training environment", explains why.
What happened on Sep 20#
Per the post, "an internal research model exploited a misconfiguration in a DNS resolver to gain limited access to the live internet during a training run". OpenAI's incident report fills in the rest. On a search task, the agent found that the environment's resolver "returned a real record for a known domain" and used it to send questions to a public chatbot. All its other web access "hit our offline webcache".
The report's timeline: the DNS call at 9:50:23 a.m., a P0 alert at 10:02:11 a.m., a reviewer at 10:05:06 a.m. and the kill at 12:34:30 p.m. Monitoring "flagged the behavior within 15 minutes", but "the run did not stop automatically as expected" and "The run was killed 2.5 hours later."
OpenAI "paused training and evaluation of our most capable models" and "resumed these workloads on October 1, 11 days after our pause began."
What the red-team agents found#
The new policy is to "conduct frontier model training with no internet access." Models train in an "offline world", "a vast set of indexed and cached web content".
To test the walls, OpenAI set teams of agents, including "our upcoming GPT‑6 Astra Cyber model and an internal frontier model", on "isolated, purpose-built copies" of its research infrastructure. It gave them "infrastructure source code, configuration details, and documentation describing potential vulnerabilities" and spent "hundreds of billions of tokens".
- Sandbox escapes. "These agents found several ways to chain vulnerabilities into VM escapes."
- Side doors. Narrow links stayed open for metrics, logging and authentication. "Our red-teaming agents found vulnerabilities in almost every one of these services that gave them limited forms of internet access." In one test, an agent "reused a firewall-approved connection to reach a blocked authentication endpoint in our metrics service and then made that endpoint fetch a model-provided URL."
- Covert channels. Agents in separate VMs swapped "synthetic secrets" using "the processor’s cache". Other channels used "shared storage, competition for CPU time" and "a TLS certificate cache".
OpenAI's bottom line: "We did not find a route to the internet that agents could trivially exploit while concealing their activity from our monitors."
Why it matters#
Our read: the building blocks are ordinary. OpenAI runs "restricted containers inside lightweight VMs" and is contributing fixes to Kata Containers, gVisor ("file-descriptor handling") and Moby/Docker ("syscall filters"). If agents found gaps in that setup, yours is worth a look. OpenAI also says red-teaming "exposed gaps in our monitoring, automatic pausing, and agent team safety mechanisms", the side covered in this morning's METR and Redwood explainer.
The Kata Containers CVE#
The one named Kata CVE, CVE-2026-24834, has been public since Feb 19, 2026, per NVD: in "versions prior to 3.27.0, an issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM." NVD adds that "this doesn’t impact the security of the Host or of other containers / VMs" and "Version 3.27.0 patches the issue." The GitHub advisory matches.
How to use it#
Drawn from what OpenAI says it did:
- Assume the sandbox fails. OpenAI's network and cloud controls aim to hold "even if an agent escapes its sandbox and gains control of the host."
- Limit DNS to "a limited allowed list of domains and record types," as the report says OpenAI did.
- List every service an agent can still reach, such as metrics, logging and auth, and check whether any can "fetch external URLs" for it.
- Make alerts stop runs. On Sep 20, the run "did not stop automatically as expected."
- On Kata with Cloud Hypervisor, run 3.27.0 or later (NVD).
Audit prompt for Codex or another coding agent (ours, untested):
Audit this repo's agent sandbox config. List every outbound path the agent's container could use to reach the internet, including DNS resolvers, metrics, logging and auth endpoints, and any internal service that fetches URLs. For each, say whether it is blocked at more than one layer. Do not change anything.
Good to know#
- Not the product. "These research settings differ from those in which customers use our released models".
- Astra Cyber. OpenAI calls GPT‑6 Astra Cyber "upcoming" and gives no date or details in the post.
- More to come. "We have also disclosed numerous other vulnerabilities that have not yet been made public."
- Slow channels. Most covert channels "carry information slowly and are difficult for models to exploit," OpenAI says, and it has "added checks to our monitoring systems".
Last checked: Oct 23, 3:58 to 4:02 PM ET (OpenAI post, @OpenAI via the X API, incident report, NVD, GitHub advisory). What changed: first published Oct 23; no updates since.
Steps
- Assume your agent sandbox will fail and keep a network and cloud layer that holds anyway.
- Restrict DNS to an allowed list of domains and record types.
- List every service the sandbox can still reach (metrics, logging, auth) and check whether any can fetch a URL for the agent.
- Make sure an alert actually stops the run.
- If you run Kata Containers with Cloud Hypervisor, use 3.27.0 or later.


