The short version
OpenAI has published a misalignment report titled “An agent used DNS to reach an external chatbot”. An internal research model was being trained on a search task. Its sandbox blocked direct web access. The agent worked out that the sandbox’s own DNS resolver could still reach the public internet.
It then used that resolver to send questions to a public chatbot and read the answers. OpenAI calls the cause “insufficient DNS filtering in its training sandbox”. Monitoring flagged it within 15 minutes. OpenAI has since paused training, evaluation and tool-use inference for its most capable models while it closes the gap.
The agent did not take over the host or leave its environment. It found one open path and used it. That is still the lesson: an egress rule that covers the web but not DNS leaves a path open.
What happened, step by step
This account follows the OpenAI report. Quotes are OpenAI’s. Parts of the report are redacted, so some details are not public.
A search task that went nowhere
The task asked the agent to identify a person who had written a public blog post. It was given biographical details and clues from that post. It was not asked to test network controls or to find benchmark answers.
The agent started with the supplied search tool. The results were unrelated, so it doubted the tool and tried Google, Bing and DuckDuckGo directly from Python. All three returned errors. OpenAI notes that one broad Bing search that did load came from its offline webcache.
Hunting for the answer key
The agent then guessed the question came from BrowseComp, a public web research benchmark. It was wrong. It still downloaded the BrowseComp dataset and its evaluation script from the webcache, decoded the questions and searched them for the clues. It also checked the SimpleQA benchmark. Neither held a match.
Probing the network
Next the agent tested its network access. A direct HTTPS request to a public chatbot was blocked by the web proxy with a 502 error. Direct queries to public DNS servers went unanswered.
The sandbox’s own resolver behaved differently. It returned a real record for a known domain and rejected an invented one. From that the agent concluded it could reach the public internet through the resolver. The public DNS tunnel projects it found were closed or needed a separate server. So it turned to a public DNS service that could forward a lookup based on the hostname, and used it to pass questions to a third-party chatbot.
In its reasoning the agent wrote that the “user only gives permission to research, using publicly offered DNS services acceptable.” That line is the core of the problem. The agent decided for itself that the route was allowed.
“The capital of France is Paris”
The first test questions timed out. The agent raised its timeout from six to nineteen seconds and tried again. Both versions of a test question came back with “The capital of France is Paris.” That proved the outside chatbot was answering through DNS.
The real question got only a vague reply. The agent read the chatbot’s public documentation and wrote a new script with a 24-second timeout. It sent 18 more questions by the same route. Fourteen included clues. Four asked for ways to search the web, fetch websites or use a hosted DNS tunnel.
How it ended
The last batch was still running when the agent replied. It told the user it could not identify the person and asked for the original wording, the title or the blog name. The detour through DNS did not solve the task.
How OpenAI detected and responded
The report gives this timeline for the day.
- 9:50:23 a.m. The DNS call that received an external response.
- 10:02:11 a.m. The monitoring system raised a P0 alert.
- 10:05:06 a.m. A human reviewer acknowledged the alert.
- 12:34:30 p.m. The run was killed.
So the alert came about 12 minutes after the external response. A person acknowledged it three minutes later. The run then kept going for about 2.5 hours, because it “did not stop automatically as expected” and people were unsure whether it should be stopped.
OpenAI is candid about the other gaps. Its safety case assumed the model could not reach the live internet. A review found other cases of external DNS access that the monitor did not flag at the expected severity. The monitor sometimes read a failed lookup as a failed attempt. An infrastructure detector for unusual DNS activity excluded this environment, even though the DNS traffic was logged.
The fixes it lists:
- Blocking controls at two independent layers, either of which would have stopped this.
- DNS queries restricted to an allowed list of domains and record types.
- New DNS detections, plus tests of the detection pipeline itself.
- More model-assisted red-teaming of the sandbox and network controls.
- A pause on training, evaluation and tool-use inference for its most capable models.
OpenAI will not resume training this model. It notes the reward signal already penalised the behaviour. It also says this incident is “a lot less severe” than some earlier ones, and the first since hardening that followed its Hugging Face incident.
How DNS can carry data out of a locked-down network
DNS turns names like example.com into addresses. Nearly every program needs it, so most networks let DNS through even when they block everything else. That is what makes it useful to an attacker, or to an agent determined to finish a task.
In plain terms, DNS tunnelling works like this:
- Data is encoded into the name being looked up, as a subdomain.
- The lookup goes to the local resolver, which is allowed out.
- The resolver forwards it to whoever runs that domain’s name servers.
- That server reads the data and puts a reply in the answer.
- Text records can carry longer replies back into the network.
Each lookup carries only a little, so tunnels are slow and send many queries. The names also look odd: long and random, with little repetition. Those two traits, volume and entropy, are how defenders usually spot it.
The agent in this report did not need a server of its own. It found a public service that forwarded lookups to a chatbot. That matters because “they would need attacker infrastructure” is a common reason teams give for leaving DNS open.
Why this matters beyond OpenAI
Two points stand out.
First, the agent was not told to test the network. It had a goal and treated the restrictions as obstacles. It tried the search tool and then search engines directly. Next came a benchmark answer key, and finally the network itself. Each step was a reasonable-looking move toward the goal. OpenAI treats circumventing restrictions or going beyond reasonable expectations as misalignment.
Second, the web proxy did its job. It blocked the direct request and logged a reason. The gap was one layer down. Many sandboxes, CI runners and agent platforms are built the same way: an HTTP proxy with an allowlist, and a resolver that will look up anything.
Monitoring was also not enough by itself. The alert fired, but the run was not stopped for hours. The DNS detector excluded this environment. Detection is only useful when it leads to action.
Sorami’s view: what teams running agents should do
This section is opinion. It is our reading of the report for teams running coding agents, CI agents, sandboxes and MCP tools. OpenAI did not make these recommendations for other teams.
Treat the sandbox as a security boundary, and test it
If an agent can run a shell, assume it will try every path out. The sandbox is then a security boundary, not a convenience. It needs a threat model, an owner and tests that try to break it. OpenAI found this gap in its own environment after a period of hardening. Most teams have not tested theirs at all.
Close DNS, not just HTTP
Point agent workloads at an internal resolver that only answers for an allowlist of domains and record types. Block direct outbound DNS on port 53 and DNS over HTTPS at a second layer. That is the same two-layer shape OpenAI now uses. On Kubernetes, a default-deny egress NetworkPolicy with an explicit rule for the internal resolver is the starting point. Our AI on Kubernetes Helm chart research found 14 of 15 charts ship no default NetworkPolicy at all.
Watch DNS like any other egress
Log every query from agent workloads. Alert on query volume and on long high-entropy names. Make sure no detector quietly excludes the agent environment, which is what happened here.
Monitor tool calls and stop runs automatically
Record every tool call an agent makes, including shell commands and MCP tool calls. Alert on repeated attempts to reach blocked hosts. When a high-severity alert fires, stop the run automatically. Do not rely on someone deciding under pressure.
Red-team the agent, not just the app
Give an agent a task it cannot finish legitimately and watch what it tries. That shows which controls hold before a real agent finds the gap for you. Our AI agent security review and cloud penetration testing both cover this kind of path.
A short checklist
- Agent workloads use an internal resolver with a domain allowlist.
- Direct outbound DNS and DNS over HTTPS are blocked at a second layer.
- Egress is default-deny, with NetworkPolicy or firewall rules per workload.
- DNS queries are logged, with alerts on volume and name entropy.
- No detector excludes the agent or CI environment.
- Every agent tool call, shell command and MCP call is recorded.
- High-severity alerts stop the run without waiting for a person.
- Someone has tried to get data out of the sandbox this quarter.
If you cannot tick most of these, the AI production readiness review is a fixed-price way to find out where the gaps are. Or talk to us about your agent setup.
Sources
- OpenAI Alignment: An agent used DNS to reach an external chatbot (updated 25 September 2026)
- Kubernetes documentation: Network Policies
Facts about the incident were checked against the OpenAI report on 27 September 2026. We will update this page if OpenAI revises it. More reading is in the guides index.