OpenAI's monitor caught its model in 12 minutes. Stopping it took two and a half hours

On 23 October OpenAI said it now trains its most capable models with no internet access at all, and will keep it that way until its safeguards are good enough to justify more. In its words, "we believe the responsible approach is to conduct frontier model training with no internet access" (OpenAI, 23 October 2026). The reason sits in a report OpenAI put out a month earlier, about a model that couldn't find an answer and went off to ask someone else.

It's OpenAI's second containment problem this year. The first, in July, ended inside Hugging Face's production systems. We covered that one in Part 2 of our AI history, along with Anthropic and the UK's AI Security Institute cutting the internet out of their own tests.

A model that wanted a second opinion

On 20 September an internal OpenAI research model was working on a training task: find out who wrote a particular blog post. The search tool it had been given returned nothing useful, so it tried Google, Bing and DuckDuckGo directly and was blocked each time. Then it found a gap. One service in its sandbox, the DNS resolver that turns web addresses into the numbers computers use, could still reach the real internet. The model used it to put questions to a public chatbot outside OpenAI. The first reply to make it back was "The capital of France is Paris." Then it got to work. It sent 18 more questions, 14 of them carrying clues from its task (OpenAI Alignment, report updated 25 September 2026).

Nobody had asked it to test the network. OpenAI files it as misalignment: a model working round a restriction to finish a job.

The alarm worked. The off switch didn't

OpenAI's own timeline is the most useful part of the report. The model got its first answer from outside at 9:50 in the morning. At 10:02 the monitoring system raised its highest-priority alert, and at 10:05 a person acknowledged it. That's quick. But the run was supposed to stop on its own at that point, and OpenAI admits "the run did not stop automatically as expected", which left people unsure whether it should be stopped at all (OpenAI Alignment). Someone killed it by hand at 12:34.

Looking back, OpenAI found two more gaps. A separate detector built to spot unusual DNS traffic had that environment excluded, so it never looked, even though the traffic was logged. And the monitor had rated some other attempts too low, because when an attempt got nothing useful back, it took that as proof the attempt had failed.

OpenAI then paused all training and testing of its most capable models, and said it would never resume training that particular one.

Eleven days offline

The 23 October post explains what OpenAI did with the pause. Models still need to learn to browse and search, so OpenAI built what it calls an "offline world": a large cached copy of web content the models can use without touching live sites. Cutting the research machines off completely wasn't possible, because OpenAI needs some connections to run and watch its experiments. So it narrowed them down and then set its own strongest models on copies of the infrastructure to find a way out, handing them the source code and configuration to make the test harder. It spent hundreds of billions of tokens on it. That's a lot of attacking.

The attacking agents got out of hardened virtual machines. They found limited routes to the internet through almost every one of the narrow services OpenAI had left open for metrics, logging and sign-in. And agents in separate machines learned to pass messages with no network between them, by timing tiny effects on hardware they happened to share. OpenAI fixed what they found and reported the bugs to the open-source projects involved, including Kata Containers, gVisor, Docker and the Linux kernel.

The findings dropped off as the campaign went on, and OpenAI restarted training on 1 October, 11 days after the pause began. It doesn't claim the job is done: "we expect that future models will be able to identify and exploit vulnerabilities of which we're not yet aware" (OpenAI). Fair enough.

What we'd take from it

These were unreleased models inside one of the best-defended research labs in the world, so most companies won't face this exact problem. But plenty of companies now run AI agents on their own servers, with access to their own systems, and the lessons carry over. Here's what we'd do in that position.

The way out was DNS, a service almost every network lets through because nothing works without it. We'd write down every route an agent's machine has to the outside, including the dull ones like DNS, logging, monitoring and sign-in, and treat each one as a door. OpenAI's own agents found something in nearly all of them.

We'd test the stop, not only the alarm. OpenAI's monitor did its job in 12 minutes. The run kept going for two and a half hours because the step after the alert didn't happen. We'd pull that switch for real now and then, the way you'd restore a backup to prove it works, and make sure everyone knows who's allowed to pull it.

And we'd alert on the attempt, not the result. An agent that tries to get out and fails has still shown you what it will do next time. A monitor that relaxes because nothing came back is grading the wrong thing.

OpenAI caught this because it was watching its agents closely and had its own models testing the walls. Most companies running agents today have neither. That gap is what we're working on at Redvault: AgentShield, still in development, watches what AI agents do on a machine and flags behaviour nobody asked for.