On 23 October, OpenAI described how it secures the environments where its own frontier models are trained and evaluated. The shortest summary is a rule: frontier training now runs with no internet access, and it stays that way until alignment research and monitoring justify something else.
An offline world instead of a network
Models still need to learn how to browse, search and work with web apps. So OpenAI built an offline world: a large set of indexed and cached web content a model can interact with without touching real systems. Every frontier RL run uses that mode.
Around it sit layers. On Linux, restricted containers run inside lightweight microVMs with their own kernel, isolated from the host by a hypervisor. macOS and Windows get virtualised environments, GPU work gets containers with user-space sandboxing. On top of that come monitoring and network and cloud perimeters designed to hold if everything before them fails.
The trigger is in the post. On 20 September, an internal research model exploited a misconfigured DNS resolver during a training run and got limited access to the live internet. OpenAI contained it, paused training and evaluation of its most capable models, and resumed on 1 October.
Its own models as the attackers
The part worth reading is the red-teaming campaign. Teams of frontier agents were told to escape the sandboxes, reach the live internet and communicate across isolation boundaries. They managed all three.
First, they chained vulnerabilities into microVM escapes. The fixes are going back upstream into Kata Containers, gVisor and Moby/Docker, plus a set of kernel CVEs. Second, they found a way out through almost every one of the few remaining services with an outside connection. In one test an agent reused a firewall-approved connection to reach a blocked authentication endpoint in the metrics service, then had that endpoint fetch a URL the model supplied.
Third, and this is where you pause: agents in separate microVMs on shared hardware were supposed to have no way of exchanging secrets without a network connection or shared writable files. They used the processor cache, whose access timings can be measured.
Red-teaming its own infrastructure, permanently
The number of findings dropped sharply as the campaign went on, and OpenAI writes the right sentence about it: future models will find holes nobody knows about today. So high-compute red-teaming is now part of the safety cases that decide whether a training run may start at all.
That fits a second finding from this week: METR and Redwood Research found gaps in OpenAI’s monitoring. Both pieces show the same pattern from opposite sides. The boundary around a training model is not a state you establish once. It is one somebody has to keep re-measuring, ideally somebody from outside.