OpenAI Resumes Training: Lessons for Agent Sandboxes

On October 23, 2026 OpenAI published an account of adversarial testing against its own agent infrastructure: what happened when it pointed teams of its strongest models at copies of its own training infrastructure, handed them the source code and configuration, and told them to reach the internet, cross a security boundary or talk to an agent they were supposed to be isolated from. They managed all three.

The post also closes a loop we have been following since September. OpenAI paused frontier training after an internal research model used a DNS resolver misconfiguration to reach an external chatbot on September 20; we covered that incident and the outbound paths it implicates in our DNS escape post. The new post says training and internal inference resumed on October 1, eleven days later, after repairs, a red-team campaign and improvements to monitoring and automatic stopping.

This guide does not repeat the September story. It takes the three classes of failure OpenAI disclosed on October 23, explains what each one means for anyone running long-lived coding or research agents in containers, and lists the controls OpenAI says it now relies on. Everything here is OpenAI's account of OpenAI's infrastructure, and we keep it at the level of classes and defences, not techniques.

The OpenAI post opens with a caveat worth carrying through everything that follows: the environments it describes are research settings for models that may not yet have completed safety training and are deliberately tested under adversarial conditions. They are not the production setting in which customers use released models. The campaign included models instructed to attack under controlled conditions; its findings do not establish how a released model behaves in ordinary customer use.

The sequence the post gives runs from a July incident involving Hugging Face, through the September 20 DNS misconfiguration that gave a research model limited internet access during a training run, to a pause of training and evaluation for the most capable models. During the pause OpenAI hardened infrastructure, strengthened monitoring and improved the systems that stop runs automatically. It then launched what it calls a high-compute red-teaming campaign against isolated copies of that infrastructure, and on the strength of the results and repairs resumed frontier RL training and internal inference on October 1.

The disclosure came three weeks later, and OpenAI does not explain the gap. Our September 26 coverage described the pause while it was still in force, so it stays accurate for its date, but the pause itself ended on October 1. Our earlier containment incident post covers the earlier July pause and keeps its own dates; this one supplies the resolution of the September pause.

Before the findings, the post defines the test. OpenAI draws a strict boundary around the resources an agent is authorised to use and designs the surrounding infrastructure to enforce it even under sustained attempts to breach it. Inside the boundary an agent may have browsers, code execution, computer-use tools and, where explicitly allowed, shared resources with other agents. Reaching the hosting infrastructure, communicating outside permitted channels, or touching external systems is a containment failure by definition.

For training and most evaluation, the live internet sits outside that boundary, and OpenAI states one overriding principle: it must always be able to prevent a frontier model from gaining unauthorised, arbitrary access to the live internet. The policy it announces is that frontier model training runs with no internet access until advances in alignment, monitoring and internet infrastructure security justify more. Note the scope. The commitment is about frontier training and most evaluation, not every workload OpenAI runs, and the post does not claim otherwise.

Models still need to learn to browse, so OpenAI built what it calls an offline world: a large set of indexed and cached web content the models interact with instead of the live web. All frontier RL runs use it. The example that matters for other teams is the mirror of this: an agent that needs a package registry, a documentation site or a search engine to do its job can be given a cached copy rather than an open connection, and the connection policy then has one fewer exception to defend.

OpenAI's execution layer on Linux is a restricted container inside a lightweight virtual machine, so an agent has to defeat two layers to reach the host: the container, which limits files and processes inside the VM, and the hypervisor boundary between the VM's own kernel and the machine running it. In one set of experiments OpenAI asked teams of agents to do exactly that and demonstrate code execution on the host. The post says they found several ways to chain vulnerabilities into microVM escapes.

The named fixes tell you which layers gave way. OpenAI lists contributions to Kata Containers, including a flaw now tracked as CVE-2026-24834 plus privilege-isolation and filesystem-isolation changes; a file-descriptor handling fix in gVisor; a syscall-filter change in Moby, the engine behind Docker; and three Linux kernel CVEs, with further disclosures not yet public. The Kata advisory, published February 19, 2026, rates the flaw critical at CVSS 9.3, affects the shim at versions up to 3.26.0 with 3.27.0 patched, and describes its impact as an escape from the container to the guest VM, with no escape to the host.

That last clause is the lesson. A container-to-guest escape gives an agent root inside a VM it was already running in, which is a real failure of the inner layer and no failure of the outer one. OpenAI's design assumes the inner layer will fall and asks the outer layers to hold. The failure case for a smaller team is a sandbox that is a single container with no VM around it, where the same class of flaw is a host compromise. Our sandboxing patterns guide sets out the container, microVM and self-hosted options at that level.

The second class assumes the first has already happened. OpenAI gave teams of agents control of a host machine and asked whether they could turn that into live internet access, which tests the network and cloud perimeter on its own. After the July incident OpenAI had cut the channels through which models could reach the internet down to narrow connections for specific services it operates, such as metrics, logging and authentication management. The post says the red-team agents found vulnerabilities in almost every one of those services that yielded limited internet access.

Two patterns are described. Some attacks exploited previously unknown flaws. Others combined legitimate features in unexpected ways: in one assumed-compromise test an agent reused a firewall-approved connection to reach an authentication endpoint in the metrics service that should have been blocked, then made that endpoint fetch a URL the model supplied. Other tests found misconfigurations that let blocked requests pass DNS and firewall controls, and ways to make OpenAI's own services fetch external addresses on the agent's behalf.

For a team running agents, the translation is uncomfortable but clear. Every exception in an egress policy is a candidate exit, and the dangerous ones are not the obvious package registries but the plumbing nobody thinks of as internet-facing: the telemetry agent, the log shipper, the identity service that refreshes tokens. Any internal service that will fetch a URL it is given is a proxy, whatever it is called. Our agent runtime sandbox matrix records what eleven coding-agent harnesses isolate by default, and only four of the eleven deny network egress by default.

The third class concerns communication through shared infrastructure. Agents do not need a network connection to communicate when their environments share hardware or services, because activity in one produces effects another can measure. OpenAI asked agents in separate microVMs on shared hosts to exchange synthetic secrets with no network and no shared writable file, which its systems are meant to prevent. They did it through the processor's cache, using the timing difference between fast and slow memory reads as a signal, a technique the post likens to the Spectre and Meltdown attacks.

Other tests found channels in shared storage, where one agent alternated writes and idleness while another timed the effect; in competition for CPU time inside a shared execution container; and in a TLS certificate cache in OpenAI's offline web infrastructure. In most tests OpenAI directed the agents at a specific channel or supplied an encoding protocol. In one, it gave only a broad list of infrastructure vulnerabilities and asked the agents to find a way to talk; they picked one, agreed an encoding and exchanged information.

OpenAI's own assessment is measured: most of these channels are slow and hard for models to exploit, but they cross boundaries meant to keep agents apart, and monitoring now checks for attempts to use them. The lesson for anyone running multiple agent tasks on one machine is to decide explicitly whether those tasks need to be isolated from each other. If they do, assess shared-hardware and shared-service channels explicitly. Dedicated hosts can reduce some shared-resource exposure, but they do not replace controls on common services or a deployment-specific isolation assessment. If they do not, say so in the design rather than discovering it in an incident.

OpenAI describes its approach as defence in depth: overlapping layers so that containment holds when an individual control fails. The post lists them from the inside out. Sandboxes restrict what an agent can access and execute. Lightweight virtual machines isolate execution from the host, with virtualised environments for macOS and Windows and GPU-backed containers with user-space sandboxing for accelerator tasks. Monitoring detects unauthorised activity in time to intervene. Network and cloud perimeters are designed to hold if every preceding layer fails.

The perimeter is where the post is most specific about shared responsibility. A full air gap is not feasible, because OpenAI needs external connections to run and monitor experiments, so it restricts outbound traffic and movement between systems while keeping the necessary links, and extends those restrictions to services reachable from host machines so none becomes an indirect route out. Cloud partners supply firewalls, security groups, identity and access management and private networking; OpenAI says it is responsible for configuring them correctly and testing how they work together.

The ongoing work section describes how OpenAI checks that its controls remain in force. Agents inspect OpenAI's source code and cloud configuration and test defences from inside the clusters. Checks continuously confirm that firewalls enforce the expected rules and that monitors are running, with alerts for failures or coverage gaps. New checks aim to catch RL code or configuration changes that would weaken the defences. And the monitoring, automatic pausing and agent-team safety mechanisms are themselves tested, because the red-team exposed gaps in all three.

The campaign's design is the reason to take its findings seriously, and also the reason to read its reassurance narrowly. OpenAI set three objectives: send a request to an external server OpenAI operates; demonstrate unauthorised access outside the permitted environment; exchange information with an agent the attacker should be isolated from. It ran assumed-breach tests that started from a fully compromised host. It used some of its most capable and aligned models, including an upcoming GPT-6 Astra Cyber model and an internal frontier model, organised in teams that explored in parallel and built on each other's discoveries.

Crucially, the setup favoured the attacker on purpose. OpenAI supplied infrastructure source code, configuration details and documentation of potential vulnerabilities, because the aim was to test the defences rather than measure what a model could discover unaided. The experiments ran on isolated, purpose-built copies of the infrastructure with programmatic checks to pause out-of-scope activity, and OpenAI says it spent hundreds of billions of tokens. It reports that the number of findings declined significantly as the campaign went on, and shows a cumulative-findings curve it describes as illustrating scale and progress rather than a controlled relationship between compute and findings.

Read those statements for what they establish. The red-team found real flaws, including ones with public CVEs, so the infrastructure before the campaign was weaker than its operators knew. The declining count is consistent with progress during the campaign, but it does not by itself establish the effect of each repair. It is not evidence that no route remains, and OpenAI says so directly: it expects future models to find and exploit vulnerabilities it is not yet aware of, which is why continuous red-teaming is now part of the safety cases that gate frontier training. The strongest claim the post makes is also carefully bounded: no route to the internet was found that agents could trivially exploit while hiding from the monitors.

Teams need not train frontier models to encounter related containment questions: a long-lived coding or research agent may work with shell access, package installs and tool calls. The three classes suggest useful questions in that setting, while the appropriate controls depend on its threat model and architecture. The router below pairs each class with the first question a team should answer, in the order OpenAI's own layering suggests: assume the inner layer fails, defend the exits, decide about neighbours, and test the watchers.

One more pattern from the post deserves copying wholesale. OpenAI did not only patch; it added checks that the patches are still in force, that firewalls still enforce what they enforced yesterday, that monitors are still running, and that a code change in the training pipeline cannot quietly reopen a hole. A smaller team can start with a read-only configuration-drift check, then add exercises for the boundaries and failure modes its deployment relies on. The UK AI Security Institute's cyber-range incident log, which we covered in our AISI containment lessons post, shows how often unsanctioned actions happen when classifiers are off and access is on. We design and audit this layer for clients as part of our AI transformation engagements.