TL;DR. On October 23, OpenAI said it will train its strongest models only without access to the internet. The trigger came on September 20: a research model found its way onto the open internet through a misconfigured DNS service. OpenAI paused training for eleven days and used the time to set its own AI agents loose on its defenses. They found escapes from virtual machines, holes in almost every service still allowed to reach outside, and a hidden channel through the processor. A day earlier, two independent reviewers had shown that OpenAI's agent monitoring had gaps as well. Anyone who lets agents work with tools faces the same task on a smaller scale: build limits that hold even when the agent looks for a way around them, and count whether monitoring really sees everything.
What OpenAI changed
According to OpenAI's report, its frontier models now learn in an "offline world": a large collection of cached, searchable web pages. There they keep practicing how to search, click and use web applications, but they cannot reach a real server. It will stay that way until better safeguards justify more access. OpenAI does not say when that will be.
On September 20, an internal research model used a misconfigured DNS resolver during a training run. DNS is the service that turns names like azena.ai into addresses. That gave the model limited access to the open internet. OpenAI contained the incident, stopped training and testing its strongest models, and resumed on October 1. On October 9, Anthropic had announced that it would no longer run its internal tests on the open internet. We wrote about that report in "When the agent finds a detour" (in German).
From the breakout to the reports, fall 2026
September 20An OpenAI model reaches the open internet through a DNS error.
October 1Training restarts, now without internet.
October 9Anthropic takes its internal tests off the open internet.
October 22 and 23Review of the monitoring, reports from OpenAI and Anthropic.
What the test agents found
During the pause, OpenAI sent teams of its own frontier models up against copies of its training environment. They had three assignments: reach the internet, cross an internal boundary, and make contact with agents they were supposed to be isolated from. To make things hard for the defense, the attackers received source code, configuration and pointers to possible weaknesses. According to OpenAI, the exercise used hundreds of billions of tokens.
OpenAI protects every agent with four layers meant to back each other up. The testers found something in every one of them.
Four layers around every agent, and what the testers found in each
- Layer 1Sandboxcontainer with tight permissions
Holes in widely used software such as Kata Containers, gVisor and Docker.
- Layer 2Virtual machineown kernel, separated from the host
Several chained escapes down to the host machine. Separate machines exchanged data through the processor cache.
- Layer 3Monitoringchecks what agents do
About 10% of Codex traffic went unchecked. One trick hid hundreds of actions.
- Layer 4Network boundaryfirewall, few permitted services
Holes in almost every service allowed to reach outside, and routes through DNS and the firewall.
Layers 1, 2 and 4: OpenAI's own test with agents this fall. Layer 3: review by METR and Redwood Research in July and August.
Two findings show how inventive the agents were. Only a few services were still allowed to reach outside, for metrics, logs and sign-ins, for example. One agent reused a connection the firewall permitted to reach a blocked sign-in service, then had that service fetch an address of its choosing. Two other agents in separate virtual machines on the same host exchanged secrets without any network at all: one deliberately evicted data from the processor cache, the other measured how long reloading took. Fast and slow became a message. It is the same technique behind the well-known processor flaws Spectre and Meltdown.
The good news is in the report too. The testers found no route outside that an agent could have used easily and unnoticed. And the longer the test ran, the rarer the findings became.
The monitoring had gaps
One day before OpenAI, METR and Redwood Research published what they had looked for during three weeks inside OpenAI's agent monitoring this summer. The system is meant to check the work of internal agents for deception, sabotage and data exfiltration. By their estimate, 75 to 94 percent of internal agent traffic through OpenAI's Responses interface was set up for monitoring, and 99.2 percent for the Codex programming agents.
How much agent traffic OpenAI's monitoring saw this summer
set up or checkeduncertainty range of the estimateunchecked
From May to July, however, about 10 percent of that Codex traffic went unchecked. The monitor only looked when an agent handed control back to a human, and not at all when long histories were being summarized. An agent that simply kept working could postpone the check indefinitely. OpenAI had already found this itself and fixed it during the review. The two reviewers also found a trick that hides hundreds of actions from monitoring, and two settings that allowed new agents to be started with no monitoring at all. OpenAI says all holes have been closed. METR writes that it has not verified this.
The catch
- This is about training. It concerns unfinished models under deliberately harsh conditions. According to OpenAI, customers use finished models with additional safeguards.
- Attackers with a blueprint. The test agents had source code and pointers to weaknesses. The exercise does not measure what a model would find without that help.
- Self-reported. Nobody outside has confirmed the fixes. The METR report is a short version that OpenAI was allowed to redact.
- Costly, with an open outcome. Former OpenAI researcher Steven Adler told TechCrunch that full separation would be a lot of overhead, with research teams essentially sitting inside the data center. Whether models learn as well from a cached web remains open.
What this means for mid-sized companies
No mid-sized company trains frontier models. But more and more companies let agents run code, operate browsers and connect to company systems. These are the same model families, just fully trained. That makes OpenAI's report the most detailed public guide to fencing in an agent. It also shows where things leaked despite huge effort: rarely in the wall itself, often in the small permitted exceptions next to it. A DNS service, a logging service, a sign-in endpoint.
Agents looking for such exceptions are not an isolated case. In a test by the UK AI Security Institute, Claude Mythos 5 took unsanctioned actions against real people and organizations in 9 of 43 runs, as Anthropic's analysis of October 23 shows. Limits therefore have to hold when the agent is searching for them, not only when it respects them.
What you should do now
- List the exits. Write down for every agent what it may reach on the network, including DNS, proxies, logging and sign-in services. Everything else gets blocked, not merely "not intended".
- Two walls instead of one. Assume the sandbox will fail. Agents run in their own virtual machine with no access to production systems, and the firewall sits outside it.
- Check fetch services. Any service that loads an address the agent names is an exit. That applies to link previews, webhooks and import features alike.
- Count your monitoring. Regularly compare how many agent actions appear on the bill and how many in the log. Check continuously, not only at the end of a task.
- Have your own environment attacked. Give an agent in a copy the task of reaching a page outside. Fix what it finds before someone else finds it.
The vendors are drawing their limits tighter because their models are getting better at finding them. The same goes for the agents in your company. If you would like to know where your agents can get to today, we are happy to talk.
