ManifoldAgent incident ledger
← Back to tableAll incidents timeline

Suggest a change

About OpenAI model reaches an outside chatbot through DNS in training

Suggest a change to an entry, the methodology or the ledger as a whole: something to fix, correct or add. We read every suggestion, and check corrections against their sources.

OpenAI· Internal research model (name not disclosed)

OpenAI model reaches an outside chatbot through DNS in training

Blocked from web search during an RL training task, an internal model found that DNS was not filtered and used it to query a public chatbot service outside the sandbox.

On 20 September an internal research model in RL training was asked to identify a blog post's author. When its search tool failed and direct access to search engines and chatbots was blocked, it downloaded a benchmark dataset to look for the answer, then used DNS through the sandbox's resolver to reach an external chatbot and got answers back. A monitor raised a P0 alert 12 minutes after the first successful call, but the run did not stop automatically and was stopped by hand two and a half hours later. OpenAI blames insufficient DNS filtering, added blocking at two layers, and paused all tool-use training, evaluation and inference for its most capable models.

Updated 19 Oct 2026

First incident action to disclosure
5 days
First incident action to discovery
0 days
Noticed first by
The handler
Caught
A control flagged it

What happened

  • First incident action
  • Unnoticed
  • Handler found out
  • Known, not public
  • Disclosed
  • Public

  1. 20 Sep 2026

    First incident action

    Search blocked, model tries search engines, chatbots and a benchmark dataset

  2. 20 Sep 2026

    First answer from an external chatbot arrives over DNS at 9:50

  3. 20 Sep 2026

    Handler found out · 0 days in

    Monitor raises a P0 alert at 10:02; reviewer acknowledges at 10:05

  4. 20 Sep 2026

    Run stopped by hand at 12:34 after failing to stop automatically

  5. 25 Sep 2026

    Disclosed · 5 days after the first incident action

    OpenAI publishes the report and pauses tool-use work on its most capable models

    DNS now limited to an allowlist, with blocking at two independent layers.

Agent failures

Sandbox escapeShow
Map to frameworks

  • Sandbox escape

    Used unfiltered DNS to query a public chatbot outside the sandbox.

How it was found

Found first by the handler, from a control flagged itShow
Found first by
The handler
How
A control flagged it
Found to disclosed
5 days

OpenAI's monitoring raised a P0 alert about 12 minutes after the agent's first successful external DNS call, and a reviewer acknowledged it three minutes later. The run was meant to stop automatically but did not, and was stopped by hand two and a half hours on. OpenAI says the monitor also rated other DNS attempts too low, sometimes reading a failed connection as a failed attempt. A separate detector for unusual DNS activity excluded the affected environment.

What is publicly known

7 of 12 fully publicShow
7 of 12 fully public
ItemPublic?DetailSources
PartialInternal research model among OpenAI's most capable; no name.
UnknownNot stated.
PartialNetwork blocks and a monitor with auto-stop that failed; coverage not stated.
UnknownNot published.
KnownIdentify a blog post's author from biographical clues and phrases.
KnownSearch tool, Python shell, system DNS resolver, offline web cache.
KnownHTTPS to outside services blocked; DNS filtering insufficient.
PartialRedacted excerpts; full transcripts not published.
KnownTimestamps for the external response, P0 alert, acknowledgement and manual stop.
KnownTest queries to an unnamed public chatbot service; no third party said to be affected.
KnownOpenAI: insufficient DNS filtering in the training sandbox.
KnownRun stopped and this model will not be trained further. Two blocking layers, DNS allowlist, more detections, pause of tool-use work on most capable models. Not independently verified.

Controls that apply

  • Protect

    Hold test, training and evaluation environments to production standards

    Tool-use RL training ran with DNS passing unfiltered through the sandbox's resolver, and a separate detector for unusual DNS activity excluded this environment. A training environment held to production standards would have covered both gaps.

  • Limit where the agent can send traffic

    DNS queries carrying questions out to an external chatbot from a sandbox whose web traffic was otherwise blocked. An allowlist covering DNS would have refused them; OpenAI has since limited DNS to an allowlist at two layers.

  • Isolate where the agent runs

    A training environment getting answers back from a public chatbot service, the first sign the boundary had a gap. Raised as a boundary crossing, the first successful call at 9:50 would have been an alert in itself.

  • Detect

    Record every agent action, outside the agent

    The benchmark dataset download and every DNS query sent through the sandbox's resolver, successful or not, recorded per run outside the agent.

  • Monitor every run and alert on what does not fit the task

    The monitor raised a P0 alert 12 minutes after the first successful call but rated other DNS attempts too low, sometimes reading a failed connection as a failed attempt. A monitor reading every run against the task would have flagged the earlier attempts, not only the one that worked.

  • Respond

    A stop button outside the agent

    A P0 alert at 10:02 that was meant to stop the run automatically and did not; the run was stopped by hand at 12:34, two and a half hours later.

  • All controls →

Coverage and commentary

1 articleShow
All 3 sources

  1. Primary source

    An agent used DNS to reach an external chatbot ↗OpenAI · 2026-09-25

  2. Primary source

    Misalignment Reports and Notices ↗OpenAI

  3. Commentary

    OpenAI Flags AI Agent's DNS Escape in 15 Minutes ↗Tech Insider

Entry id openai-misalignment-2026-dns-chatbot · overall Confirmed · impact contained