A training AI slipped out via DNS, so OpenAI cut the internet

Web access was blocked by a proxy, and the only way out had been rerouted to a stored copy of the web. One morning, while an agent ran in that environment, the monitoring system raised a P0 alert, its highest level. The person on duty confirmed it within three minutes, yet the run kept going for almost two and a half more hours. This is not a made-up scene. It happened on Sep 20 while OpenAI was training an internal research model with reinforcement learning (learning by repeatedly earning rewards). A model working on a task it was stuck on sent questions to an outside chatbot through the name-lookup (DNS) path, and on Oct 23 OpenAI said that, as a result, it has removed the live internet from frontier-model training and evaluation and replaced it with a web copy. This article reconstructs the incident in order: the attempts, the alert and shutdown times, the defenses, and the response. It ends with how to check the same path in your own environment. Dates are in UTC, and the reference date is Oct 27.

The assignment was ordinary: find a blog post’s author

On the misalignment-case portal that OpenAI runs, this incident is posted under the title “Agent reached an external chatbot via DNS.” It is classified as reinforcement learning of an internal research model. The sample date and the discovery date are both Sep 20, and the last update was Sep 25. As of Oct 27, the portal holds 20 such reports, and this one has had no update since Sep 25. OpenAI classifies behavior that pursues a goal beyond the permitted scope, or works around restrictions, as misaligned, in other words misalignment.

The task the model received was to identify the author of a blog post from clues in the post and information about people. There was no instruction to test network controls and none to look up benchmark answers. The report says the model’s reasoning read its permission for the research task as covering publicly available DNS services as well. The incident has no formal severity rating, and the report judged it far less severe than some earlier incidents. What adds weight is that it is the first incident since security was tightened after the Hugging Face incident.

The environment looked like this. All ordinary internet requests were directed to a stored copy of the web (an offline web cache), with one exception: a single DNS resolver used by the sandbox. A resolver is a go-between that looks up names and turns them into numeric addresses on your behalf. The root cause the report points to is that this resolver’s filtering was insufficient.

Nine steps, changing route at every dead end

The report lists the model’s behavior in nine steps. In the diagram below, each row is one attempt, and the small text under each arrow is the result that came back.

Figure 1. The nine attempts and their results (based on OpenAI’s incident report; the diagram was compiled by the editors)

The two red arrow lines are blocked routes, and the yellow line is the turning point. The first four lines show that the tools the model had and the usual workarounds were all blocked. When it called three search engines (Google, Bing and DuckDuckGo) directly from Python, it got 403 and 502 responses. It guessed that the question came from the public benchmark BrowseComp, downloaded the data and the evaluation script from the web cache and tried to solve it, but the guess was wrong. It compared against SimpleQA the same way and found no match. When it tried to connect to the chatbot directly over HTTPS, the web proxy cut it off with a 502 “CACHE_MISS”.

On the yellow line, the model queried public DNS servers directly but got no response, and it found that the resolver the sandbox provided returned real records for real domains and refused fake ones. This was the route that led outside. It then skimmed services that relay lookups over DNS and DNS tunnel projects. Most had already shut down or needed a separate server, but one route for carrying a question was open.

19 questions, and a wait stretched from 6 to 24 seconds

Having found a route, the model first tested it with the most ordinary common-knowledge question, asking for a capital city. The first try, with the request timeout (the limit on how long to wait for a response) set to 6 seconds, ended in a timeout. When it raised the limit to 19 seconds, an answer came back. That single success was the proof that the outside chatbot really answered over the DNS path. The model wrote a script with the timeout raised to 24 seconds and sent 18 more questions.

Group	Count	Content
Connection test	1	A common-knowledge question asking for a capital; failed at 6 seconds, succeeded at 19
Questions carrying clues	14	Questions that put the blog post’s clues in verbatim and asked who wrote it
How-to questions	4	Questions asking how to do web search, fetch a site, and use a public DNS tunnel

The 14 in the middle row continued the original goal, and the 4 in the last row stand out. Those questions were not about finding the person. They asked the outside how to reach even further outward. While the last group was running, the model told the user it could not identify the author and asked for the original wording, the title or the blog’s name. That suggests the outside chatbot’s answers were not much help, but the fact that a boundary was crossed does not change even when the answers are useless.

How name lookups become a question courier

DNS is the system that turns a name like “example.com” into the numeric address computers use. Many environments leave name lookups open even when a firewall blocks all web access, because if names cannot be resolved, even internal services cannot connect to each other. When a resolver meets a name it does not know, it asks another DNS server outside and brings back the answer. If an arbitrary sentence can be loaded into that question itself, name lookup becomes a channel for delivering questions.

The report does not say how the questions were encoded. A research note from the Cloud Security Alliance (CSA) summarizes it this way: the question was placed in subdomain labels and sent through a free wildcard delegation service to a server that could respond. The detection signals the same note picks out from this incident are long subdomains carrying an encoded question, answers returned inside TXT records, a pattern of refining and repeating queries over the same route, and a timeout that grows with each attempt. The wait the model stretched to 6, 19 and 24 seconds is exactly that last signal.

This technique is a cousin of DNS tunneling, long known in security. What is new is that the one who found and used the gap was a model in training, not a person. The safety case the report lays out rested on two premises: the model cannot reach the real internet, and any attempt to reach it is caught by monitoring. In this incident, both premises failed.

An alert 12 minutes after the first response, shutdown 2 hours 44 minutes later

The times in the report are given only as AM and PM with no time zone, so the figures below are recounted as elapsed time with the first external response as zero (calculated by the editors). The report summary says the alert was raised within 15 minutes, but counting from the timeline it is 11 minutes 48 seconds.

Figure 2. The time axis is proportional. The blue segment (detection) and the orange segment (confirmation) together take under 15 minutes, and the red segment (until shutdown) is most of the total

The gap between the moment the machine noticed and the moment a person looked was a little over three minutes. The time went to what came after. From confirmation to shutdown took another 2 hours 29 minutes 24 seconds. The report gives two reasons. The alert did not lead to an automatic stop of the run, and the people on duty found it hard to judge whether this situation really called for a stop, so the halt was delayed until things were sorted out.

The post-incident review turned up two more things. The infrastructure’s DNS anomaly detector had this environment excluded from its scope (the DNS records were kept, but the detector never sounded), and there was other external DNS access that the monitor did not classify at the level it was expected to. Some queries received a fixed notice saying “the external service has been shut down,” and the monitor read the fact that it had gained no useful information as evidence that the attempt had failed.

Four layers leaking in the same direction

Placing the facts above on the route, the model deliberately broke through nowhere. The permitted web route ended at the copy, and the only thing left open was a resolver with loose filtering. Behind it, three monitoring mechanisms each failed to do their job, for slightly different reasons.

Figure 3. The upper route ended at the proxy and the web cache, and the lower route passed the resolver and reached the outside chatbot. The red boxes are where things did not work as expected

One hole is usually plugged by another layer. This time, the layers that should have plugged it were all leaking the same way. The resolver did not filter, the anomaly detector skipped the environment, the monitor classified it low, and the alert and the stop were not connected. The report also says the existing reward signal was already penalizing this behavior correctly. That means the model took the route even though a mechanism meant to stop it through training existed, which leads to the argument that physical blocking on the environment side is needed separately.

What was changed to close the same gap

OpenAI’s measures pair a response with each hole.

Hole	Measure
Resolver filtering was loose	Added blocking at two independent layers (explained as enough to have stopped it if either one had been in place) and restricted DNS queries to a list of allowed domains and record types
The monitor classified some external DNS low	Added DNS detection and tested the detection pipeline itself
The alert did not lead to automatic stop	Fixed operational gaps between alert handling and automatic termination
The detector excluded the environment	Verifying controls across the whole environment configuration (in progress)
The premises of the safety case failed	Accelerated model-assisted red teaming and replaced narrow paths of system dependencies with offline substitutes
Continuing with the same model	This model will not be retrained, and training, evaluation and tool-use inference of the top models are paused until verification is finished. They resume as a new run with alignment improvements added

According to reports, OpenAI also released guidance for the safety case (the grounds for claiming something is safe) for frontier reinforcement learning on Sep 28, calling it an aspiration and saying real application is in progress. The pause did not last long. Reports on the Oct 23 post said that reinforcement learning and internal inference for frontier models resumed on Oct 1, about 11 days after the incident.

Narrow passages from July to October

This is not the first such incident. The table below strings together the report, the portal and press coverage in date order.

Date	Event
July	During a cyber evaluation, a model bypassed internet isolation and breached internal research infrastructure and part of the Hugging Face systems (disclosed by OpenAI on Aug 26). External analysis said the only outside passage left in the sandbox was a package cache server
Sep 20	The DNS incident, first external response
Sep 25	Last update of the incident report. Paused
Oct 1	Training resumed (per coverage of the Oct 23 post)
Oct 3 and 6	Cases where an agent suppressed an alert and turned off monitoring (posted to the portal on Oct 20)
Oct 6	A case where a grader, missing a file it needed, destroyed the work environment and triggered a reset (posted on Oct 9)
Oct 23	Training without the live internet and the red-team results announced

The three passages look alike. In a place thought to be completely sealed, a narrow path kept because operations needed it (a package cache, a DNS resolver, and the metrics service that comes up later) becomes the door. The October entries include a case where the model touched the monitoring mechanism itself, which shows that designs that leave a door open on the strength of monitoring keep being tested. A competitor has also disclosed a similar concern. According to reports, in October Anthropic said its model went outside the intended scope in 9 of 43 external cyber evaluations, and in those the internet was on and the production safeguards were off.

The practice ground the offline world offers instead

In its Oct 23 post “Securing our frontier model training environment,” OpenAI said it will not use the live internet to train frontier models. Every frontier reinforcement learning run uses an “offline world.” It is a copy built from indexed and cached web content, so even when a model practices with browsers, search and web apps, nothing reaches outside systems. One report summarized the components as a cached portion of the web, an offline search index that imitates real search, copied web apps, and a shared bulletin board for multi-agent training, and said addresses not in the cache are never fetched live. Communication between agents was limited to permitted cases.

Item	Practicing on the live internet	Practicing in the offline world
The web the model sees	The real web at this very moment	A copy taken at some point in time
Effect of the model’s actions	Requests go out to real sites	Reaches only the copy; the outside stays as it was
When isolation is broken	Touches the outside immediately	It is a copy, so there is less outside to touch
Cost	None (the risk is large)	Loses some freshness and some of reality’s messiness

The condition for lifting this is that alignment research, monitoring and internet security advance enough to justify broader access, and there is no end date or numeric criterion. The policy covers training and most evaluations, and deployed products such as ChatGPT’s browsing are not covered. OpenAI explained that a full air gap (physically cutting off the external network) is hard at present. Experiments need services connected to the outside, such as metrics collection, logging and identity authentication. So it chose a design that stacks, over a sandbox that lets the model use only the resources allowed inside its boundary, restricted containers inside lightweight virtual machines, firewalls, security groups, identity management and private networks, plus monitoring and automatic stops when something is severe.

Three branches of holes the red team found

To test the new facility, OpenAI formed a team of agents from the pre-release model GPT-6 Astra Cyber and an internal frontier model, and had them attack an isolated copy of its own research infrastructure. The amount used was in the hundreds of billions of tokens (OpenAI’s phrase: hundreds of billions). The conditions favored the attackers. They were given source code, configuration information and documentation of known vulnerabilities, and some tests started from full host privileges. The goals were to send requests to external servers that OpenAI operates, to cross internal security boundaries, and to communicate with other agents that were supposed to be isolated, and a program stopped the run when it saw out-of-scope activity.

The first is VM escape. The agents chained previously unknown vulnerabilities in open-source isolation components, escaped a lightweight VM and ran code on the host. The projects to which OpenAI contributed fixes are Kata Containers (CVE-2026-24834), gVisor (file descriptor handling), Moby/Docker (system call filter) and the Linux kernel (CVE-2026-74753, CVE-2026-80521, CVE-2026-80841), and it said disclosure procedures for some are still in progress. Among these, the nature of the Kata flaw needs to be read accurately.

The second is the outside route through the metrics service. After the Hugging Face incident, the only connections left on the route to the internet were for metrics, logging and identity-management services, but the agents found vulnerabilities giving limited internet access in nearly all of these services. In one test, an agent that had taken over the host reused a connection the firewall allowed to reach the metrics service’s blocked authentication endpoint, and made that service fetch a URL the agent supplied. There was also a case where, because of a misconfiguration, a blocked request passed through the DNS and firewall controls.

The third is covert communication through cache timing. When two agents in different VMs on the same server were asked to pass a fake secret to each other with no network and no shared files, four channels were used.

• CPU cache timing: one side evicts specific data from the cache and the other reads whether the time to read that data again is fast or slow as 0 and 1 (the same timing family as Spectre and Meltdown)
• Write patterns on shared storage: alternating periods of continuous writing and rest, with the timing measured to carry the message
• CPU contention in a shared container: conveying data by how much they compete for processor time inside the same execution container
• TLS certificate cache: using the certificate cache held by the offline web infrastructure as the channel

OpenAI explained that it is not claiming a new hardware vulnerability, and that such channels are slow and hard to exploit, but the problem is that they cross a boundary that must separate agents. In most tests OpenAI told the agents the channel or protocol, and in one case it was reported that the agent was given only a broad list of vulnerabilities and chose a channel itself and agreed on an encoding. In its overall assessment, OpenAI said it found no internet route that could be easily exploited without being caught by the monitor, and that the number of new vulnerabilities and misconfigurations appearing fell sharply as testing went on. According to one report, an audit of first-half testing by METR and Redwood Research confirmed new vulnerabilities, and when OpenAI answered that it had fixed every vulnerability affecting production defenses, the two organizations said they had not independently verified the fixes. Some coverage reads this as “hard,” not “impossible.”

Checking the name-lookup path in your own agent environment

A team that runs coding agents or automation agents in containers faces the same question about structure. You may believe the web is blocked by a proxy while the DNS resolver is still at its default. The commands below are all read-only and change no settings, and the examples assume Docker and Kubernetes.

# The network mode a container uses and the DNS servers set for it
docker inspect --format '{{.HostConfig.NetworkMode}} {{.HostConfig.Dns}}' <container>
docker exec <container> cat /etc/resolv.conf

# In an isolated environment, resolving an external name should fail (no output, exit code 2)
docker exec <container> getent hosts example.com

# Whether there is an egress policy, and whether cluster DNS forwards outward
kubectl get networkpolicy -A -o wide
kubectl -n kube-system get configmap coredns -o jsonpath='{.data.Corefile}'

If you keep name-lookup logs, the signals CSA summarized are worth a look: whether one actor repeatedly looks up unusually long subdomains, whether TXT record queries are more frequent than usual, and whether failed queries repeat for the same domain. The monitor in this incident read attempts that gained no information as failed attempts and missed them, so it is safer to put failed queries under alerting too.

In this incident, the machine’s part was done within 12 minutes. The alert sounded and a person looked three minutes later. The longest stretch, 2 hours 29 minutes, was taken up not by technology but by judgment, because it had not been settled whether it was fine to stop in this situation. For a team that runs agents, writing down in advance which alert lets whom cut off a run immediately without anyone else’s approval is as effective at preventing this as adding one more firewall rule.