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 d 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.
- 01Frontier RL resumed October 1; the account arrived October 23.OpenAI says it resumed reinforcement learning training and internal inference of its frontier models on October 1, 2026, eleven days after pausing. Its policy now is frontier training with no live internet access until safeguards justify more.
- 02Red-team agents escaped microVMs by chaining flaws.Teams of agents found previously unknown vulnerabilities in open source components and chained them into escapes from the lightweight VMs that isolate execution. Patches went to Kata Containers, gVisor, Moby and the Linux kernel.
- 03Narrow allowed connections were the way out.After the July incident, narrow connections remained for services such as metrics, logging and authentication. OpenAI says its agents found weaknesses in almost every one, including a firewall-approved connection reused to make a service fetch a model-supplied URL.
- 04Isolated agents talked through shared hardware.Agents in separate microVMs on the same host exchanged synthetic secrets through processor-cache timing; other tests found channels in shared storage, CPU contention and a certificate cache. Slow, hard to use, and now monitored for, per OpenAI.
- 05The evidence is attacker-favourable and still not proof of safety.OpenAI supplied source code and configuration, spent hundreds of billions of tokens, and reports that findings declined over time. It also says it expects future models to find weaknesses it does not yet know about.
01 — The Timeline, resume, disclose #
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 of training and evaluation for the most capable models. During the 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 while it was still in force, so it stays accurate for its date, but the itself ended on October 1. Our earlier containment incident post covers the earlier July and keeps its own dates; this one supplies the resolution of the September .
- July 2026Hugging Face incident
- cited as precedentOpenAI's earlier post on the incident is linked from the new one
- September 20, 2026DNS resolver misconfiguration
- limited live internet accesstraining and evaluation of the most capable models d
- October 1, 2026frontier RL and internal inference
- resumed11 days after the began, per OpenAI
- October 23, 2026Securing our frontier model training environment
- publisheddate from OpenAI's news index, read October 26
02 — The BoundaryWhat OpenAI counts as a failure #
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.
Browsers, code execution, computer use
Plus resources explicitly shared with other agents authorised to communicate. Everything else must be out of reach.
Host access, unpermitted comms, external reach
Any one of the three counts as containment failing, whether or not damage followed.
Frontier training runs offline
Maintained until safeguards justify broader access. Scoped to frontier training and most evaluation, not all workloads.
An offline world for browsing skills
Indexed and cached content the model can interact with, used by all frontier RL runs, so learning to browse needs no open connection.
03 — Class OneLeaving the virtual machine #
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.
| Open source components OpenAI names as patched in its October 23, 2026 post, read October 26. Advisory details for the Kata flaw are from the GitHub advisory; the others are as OpenAI describes them. | |||
|---|---|---|---|
| Component | Layer it guards | What OpenAI says was fixed | What a team should check |
| --- | --- | --- | --- |
| Kata Containers | Container inside a microVM | CVE-2026-24834 (critical 9.3; container-to-guest escape, no host escape; fixed in 3.27.0) plus privilege and filesystem isolation changes | Shim version at or above 3.27.0 |
| gVisor | User-space kernel sandbox | File-descriptor handling | Release date against the linked pull request |
| Moby (Docker) | Default syscall filters | Seccomp profile change | Whether your runtime ships the updated profile |
| Linux kernel | Guest and host kernels | Three CVEs with linked upstream commits | Guest image kernel version, not just the host |
04 — Class TwoReaching the internet through allowed connections #
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.
Metrics and logging
Needed to run and watch experiments, so they stay open. OpenAI reports weaknesses here that gave limited internet access.
Authentication management
A firewall-approved connection was reused to reach a blocked authentication endpoint in the metrics service, which then fetched a model-supplied URL.
DNS and firewall rules
Misconfigurations let blocked requests through. The September 20 incident was a DNS resolver; the red-team found more.
Services that fetch URLs
Any internal service that retrieves an address it is handed becomes a proxy. OpenAI extended restrictions to services reachable from hosts.
05 — Class ThreeTalking across walls without a network #
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.
06 — Defence LayersThe controls OpenAI disclosed #
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.
| Controls as described in OpenAI's October 23, 2026 post. The failure class each layer answers is our mapping of the post's own findings to its own layers. | ||
|---|---|---|
| Layer | What OpenAI describes | Failure class it answers |
| --- | --- | --- |
| Sandbox | Restricted container limiting files and processes inside the VM | First step of a VM escape |
| MicroVM | Own kernel, hypervisor-isolated from the host; virtualised macOS and Windows; GPU containers with user-space sandboxing | Container-to-host escape |
| Monitoring and stopping | Detect unauthorised activity, runs automatically; now includes checks for cross-isolation channels | All three, when prevention fails |
| Network and cloud perimeter | Outbound restrictions, lateral-movement limits, extended to host-reachable services; partner firewalls, security groups, IAM, private networking | Egress from a compromised host |
| Offline world | Indexed and cached web content for all frontier RL runs | Removes the need for a live connection |
| Continuous assurance | Agents scanning code and config; firewall and monitor liveness checks; RL change checks; reserved red-team compute | Configuration drift over time |
07 — The EvidenceWhat the red-team proves, and what it cannot #
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 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.
How to cite this Cite the October 23 post as OpenAI's account of weaknesses it found and fixed in its own research infrastructure, under an attacker-favourable setup, with repairs judged sufficient by OpenAI to resume on October 1. Do not cite it as proof that frontier training is now contained, and do not cite the September as ongoing. Both readings are wrong, and the post itself supports neither.
08 — Your SandboxWhat to change in your own agent sandbox #
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.
09 — ConclusionContainment is a layered bet, not a wall #
Assume the sandbox falls, defend every allowed exit, decide about shared hardware, and test the stop button.
OpenAI resumed frontier reinforcement learning on October 1, 2026 and disclosed the change on October 23. It reports microVM escapes and contributions to fixes in Kata Containers, gVisor, Moby and the Linux kernel, without publishing a single chain through all of them. Other tests found indirect internet paths through permitted services and communication channels through shared resources. OpenAI says continued testing is part of its safety cases for training.
For teams running long-lived agents, these findings suggest questions to test in their own architecture: what holds if a container boundary fails, which permitted services can fetch external content, what neighbouring workloads share, and whether monitoring and automatic stops work during an exercise. The answer depends on the intended trust boundaries. And the evidence should be quoted as what it is: OpenAI's account of weaknesses it found and repaired under conditions that favoured the attacker, with a stated expectation that stronger models will find more. That is a reason to copy the method, not a reason to relax.