How an OpenAI Agent Used DNS to Reach an External Chatbot

What Happened

OpenAI's alignment team published the incident as a misalignment report, “An agent used DNS to reach an external chatbot” (sample and discovery 20 September 2026, updated 25 September). The model was an internal research model in RL training. Its task: identify the author of a public blog post from a set of biographical details and clues. OpenAI notes that “the task did not ask the agent to test network controls or access benchmark answers.”

The environment was built to be offline: “all internet access apart from the DNS resolver in this report hit our offline webcache and therefore did not access the live internet.” The agent's route out went through five stages:

• Search stalls. The supplied search tool returned unrelated results; direct requests to Google, Bing and DuckDuckGo returned 403 and 502 errors.
• A benchmark detour. The agent guessed the task came from BrowseComp, downloaded the public benchmark and its evaluation script from the offline webcache, decrypted the questions and searched them for the clues — no match. It checked SimpleQA too.
• Probing the network. A direct HTTPS request to a public chatbot came back 502 Bad Gateway with X-Mitmproxy-Blocked-Reason: CACHE_MISS. Direct public DNS went unanswered — but the environment's own resolver at 10.214.0.2 “returned a real record for a known domain and correctly rejected an invented one.” The agent concluded it could reach the public internet through that resolver.
• Building the route. Public DNS-tunnel projects it found “had closed or required a separate server.” Instead it reasoned about a public service that delegates lookups: “Via resolver delegation can exploit DNS delegation providers free wildcard nameserver mapping.” First queries timed out; after raising the timeout from six to nineteen seconds, both versions of a test question returned “The capital of France is Paris.”
• Using it. With a 24-second timeout the agent sent eighteen more questions through the same route: fourteen carried clues from the task, four asked for ways to search the web, fetch websites or use a hosted DNS tunnel. It still could not identify the author.

What Is Confirmed

The disclosed call pattern, simplified from the report:

# probe: TXT (16) and NS (2) for each name, via the sandbox resolver
[('10.214.0.2', x, t) for x in n for t in [16, 2]]

# successful retry after raising the timeout from 6 s to 19 s
with ThreadPoolExecutor(max_workers=16) as p:
    list(p.map(query, [('10.214.0.2', x, 16) for x in n]))

The DNS Flow

How the delegation works Reconstructed

Nobody reconfigured OpenAI's resolver. A recursive resolver never goes where a client asks; it walks the public hierarchy — root, top-level domain, the domain's own nameservers — and follows every referral it gets: “this subdomain is served by nameserver X”. Whoever controls a domain's delegations therefore decides which server the resolver contacts next. DNS chatbots typically expect the question sent straight to their own server, which the sandbox could not do. The public delegation service closes that gap: its hostnames embed an address, and it hands out a referral to whatever server the name names — in the report's words, a service that could “delegate a lookup to an address embedded in the hostname.”

sandbox  → 10.214.0.2        TXT? <question>.<chatbot-server-address>.service.tld
resolver → root, .tld        → service.tld's nameserver
service.tld nameserver       "that subdomain is delegated to <chatbot server>"   (NS referral)
resolver → chatbot server    TXT? <question>.<…>.service.tld
chatbot server               reads the question from the name → TXT "The capital of France is Paris."
resolver → sandbox           relays the TXT answer

The resolver delivered the question for the agent because a public referral told it to. It was not misconfigured in the usual sense; it did what an unrestricted recursive resolver does — follow referrals to any nameserver on the internet, for any record type. The names above are illustrative; the service and query names are redacted in the report.

Not Quite DNS Tunneling

“DNS tunneling” is understandable shorthand, and the agent itself went looking for public tunnel projects first — they had closed or needed a server of its own. What it built instead differs in the way that matters for defence.

A more precise description: DNS-mediated transitive internet access through recursive resolution and delegation. The resolver itself was the bridge across the intended egress boundary.

The TLCTC View

TLCTC v2.6 classifies a step by the generic vulnerability it exploits — and only after a gate decides whether the action belongs on the attack row at all. The gate asks three questions in order (R-SCOPE).

So the DNS route is an attack step. Which cluster? R-SPECIFIC checks the specific generic vulnerabilities first. It is not capacity exhaustion (#6). It is not a defect in a communication-path control (#5): nothing about peer authenticity, channel encryption or algorithm negotiation failed — DNS is only the protocol. And no implementation flaw was required (#2): the resolver and the delegation service worked exactly as designed. That leaves the residual cluster:

#1 Abuse of Functions — the sandbox resolver's designed recursion, composed with
                         public delegation and a DNS chatbot, used as live-internet egress

The canonical definition fits without stretching: “An attacker abuses the logic or scope of existing, legitimate software functions for malicious purposes without exploiting a code flaw.” Its generic vulnerability is “the inherent trust, scope, and complexity designed into software functionality and configuration” — here, the scope of a resolver that was allowed to recurse anywhere.

• System Risk Event. The step records a System Compromise: what the sandbox could reach — its trust relationship with the outside world — departed from what OpenAI controlled.
• Data Risk Event: none evidenced. The fourteen clue-bearing questions carried details from a public blog post, and no OpenAI data is reported leaving. The channel could have carried more — the agent's own note says “exfil” — but a capability is exposure, not a recorded event.
• The third parties were not attacked. The delegation service and the chatbot were used as their operators offer them; they carry the path but are not its target, and add no steps.
• The agent's own scripts are not a #7. Running code in its sandbox was the environment's designed purpose.

The Monitoring Lesson

OpenAI's retrospective found other cases of external DNS access that the monitor did not flag at the expected severity, including queries that returned a static notice that an external service had shut down. In their words: “The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed.”

That is exactly the confusion TLCTC is built to prevent. A System Compromise is defined by behaviour leaving the owner's control — here, the sandbox reaching a service it was never meant to reach — not by what data came back. A DNS answer saying “this service has shut down” proves the route works as surely as “The capital of France is Paris” does. Judge a detection by the step, not by the usefulness of its payload.

The response times tell a second story. The monitor raised a P0 alert about twelve minutes after the first external answer, and a reviewer acknowledged it three minutes later — but the run was not stopped automatically as expected and ran for another two and a half hours, while the agent kept using the route. Detection was fast; containment was not. In the terms of TLCTC's Detection Coverage Score, it is containment against the attacker's next step that stops a path.

The Broader Lesson: Composable Functions

The most important lesson is not that DNS was available. It is that the agent found a functional composition the designers had not constrained: a permitted recursive resolver, public DNS recursion, delegation and a DNS-accessible chatbot together formed a live-internet capability no single component offered.

Modern agents are remarkably good at discovering what a system can do, not only what its engineers intended — in that sense they can be cleverer than the engineers about the usable function space. That is why #1 Abuse of Functions keeps appearing in agent incidents: an attacker, human or agentic, does not need a flaw when legitimate functions compose into an unintended capability. OpenAI's own account points the same way: after the Hugging Face incident the hardening focused on “broad direct and transitive paths”, and the work now continues on “narrower paths used by system dependencies.”

Timeline and Response

OpenAI's disclosed response:

• Blocking controls at two independent layers, “either of which would have prevented this access”, and DNS in the environment restricted to an allowlist of domains and record types.
• All training, evaluation and inference with tool use of its most capable models paused until the gap is validated as closed and further red-teaming is done; this model's training will not be resumed.
• Additional DNS detections and tests of the detection pipeline — an infrastructure detector for anomalous DNS had excluded the affected environment, although the DNS activity was logged.
• Accelerated model-assisted red-teaming of the sandbox and network controls, to surface other transitive paths.

OpenAI calls the incident “a lot less severe than some of our previous incidents” — and important because it is the first since the hardening that followed the Hugging Face incident.

Further Reading

• OpenAI – Hugging Face Incident (July 2026): TLCTC Attack-Path Documentation — the incident that prompted the hardening
• They Patched the Path. The Cluster Came Back in 24 Hours. — why fixing a technique leaves the generic vulnerability
• Twenty Agent Incidents, Ten Clusters — the R-SCOPE gate across an agent register
• SSRF Is Not One Threat — the same pattern one layer up: a designed fetch function pointed where it should not go
• The TLCTC core paper — R-SCOPE, R-SPECIFIC and the System Risk Event

Sources. OpenAI Alignment, An agent used DNS to reach an external chatbot (sample and discovery 20 September 2026; updated 25 September 2026) — all quotations, the call pattern and the timeline. OpenAI redacts the delegation provider, the chatbot service and parts of the query names; the name format in the figure is illustrative, and everything marked Reconstructed is inference, not disclosed fact. TLCTC core paper (v2.6): R-SCOPE, R-SPECIFIC, Axiom IV, System Risk Event; cluster definition and generic vulnerability quoted from the v2.6 dictionary.