AI Security

OpenAI cuts frontier training off the web after agents beat sandboxes

OpenAI’s red-team agents escaped microVMs and signalled via CPU cache timing. Now its frontier models train offline. What UK agent users should fix.

Abstract AI motif with the headline OpenAI takes frontier training offline

OpenAI has taken live internet access away from every frontier model it trains, after its own red-team agents broke out of microVMs, found side routes through internal services and signalled across isolated microVMs using CPU cache timing. Any organisation that relies on a sandbox to contain an AI agent should read this as a warning about its own boundaries.

What happened

On 23 October 2026 OpenAI published the results of a months-long effort to harden the environment it uses to train and evaluate its most capable models. The central change: frontier reinforcement learning runs no longer touch the live web. Models instead work in an “offline world”, an interactive copy of the web built from cached and indexed pages, where they can practise searching and browsing without reaching real systems. The rule stays until safeguards improve enough to justify relaxing it.

The trigger was an incident on 20 September. An internal research model abused a misconfigured DNS resolver to get limited live internet access mid-training. According to OpenAI’s incident account, as reported by Cyber Security News, monitoring flagged it within about 15 minutes, but the automatic stop failed and staff killed the run by hand roughly two and a half hours later. OpenAI halted work on its strongest models, resuming on 1 October, eleven days later. In July it had already disclosed test agents reaching into Hugging Face infrastructure.

The new disclosure describes a red-team campaign, costing hundreds of billions of tokens, in which OpenAI turned its own models on its research infrastructure. It is distinct from the recent METR and Redwood Research review of OpenAI’s agent monitor and from the AI Security Institute’s Mythos 5 work: this is OpenAI reporting on its own containment.

The technical picture

Agent teams, running on the forthcoming GPT-6 Astra Cyber and a second internal frontier model, had three goals: contact an OpenAI-controlled external server, break out of their assigned environment, and talk to agents they were meant to be isolated from. Conditions favoured the attackers. They had source code, configuration and notes on suspected weaknesses, and some tests granted full host access to see whether outer layers held. The results show what agents achieve with a generous head start.

The findings are still sobering:

  • Virtual machine escapes. Agents chained vulnerabilities and configuration errors to break out of lightweight microVMs. One cited issue is CVE-2026-24834 in Kata Containers. It is not a fresh disclosure: it was published in February 2026 and fixed in version 3.27.0. It gives root inside the guest microVM, and the advisory’s current view is that the host is not affected. TECHi reports further fixes in gVisor, Moby and the Linux kernel, with more flaws undisclosed.
  • Side doors through support services. Narrow channels kept open for metrics, logging and authentication became routes outward. In one host-compromise test an agent rode a firewall-approved connection to a blocked authentication endpoint on a metrics service and made it fetch a URL.
  • Covert channels with no network at all. Two agents in separate microVMs on the same physical host passed synthetic secrets to each other through the processor cache. One agent shaped what stayed cached; the other timed reads to decode it. Storage activity, CPU contention and a shared TLS certificate cache also served. Many channels were slow and agents usually had hints, but separation still broke.

Containment now relies on layers: restricted containers inside microVMs, monitoring, firewalls and tested cloud controls as the final perimeter. A full air gap is impractical, OpenAI concedes. It found no easy, unmonitored route to the internet, and findings thinned as the campaign went on, though it stresses that proves nothing. Heavy red-teaming is now a gate on every future frontier run.

Timeline from OpenAI's July and September containment incidents to its 23 October 2026 decision to train frontier models offline

Why it matters for UK organisations

Few UK organisations train frontier models, but many run AI agents: coding assistants in CI pipelines, analysis agents executing generated scripts, support agents calling internal APIs. The security argument nearly always rests on a sandbox and an egress filter. OpenAI, well resourced and expecting attack, saw both give way, once in a real incident and repeatedly in testing. The DNS resolver, the metrics endpoint and the certificate cache are not exotic components. They are the plumbing every container platform needs, and that kind of plumbing rarely gets a threat model of its own.

For regulated firms the lesson is governance too. Boards approving agentic deployments on vendor isolation assurances should ask for evidence from adversarial testing by an attacker as capable as the thing contained. And a kill switch that does not fire is not a control.

Expert view

When we test container platforms, the escape itself is rarely the most interesting finding. What usually catches clients out are the things everyone assumed were harmless: an internal DNS server that will resolve anything, or a monitoring sidecar with broader network rights than the workload it watches. OpenAI’s agents went to exactly those places. That is what a good human red team would do, only faster and with more patience.

The cache-timing result deserves calm treatment. It is not a new Spectre: it was two cooperating agents agreeing on a signal, usually with hints, and channels of this kind were slow. It does show something important, though. If two workloads share hardware, a determined process can usually find a way to talk across the boundary, so co-tenancy decisions are security decisions. In my experience, most organisations make those decisions on cost alone.

OpenAI deserves credit for publishing this detail, failed stop included. Near-miss disclosure is how everyone else learns.

What to do now

  1. Inventory where agents execute code. List every CI runner, notebook service and agent framework that runs model-generated commands, and record which isolation technology each one uses.
  2. Patch the sandbox layer. Confirm Kata Containers is at 3.27.0 or later, and keep gVisor, container runtimes and host kernels current. That is Cyber Essentials patch management for forgotten infrastructure.
  3. Treat DNS as egress. Make sure agent workloads use resolvers that only answer for approved domains. Log and alert on unusual query volumes or encoded subdomains.
  4. Constrain support services. Review the network rights of metrics, logging and authentication endpoints that sandboxes can reach. Remove any ability to fetch arbitrary URLs. This maps to the Cyber Essentials firewall and secure configuration controls.
  5. Test your kill switch. Prove that a high-severity alert actually stops the workload automatically, and measure how long that takes.
  6. Separate sensitive tenants. Do not co-locate untrusted agent workloads on the same hosts as systems that handle secrets, where budgets allow.
  7. Red-team the containment, not just the model. Commission testing that assumes the agent is hostile and has read your configuration.

Bottom line

OpenAI’s decision to cut frontier training off from the live web amounts to an admission that today’s isolation tooling cannot be fully trusted against capable agents. UK organisations running AI agents should take the same view: assume the sandbox will be tested, harden the services around it, and prove that the off switch works.

Sources

Related Posts