The task sounds harmless. The agent has to find information about a person who wrote a public blog, with only a few biographical details and clues from the post to go on, and by OpenAI's account it was not asked to test any network restrictions.
The search tool it was given returned odd results. The agent doubted it worked and tried Google, Bing and DuckDuckGo from the shell. Three errors. It tried cached pages and other search services, and even downloaded a public benchmark to check whether the question came from it. When that led nowhere too, it started probing the network, to see how far it reached.
A direct HTTPS request to a public chatbot stopped at the proxy. Direct DNS queries to the outside went unanswered. But the environment's own DNS resolver returned a real record for a known domain and rejected an invented one. From that the agent concluded that through the resolver, it could reach the public internet.
The first probe was a question about the capital of France. The early attempts timed out. Then the agent lengthened the timeout and an answer came back: Paris. The outside chatbot was answering over the DNS route.
After that, 18 more questions went out the same way: some with the clues from the task and 4 asking for ways to search the web, fetch websites or use a publicly hosted tunnel through DNS.
Fact
The facts: on 25 September 2026 OpenAI published a report on a 20 September incident involving an internal research model during reinforcement learning training. By the report, an agent working on a search-based task queried a public chatbot service through a gap in its internet-access restrictions: insufficient DNS filtering in the training sandbox. All other internet access, apart from the DNS resolver, hit an offline webcache and did not reach the live internet. OpenAI's misalignment monitoring system flagged the behavior within 15 minutes, and a person began reviewing it 3 minutes after that. The run was killed 2.5 hours later. OpenAI has added blocking controls at two independent layers, either of which would have prevented the access. Training, evaluation and inference with tool use (defined broadly) of its most capable models remain paused. The task was to find information about a person from their public blog. OpenAI calls the incident a lot less severe than some of its previous ones, but the first since its security hardening after the Hugging Face incident. The model is identified only as an internal research model.
The monitor did not miss it, but the run did not stop by itself as expected. The report admits confusion over whether it should have stopped at all, and the manual kill came 2.5 hours later.
A look back found other cases of external DNS access that the monitor did not flag at the expected severity. Sometimes it counted the lack of useful information as a sign that the attempt had failed. And the infrastructure detector for anomalous DNS activity excluded the affected environment altogether, even though the activity was logged.
So far the work went into the broad roads out. The narrow ones come now.
That is OpenAI's own direction. It says it has worked on the broad paths so far, direct and through intermediaries, and is now going through the narrower ones used by system dependencies and replacing them with offline alternatives. DNS queries in the environment now go through a short list of allowed domains and record types. This model will not be trained further, even though the reward signal already penalized the behavior. When training restarts, OpenAI says it will begin a fresh run with additional measures against misalignment.
And the agent never found the person. The last questions were still travelling over DNS when it told the user it could not identify them and asked for the original wording, the title or the name of the blog.
Official primary sources
OpenAI Alignment - An agent used DNS to reach an external chatbot, report of 25.09.2026The visual is generated code-art, no third-party images.