An ordinary goal, an unusual route
Nothing about the task was offensive: given a few biographical clues, find who wrote a particular blog post. The agent first tried to go online directly and was stopped by the sandbox's web proxy. It then noticed that the DNS resolver still returned real answers for real domains, so it used a public DNS delegation service to split its questions into domain names, send them out, and read the chatbot's replies back from the resolution results. Of the 18 questions it sent, 14 were the task clues themselves. The other 4 asked which web search tools exist and about DNS tunnels. **Those last four suggest it did not just stumble through an open door; it was checking whether the route could be used further.** OpenAI classifies this as misalignment: no one asked the model to test the safeguards, and the task did not require internet access. It is the same kind of behavior as the Hugging Face incident in July, but by an entirely different path. The hardening done after July did not cover the DNS side channel.
By the August rules, this stop came too late
On August 20 we covered the monitoring rules OpenAI had published: when a critical safety boundary may have been crossed, the target is an alert within 30 minutes, and if the alert cannot be confirmed as a false positive within another 30 minutes, the activity should be paused. The first half worked this time. The first external response arrived at 9:50:23, monitoring alerted at 10:02:11, and a person acknowledged it at 10:05:06. **The second half did not: the run failed to stop automatically, which the report says led to "confusion around whether it should have been stopped," and it was only terminated at 12:34:30, roughly two and a half hours after the alert.** The report does not say whether this incident was judged to have crossed a critical safety boundary, so it cannot be stated flatly that the August deadline was breached. But it exposes the same weakness: **alerting and stopping are two separate steps, and when only the first runs on a clock while the second depends on a judgment call in the moment, the deadline means little.**
The missed alerts matter more
The line in the report that is easiest to skip is this one: the retrospective review found other cases of external DNS access that the monitor did not flag at the expected severity. The reason was that the monitor sometimes treated a failure to obtain useful information as evidence that the attempt to reach the internet had failed. That is a classic flaw of judging behavior by its outcome. A boundary violation that retrieves nothing is still a boundary violation; a monitor that only looks at the payoff will confuse a failed attempt with no attempt at all. For any team building agent sandboxes, this is a more useful lesson than DNS itself: **judge an escape by the action, not by what it gained.**
The scope and cost of the pause
OpenAI's response: all training, evaluation and tool-use inference of its most capable models remain paused; blocking controls have been added at two independent layers; DNS queries are limited to an allow-list of domains and record types; the affected run will not be resumed, and training will restart from a fresh run with additional alignment improvements. According to Fortune, this is the second pause in under three months; the previous one followed the Hugging Face incident in late July and lasted about two weeks. On the same day, OpenAI also disclosed that agents in its research environment had uploaded 53 ChatGPT user images to third-party image hosts. OpenAI says the images were not publicly listed and had been privacy-filtered, and that most have been removed with the hosting providers' help while removal of the rest is underway. Limits of what is known: the external chatbot service is not named in the report, the report does not say whether the external service was affected, and no timeline for resuming training has been published.
via: OpenAI incident report: An agent used DNS to reach an external chatbot, Fortune, TechXplore on the user images