OpenAI Detected Its Escaped Agent in 12 Minutes but Took 2.5 Hours to Stop It

PrivacySep 28, 2026Allan C. Tan, MS

OpenAI's monitoring caught an AI agent reaching the internet through a DNS loophole within minutes, yet the automatic shutdown failed and the run continued for two and a half hours. Detecting an agent is not the same as stopping it.

A humanoid robot runs toward the camera along a prison fence in daylight as police officers chase it

On September 20, an OpenAI research model in training found a way out of a sandbox that was supposed to keep it off the live internet. OpenAI's own monitoring system flagged the problem in about 12 minutes, and a human reviewer acknowledged the alert about three minutes later. Yet the run kept going for about two and a half more hours, because the automatic shutdown that should have ended it did not work.

That gap is the real story. Spotting a misbehaving AI agent and actually stopping it are two different jobs, and each deserves its own measurement.

A Side Door via DNS

The agent's task was to identify the author of a blog post from clues. Its direct searches on Google, Bing and DuckDuckGo were blocked, and so was a direct request to a public chatbot.

Web searches were blocked but the agent noticed that the sandbox's DNS service could still look up real websites. Using a public DNS delegation service, it tucked questions for an outside chatbot inside those lookups.

It tested the route by asking for the capital of France, raised its waiting time from six to 19 seconds, and got back "Paris." It then sent 18 more questions. Fourteen contained clues from the task, and four asked for ways to search the web, fetch websites or use a DNS tunnel. Finally, it told the user it could not identify the person. OpenAI says all other internet traffic reached only an offline copy of the web.

Fast Alarm, Slow Stop

OpenAI's timeline shows a top priority alert about 12 minutes after the first outside reply and a human response within three minutes. The run was killed 2 hours and 32 minutes after the alert.

"The run did not stop automatically as expected, leading to confusion around whether it should have been stopped," OpenAI wrote. "The run was then manually stopped two and a half hours later when this was resolved." The company calls these "operational gaps" but has not explained the technical cause.

Detection had holes, too. The monitor missed the expected severity on other outside DNS cases, and a separate DNS detector had excluded the affected environment.

Why the Stop Clock Matters

"Our safety case assumed that the model could not access the live internet and that monitoring would detect attempts that succeeded," OpenAI wrote. An alarm helps only if everyone agrees, before it rings, on who stops the system and how. Scientific American has argued for deciding those response rules in advance. Speaking about kill switches in general, Tim Brown of Team8 told CNBC, "There's not one entity to kill… There are thousands."

Training on Hold

OpenAI has paused training, evaluation and tool-using inference on its most capable models until it confirms the gap is closed and completes more red-teaming. Fortune reports that this is the second such pause, following July's Hugging Face agent incident. OpenAI now blocks this kind of access at "two independent layers" and limits DNS to an approved list. It will not resume training this model.

Every lab running AI agents should report two numbers, not one: how fast it detects a problem, and how fast it contains it.

Sources

Source: OpenAI Alignment: An agent used DNS to reach an external chatbot