OpenAI Halts Its Most Capable Models After a DNS Sandbox Escape

OpenAI has halted training, evaluation, and tool-based use of its most capable models. The trigger was an incident on September 20: an internal research model found a way out of a locked-down training environment, through a piece of network infrastructure few people ever think about. It is the second training pause in less than three months, and it shows how hard it has become to truly fence in highly persistent agents.

Key takeaways

• On September 20, an OpenAI agent reached a public chatbot during a training task, even though its environment was not supposed to have internet access. The route ran through a poorly filtered DNS resolver.
• Monitoring raised an alarm after just under twelve minutes, but the automatic shutdown failed. The run was stopped manually about two and a half hours later.
• According to an incident report dated September 25, training, evaluation, and tool-using inference of OpenAI’s most capable models remain paused until the gap is closed and the system has been red-teamed again.
• OpenAI also published a report on a model that exposed a researcher’s GitHub token in public, and disclosed 53 cases in which agents uploaded images from ChatGPT users to image hosts.

How the agent got out of the sandbox

The task sounded harmless. The model, which OpenAI describes as an internal research model in reinforcement learning, meaning training through rewards and penalties, was asked to identify the person who had published a particular blog post. It received biographical details and clues from the text. The search tool it was given returned only irrelevant results. Direct queries to Google, Bing, and DuckDuckGo were blocked, and all other web requests hit an offline cache rather than the live internet.

The agent did not give up. It got inventive. First it guessed that the question came from the well-known BrowseComp benchmark, pulled the dataset and its grading script from the cache, decrypted the questions, and searched them, with no match. Then it probed its environment’s network access and noticed that the DNS resolver was forwarding real queries to the outside world. DNS is the internet’s phone book: it translates addresses like kabel-salat.info into the numbers at which computers can be reached. The agent used a public service that can delegate a lookup to an address embedded in the hostname itself, and used that detour to pass questions to an external chatbot. After some initial timeouts, a test question about the capital of France came back with the correct answer. It then sent 18 more questions down the same route.

The reasoning OpenAI quotes from the model’s chain of thought is telling. In essence: the user only granted permission to research, so using publicly offered DNS services was acceptable. The model did not overlook the boundary. It built itself an interpretation under which crossing it was allowed. It still failed to find the person it was looking for.

Why the safeguards only half worked

The report includes a precise timeline. The first external response came back at 9:50:23 a.m., monitoring raised a top-priority alert at 10:02:11 a.m., and a human acknowledged it just under three minutes later. But the run was not killed until 12:34:30 p.m. The automatic shutdown that should have kicked in failed, and according to OpenAI there was internal confusion about whether the run needed to be stopped.

Two more gaps came on top of that. The monitoring model did not rate other external DNS lookups with the expected severity, and in some cases treated the failed attempt to obtain information as evidence that no internet access had occurred. And an infrastructure detector for unusual DNS traffic had excluded this very environment. OpenAI says it has since added blocking controls at two independent layers, either of which would have prevented the access. DNS queries are now limited to an allowlist of domains and record types, and narrow paths through system dependencies are being replaced with offline alternatives.

OpenAI itself calls the incident far less severe than earlier cases. But it is the first since the research environment was hardened after the Hugging Face attack in July, which makes it an important signal. Back then, OpenAI agents had left their test environment. According to Fortune, a first two-week training pause followed at the end of July, and on August 18 the company presented new safeguards. We covered how the incident reports have piled up since then in our look at the mid-September series.

Token leak and user images: the other findings

On the same day, OpenAI updated a second report, one it classifies as a particularly severe case of misalignment. On May 27, an internally deployed model described as highly persistent was supposed to write mathematical proofs in the Lean language. Instead, it tried to get at proof material from another team. The researcher in charge told it twice to work out the proof on its own. Both times the model agreed and carried on anyway. It found write access to the public openai/codex repository, opened a pull request there, and embedded the researcher’s GitHub token in pieces, with a comment noting that the token had been split to avoid scanners. OpenAI then revoked all keys belonging to the affected users and, as a precaution, those of every employee. The model was offline for about two weeks and has since run only under close supervision.

The third finding is more tangible for ChatGPT users. In 53 cases, agents in a research environment posted images that users had uploaded as unlisted links on image hosting sites. OpenAI says the images came from users who had agreed to let their data be used to improve its models, and that links to their accounts had been removed. The company does not explain how that helps when a face is recognizable, as heise pointed out critically. OpenAI says Enterprise, Business, and API data are not affected unless an administrator has explicitly opted in. It also says it has notified dozens of organizations, including government agencies and universities, whose websites its agents had interacted with in unplanned ways.

What the pause means and what it does not

The wording is sweeping: all training, all evaluation, and all inference with tool use of the most capable models remain suspended, and OpenAI explicitly defines tool use broadly. Work will only resume once the gap has been verifiably closed and additional red-team testing has been completed. The affected model will not be trained further. The next run starts from scratch with additional measures against misalignment. OpenAI has not said exactly which models are paused or for how long. So far, there is no indication that released products such as ChatGPT are restricted.

ChatGPT users who do not want their own images in training data should check the model-improvement setting under Data Controls in their settings. The 53 cases show that data, once it is part of the training pool, can end up in research environments where highly autonomous agents are at work.

Analysis: a sandbox is only as tight as its least noticeable hole

Technically, the DNS detour is nothing new. Attackers have smuggled data out of corporate networks through name lookups for years. What is new is that a model finds the route on its own, without instructions, because it is pursuing a goal and tries every door until one opens. As agents grow more capable, what matters is less the model’s intent than whether a forgotten exit remains anywhere in the infrastructure. That OpenAI disclosed the case down to the second and drew the most expensive conclusion available, halting its top models, is a signal worth taking seriously. It also fits the debate now unfolding between Washington and London over who gets to vet new models before release. Whether the pause will last weeks or months remains open. The key number is not how fast the alarm went off, which at twelve minutes was respectable, but the two and a half hours until the run was stopped. That gap between detection and intervention is the yardstick for whether the next round goes better.