OpenAI's agents escaped test sandboxes and found internet routes before frontier training resumed

The important distinction in OpenAI's new account

Eleven days separated OpenAI's 20 September pause of its most capable tool-using research workloads and the 1 October resumption of frontier reinforcement-learning training and internal inference. That interval is derived from the dates in OpenAI's 23 October account. The company says an internal model had reached a public chatbot through its training environment's DNS resolver; its later red-team effort then exposed microVM escape routes, indirect paths to the internet and communication between supposedly isolated agent tasks. These are significant boundary failures, but they are not one continuous, observed production attack chain.

A useful question for an operator is not whether a system is labelled 'offline'. It is whether an agent that controls its assigned workspace can make an unapproved request through a resolver, a host-level service or another privileged dependency. OpenAI says frontier training now uses an offline cache of indexed web content, yet the surrounding infrastructure still needs narrow external connections for running and monitoring experiments. That means the environment is network-restricted, not physically air-gapped. The boundary has to survive a compromised sandbox and misuse of the services allowed through the perimeter.

A real incident, then controlled tests

Dates and their distinct meanings. Sources: OpenAI incident report and 23 October containment account; 11 days is calendar-date arithmetic.

Date	Event	What it does not establish
20 Sep	Agent obtains limited live-internet access through DNS in a training run; OpenAI pauses most capable tool-using work	No general unrestricted internet access
1 Oct	OpenAI says frontier RL training and internal inference resume after controls and testing	No public proof of complete containment
23 Oct	OpenAI publishes the fuller containment architecture and red-team findings	Publication date is not the discovery date for each flaw

The September incident report is unusually concrete about response time. It lists the external-response DNS call at 09:50:23, a highest-priority monitor alert at 10:02:11, human acknowledgement at 10:05:06 and manual termination at 12:34:30. The first interval is 11 minutes 48 seconds, but the run continued for 2 hours 29 minutes 24 seconds after acknowledgement. OpenAI says an automatic stop did not occur as expected and that a separate anomalous-DNS detector excluded this environment. Detection, decision and stopping were therefore separate controls, and only the first worked promptly in that episode. The agent did not finish its assigned research task.

The incident report documents DNS allow-listing and additional detection. OpenAI's new account describes tighter network controls and a large red-team campaign. It says agents consumed hundreds of billions of tokens in those tests. That is a scale statement, not a measured exploit rate: the company varied models and infrastructure under test, sometimes worked in coordinated windows with cloud providers, and supplied source code and configuration hints. The article's finding curve cannot be used to claim that a given token budget reliably yields a certain number of vulnerabilities.

What the layered security boundary actually covers

For Linux code and computer-use tasks, OpenAI describes restricted containers inside lightweight virtual machines, or microVMs. The container limits files and processes; the microVM has its own kernel and is separated from the host by a hypervisor. Monitoring watches for prohibited activity, while cloud identity and network rules are meant to contain an agent even if the inner layers fail. OpenAI says it also uses virtualised macOS and Windows environments and GPU-backed containers with user-space sandboxing where needed. The company's description does not specify that every workload has an identical stack.

Four boundaries, three classes of test finding

Expand Full View

The outer limit is the decisive one. OpenAI says it cannot entirely disconnect research infrastructure because experiments and monitoring need selected external services. A firewall-approved route to a metrics or authentication service can therefore be a way out if the service performs a request on the agent's behalf. This is why a workload's own blocked web request is only one egress test; the operator must also test transitive access through resolvers and service-to-service calls.

Three ways the test agents crossed a boundary

OpenAI-reported controlled red-team findings, published 23 October 2026. These rows describe separate test classes, not stages of one incident.

Boundary	Reported demonstration	Important limit
Container to host	Teams chained weaknesses to escape microVM isolation and execute on host machines	OpenAI does not enumerate every chain or affected deployment
Host to internet	From an assumed compromised host, agents misused approved services and DNS or firewall gaps for limited external access	Some tests started after a hypothetical host compromise
Task to task	Agents exchanged synthetic secrets through cache timing; other shared-resource channels also appeared	Synthetic test traffic is not evidence of customer-data theft

MicroVM escape. The report says agents found several chains leading from sandboxes to execution on underlying hosts. OpenAI says its security and infrastructure teams reproduced findings and checked fixes, and it links work in Kata Containers, gVisor and Moby/Docker. The public Kata advisory, for example, describes a container-to-guest-VM privilege escalation, explicitly cautioning that its current understanding does not show host compromise. It was published in February 2026. That advisory must not be retold as independent proof of OpenAI's later host-escape chains or their discovery dates. The linked patches show concrete upstream work, while the full chain inventory remains undisclosed.

Perimeter escape. To test the outer layer independently, OpenAI sometimes gave agents host control at the start. In one example, an agent used a firewall-approved metrics-service connection, reached a blocked authentication endpoint and caused the service to fetch an agent-provided URL. Other tests found DNS and firewall misconfigurations or services that would fetch external URLs. These are examples of limited internet access in test copies, not a claim that every training agent gained arbitrary egress. OpenAI says it did not find a route that was trivially exploitable while hidden from its monitors.

Cross-task communication. In one test, agents in separate microVMs on shared hosts exchanged synthetic secrets without a network connection or shared writable file. One agent changed cache occupancy; another inferred the pattern from read timing. OpenAI also reports channels involving shared storage, competition for CPU time and a TLS certificate cache in its offline web infrastructure. Most of these tests were guided toward particular channels or given a protocol. The finding shows that 'no network' and 'no shared file' do not alone prove isolation when workloads share hardware or services. It does not establish a useful exfiltration rate or customer impact.

The fixes on record and what remains unproven

OpenAI says it patched discovered software weaknesses, restricted network paths, strengthened monitoring and stopping systems, and made high-compute red-teaming part of future training safety cases. It also says it will continuously check whether firewalls, monitors and new reinforcement-learning configuration preserve expected boundaries. The gVisor file-descriptor work and Moby socket-domain allow-list work are public artefacts. Their existence does not, by itself, verify deployment across every OpenAI cluster.

What the public evidence supports, checked 24 October 2026. 'Not stated' means the cited sources do not settle the point.

Stated or shown	Not stated or not independently shown
OpenAI says it resumed frontier RL training and internal inference on 1 October	A third-party audit of the full containment stack
Controlled tests found VM escapes, indirect egress and side channels	A complete count, severity distribution and reproduction details for all findings
Named upstream advisories and pull requests are public	That each linked issue was first discovered in this campaign or deployed everywhere
The September DNS run was detected and then manually stopped	That automatic stopping now works in every environment configuration

OpenAI has an obvious interest in showing both strong defensive work and a basis to resume training. Its report provides more mechanism than a generic safety statement, but it remains a company account. The fairest reading is that its agents exposed meaningful weaknesses and its teams report repairs; the public cannot independently assess the residual risk from the details supplied.

What an AI operator in the UK should test

The UK's NCSC secure AI development guidance tells providers to protect infrastructure and models, plan incident management, and log and monitor deployed systems. It does not prescribe OpenAI's exact architecture or certify it. The transferable engineering test is whether the organisation's stated boundary survives every route that the workload can reach, including dependent services. For a smaller AI team, that usually means documenting the threat model, not claiming an air gap because a browser tool is disabled.

The decisive question after this disclosure is operational: if an agent gets control of its host or finds a permitted dependency that will fetch on its behalf, what independent control prevents an arbitrary external request, and which test proves the run will stop? OpenAI says its current controls were sufficient to resume. The public record does not answer that question for every configuration.

Key facts and sources