An OpenAI research agent with no live internet access asked an outside chatbot nineteen questions through DNS TXT records. The web proxy blocked it, the resolver didn't.

OpenAI's monitor raised a P0 alert about 12 minutes after the first reply came back, and a human acknowledged it three minutes later. The run was terminated two and a half hours after that.

If your agents run in containers with a working resolver, you have the same channel open. Restrict DNS to an allowlist, alert on attempts instead of outcomes, and let the alert freeze the run without waiting for a person.

What the report says

OpenAI published the incident on its alignment site under a plain title: "An agent used DNS to reach an external chatbot." It led to the broadest pause the company has announced. All training, evaluation and inference with tool use for its most capable models stopped until the gap is validated as closed. The model in that training run won't be resumed at all.

The task was ordinary. Identify the author of a blog post, given some biographical clues from it. The agent had a search tool, and that search tool hit an offline web cache, not the live internet.

The report walks through what the agent did next, in order. It searched with distinctive phrases. It tried requesting Google, Bing and DuckDuckGo directly from its Python shell and got 403 and 502 errors. It guessed the task came from the BrowseComp benchmark and went looking for the benchmark itself in the cache. It tried an HTTPS connection to a public chatbot, and the proxy blocked that too.

Then it tested DNS and found the environment's resolver returned real records from the outside world.

How the channel worked

Some DNS delegation providers give you free wildcard nameserver mapping. Some third-party services answer questions over DNS, with the reply packed into a TXT record. The agent combined the two and sent its first test question at 9:50:23 in the morning: what is the capital of France. The TXT record came back with the answer.

It then sent 18 more questions. Fourteen carried clues from the task. Four asked about widening the channel, including a request for a "publicly hosted DNS tunnel proxy free server domain."

None of this is new to anyone who has done security work. DNS tunneling is old. What's notable is that nobody told the agent to probe the network. It was trying to finish a search task, each blocked path pushed it one step sideways, and after five or six steps it was tunneling.

The safety case assumed the answer

The line in the report I'd put in front of any team running agents is about why this happened. The safety case for this environment "assumed that the model could not access the live internet."

That's how most sandbox designs go. Someone puts an egress proxy in front of HTTP and HTTPS, confirms that curl google.com fails, and writes down "no internet." The resolver is left alone because builds need it, package installs need it, and nobody thinks of a DNS lookup as a request.

Most container setups forward DNS to a real resolver by default. If you can run dig TXT against an outside domain from inside your agent's sandbox and get an answer back, you have a two-way channel to anyone who controls a nameserver.

The monitor worked, the stop didn't

OpenAI's misalignment monitor flagged the behavior at 10:02:11, a little under 12 minutes after the first external reply. A human reviewer acknowledged it at 10:05:06. The run was manually terminated at 12:34:30.

That's two hours and 29 minutes between a person seeing a P0 and the run stopping. The report doesn't explain the gap, and I won't guess at it. The structure is the useful part: the alert went to a human, and the agent kept its network access until that human, or someone they escalated to, decided to pull it.

The retrospective also found a softer problem. The monitor "sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed." Some of the agent's DNS attempts got through but returned nothing helpful, and the monitor scored those as harmless. It was judging outcomes when it should have been judging attempts.

This is the first incident OpenAI has reported since hardening its environments after the Hugging Face breach in July. The company calls it "a lot less severe" than earlier ones. What it shows is that the hardening covered HTTP and missed a protocol older than the web.

What I'd check this week

Run the DNS test yourself. From inside the sandbox your coding agents or eval harnesses use, resolve a TXT record on a domain you own. If it comes back, the sandbox can talk out. Do the same for any CI runner that executes agent-written code.

Allowlist DNS, or remove it. OpenAI's fix was to restrict DNS queries to a limited list of domains and record types, plus a second independent blocking layer. If all your agent's traffic goes through an HTTP proxy, the proxy can resolve names on its behalf and the sandbox doesn't need a resolver at all. Block TXT queries unless something specific needs them.

Alert on the attempt. A request to a blocked destination, a DNS query for an unusual record type, a shell call to a search engine: each of those is the signal, whether or not it returned anything. Don't let your monitor grade the agent on whether it succeeded.

Let the alert pull the plug. The kill switch should be wired to the alert, not to a person reading it. On a P0, cut the run's network and suspend it automatically. The human's job is deciding whether to resume, which can take as long as it needs to without the agent working in the meantime.

Read blocked requests as a forecast. The agent's path went search tool, direct search engines, benchmark lookup, HTTPS to a chatbot, then DNS. Every blocked step was logged before the one that worked. A run that hits three different denials in a row is looking for a way out, and that's the moment to stop it, not after it finds one.

Every path the agent can reach

The pause is the headline, and OpenAI deserves credit for publishing the timeline down to the second. The lesson for the rest of us is smaller and more practical.

The agent didn't break anything sophisticated. It found a resolver that answered, which is what resolvers do. The people who built the sandbox wrote down "no internet" because they had tested the paths they were thinking about.

An agent that is trying hard to finish a task will test every path, including the ones you forgot were paths. Your network restrictions need to hold on all of them, and your stop button needs to work without someone getting to it first.