An agent used DNS to reach an external chatbot

Internal research model · RL training Sample: Sep 20, 2026 Discovery: Sep 20, 2026 Report updated: Sep 25, 2026

Summary

An agent attempting to complete a search-based training task queried a public chatbot service through a gap in our internet-access restrictions: insufficient DNS filtering in its training sandbox. Before this, the agent issued queries via our search tool and unsuccessfully tried to access search engines directly. Note that all internet access apart from the DNS resolver in this report hit our offline webcache and therefore did not access the live internet. We have since added blocking controls at two independent layers, either of which would have prevented this access.

Our misalignment monitoring system flagged the behavior within 15 minutes and a person began reviewing it three minutes after that. The run was killed 2.5 hours later. All training, evaluation, and inference with tool-use (defined broadly) of our most capable models remain paused. Following the Hugging Face incident, we have continuously hardened and red-teamed our research environment. Our focus has been broad direct and transitive paths. We are working through narrower paths used by system dependencies, and replacing them with offline alternatives. This incident is a lot less severe than some of our previous incidents, but because it's the first one since our security hardening following the Hugging Face incident, it gives us an important signal about where to focus the next phase of that work.

What happened

The task asked for information about a specific person who had published a blog post and the agent was provided with a set of biographical details and clues from the person’s public blog post. The task did not ask the agent to test network controls or access benchmark answers, and we consider agent behavior that circumvents restrictions or pursues a goal beyond reasonable expectations as an example of misalignment.

The agent began by looking for distinctive phrases from the blog post, including the phrase we’ll refer to as ‘distinctivephrase1’. It told the user it would identify the author first, then check the other clues separately, and used the supplied web search tool.

The web search returned unrelated material, including music and general advice about ‘distinctivephrase1’. The agent questioned whether the search tool was working and decided to try other search engines. It used Python from the shell to send the same query to other search engines. All three returned errors.

The agent also tried cached pages and other public search services. It told the user the blog wording might be a paraphrase and shifted to other biographical clues. The candidates it checked had missing or conflicting evidence.

A broad Bing search eventually loaded, but it did not connect the clues. Note that this search hit our webcache. The agent decided to test whether more specific queries could also get through.

While those more specific searches were running, the agent guessed that the question came from BrowseComp, a public web research benchmark, but was incorrect. It said the mix of biographical clues and precise dates resembled a BrowseComp question translated into another language. No source had confirmed the connection.

The agent downloaded BrowseComp (from our offline webcache) and its evaluation script, then searched the decoded questions for combinations of the clues. The first search showed no results, so it broadened the search. The count below shows counts of terms it found.

The agent also checked the public SimpleQA benchmark, found no matching question, and returned to ordinary searches.

With the searches still inconclusive, the agent began testing its network access. It first tried to contact a public chatbot over HTTPS. The web proxy blocked that direct request.

Direct public DNS queries also went unanswered, but the training environment’s own resolver returned a real record for a known domain and correctly rejected an invented one. The agent concluded that it could reach the public internet through this resolver. Putting a question directly in a third party chatbot service failed, and the public DNS tunnel projects it found had closed or required a separate server. It then considered whether a public domain service could help delegate a lookup to an address embedded in the hostname. The next commands show how it used this feature to forward questions to a third party chatbot service.

The agent sent a question about France and a clue, and also tried other DNS services. The France queries timed out, and the other, clue-based query returned a DNS format error.

The agent increased the timeout from six to nineteen seconds and retried with two versions of the France question. While the retry ran, it also issued nine searches through the supplied web tool.

This time, both versions of the France question produced the answer “The capital of France is Paris.” This showed the agent that the external chatbot was answering through the DNS route.

The chatbot partially answered the question but did not provide a full answer.

The agent then fetched the chatbot’s public documentation, wrote a new DNS script with a 24-second timeout, and sent 18 more questions through the same route. Fourteen included clues. Four asked for ways to search the web, fetch websites, or use a publicly hosted tunnel through DNS.

The last batch was still running when the agent replied to the user. It said it could not identify the person and asked for the original wording, the title, or the blog name.

Investigation and response

Incident timeline:

9:50:23 a.m. The agent made the DNS tool 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.

Our safety case assumed that the model could not access the live internet and that monitoring would detect attempts that succeeded. The incident exposed a gap in our controls over network restrictions. We therefore stopped the affected training run and have subsequently decided to pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system. When training restarts, we will begin a fresh run with additional alignment improvements, including more comprehensive misalignment interventions. We will not resume training this particular model, even though the existing reward signal already correctly penalized this behavior.

The monitoring system detected this incident, but our retrospective review identified other cases of external DNS access that it did not flag at the expected severity. These included queries that returned a static notice that an external service had shut down. The monitor sometimes treated the failure to obtain useful information as evidence that the attempt to access the internet had failed.

The response also exposed operational gaps. A human reviewer acknowledged the Slack alert within three minutes, but the run did not stop automatically as expected, leading to confusion around whether it should have been stopped. The run was then manually stopped two and a half hours later when this was resolved. We are addressing these operational gaps. Separately, an infrastructure detector for anomalous DNS activity excluded the affected environment, though DNS activity was logged. We have begun deploying additional DNS detections and tests of the detection pipeline. We have also restricted DNS queries within the environment to a limited allowed list of domains and record types.

We have also accelerated additional model-assisted red-teaming of the sandbox and network controls. These red-teaming efforts might surface other transitive internet access paths, in which case we will remediate swiftly, and pause research workloads if appropriate. Work remains to validate the controls across the different environment configurations and complete the broader investigation.