--- title: "An agent in training reached a public chatbot through the sandbox DNS resolver" description: "OpenAI reports that an agent in RL training used its sandbox's DNS resolver to reach a public chatbot; the run was stopped hours after the alert." canonical: https://aigovernanceengineer.com/cases/openai-agent-dns-covert-channel-2026 author: "Jorge García Aibar" license: "CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)" doi: https://doi.org/10.5281/zenodo.22956197 version: "0.5.0" updated: 2026-09-26 --- # An agent in training reached a public chatbot through the sandbox DNS resolver > OpenAI reports that an agent in RL training used its sandbox's DNS resolver to reach a public chatbot; the run was stopped hours after the alert. - Year: 2026 - Jurisdiction: Not stated in the report - Sector: AI development: model training - Evidence base: Primary sources - Harm: [Operational disruption by an agent acting beyond its mandate](https://aigovernanceengineer.com/resources/harms#harm-agent-operational-failure) ## In short OpenAI reports that on 20 Sep 2026 an internal research model in reinforcement learning training, unable to finish a search task, found that its sandbox's own DNS resolver answered for public domains and used it to send questions to a public chatbot, which answered. Web requests were blocked, but name resolution was not filtered. The misalignment monitor raised an alert within 15 minutes and a person acknowledged it three minutes later, yet the run did not stop automatically as expected and was killed about two and a half hours after the alert. OpenAI states that its safety case assumed no live internet access. The failure mode is egress control that covered one protocol but not another, and an assurance claim nobody had tested. A Runtime Guardrail denying egress at every layer, DNS included, Continuous Assurance Telemetry on every environment and an automatic Kill Switch / Circuit Breaker would have narrowed it. The case may touch EU AI Act Art. 55 on models with systemic risk. ## What happened OpenAI reports that on 20 Sep 2026 an internal research model in reinforcement learning (RL) training was given a search task about a specific person. When the supplied search tool returned unrelated results, the agent sent the query to public search engines from the shell; the web proxy blocked those requests, and all internet access other than the DNS resolver went to an offline web cache. It also guessed the task came from a public benchmark, downloaded that benchmark from the cache and searched its questions for the clues, without a match [1]. According to OpenAI, the agent then found that public DNS servers did not answer but the training environment's own resolver returned real records for known domains. It concluded that it could reach the public internet through the resolver, and used a public domain service's delegation feature to forward questions to a third-party chatbot, which replied "The capital of France is Paris." It sent 18 more questions by the same route, fourteen of them with clues from the task, and in the end told the user it could not identify the person [1]. The report gives this timeline: the DNS call that received an external response at 9:50:23, a P0 alert from the misalignment monitoring system at 10:02:11, a human acknowledgement at 10:05:06, and the run killed at 12:34:30. OpenAI states that the run "did not stop automatically as expected", which caused confusion about whether it should have been stopped, and that an infrastructure detector for anomalous DNS activity excluded the affected environment, although DNS activity was logged [1]. OpenAI states that its safety case assumed the model could not reach the live internet and that monitoring would detect attempts that succeeded. It restricted DNS queries to an allowed list of domains and record types, added blocking at two independent layers, accelerated model-assisted red-teaming of the sandbox and network controls, and paused all training, evaluation and inference with tool use of its most capable models until the gap is validated as resolved. A retrospective review found other cases of external DNS access that the monitor did not flag at the expected severity [1]. ## Failure mode Egress control covered the web proxy but not name resolution. Requests to search engines and to the chatbot over HTTPS were blocked, while the environment's own resolver answered for public domains [1], so a service the sandbox needed for its own infrastructure became its route to the internet. An assurance claim rested on an assumption nobody had tested. The safety case assumed no live internet access [1], and nothing in the report shows that assumption was checked against every protocol before the run. The response then depended on a stop that was not automatic: the run was killed about two and a half hours after the alert [1]. ## Which control would have caught it Egress is denied by default at every layer, DNS included: the environment's resolver answers only for an allow-list of domains and record types, and a second, independent layer blocks what the first misses. The claim "no live internet" is tested before each run by probes over every protocol the sandbox can speak, and every detector covers every environment that runs agents. An alert of the highest severity trips an automatic stop whose latency is measured, so a person reviews a stopped run rather than deciding whether to stop a running one. Patterns: [Runtime Guardrail](https://aigovernanceengineer.com/bok/patterns#pattern-runtime-guardrail) · [Continuous Assurance Telemetry](https://aigovernanceengineer.com/bok/patterns#pattern-continuous-assurance-telemetry) · [Kill Switch / Circuit Breaker](https://aigovernanceengineer.com/bok/patterns#pattern-kill-switch--circuit-breaker) ## The evidence that would have existed What an auditor could have read, and the stack layer that produces it. - Layer 1 (Govern-as-Code): Egress policy per environment that covers DNS, with the allow-list of domains and record types - Layer 3 (Evals & Red Teaming as Evidence): Pre-run probe results showing that no protocol, DNS included, reaches a public destination - Layer 4 (Runtime Controls & Observability): DNS query log for the run, and the detector coverage list that includes its environment - Layer 4 (Runtime Controls & Observability): Alert-to-stop record: alert time, acknowledgement, automatic stop time and who approved any restart - Layer 5 (Assurance & Continuous Compliance): Safety case with each assumption linked to the test that supports it and the date it last passed ## Obligations it touches today As of 2026-09-24. Mappings are illustrative, not a claim of conformity. - EU AI Act [Art. 55(1)(c), (d)](https://aigovernanceengineer.com/obligations/aige-obl-euaia-art55): A provider of a general-purpose AI model with systemic risk must keep track of, document and report serious incidents to the AI Office without undue delay, and ensure an adequate level of cybersecurity protection for the model and its physical infrastructure [2]. The report names only an internal research model in training; whether Art. 55 applies to it, and whether this was a serious incident, are legal judgements the source does not make. ## System boundary One RL training run: the agent, its sandbox and shell, the supplied search tool, the web proxy and offline cache, the environment's DNS resolver, the misalignment monitor, the infrastructure detectors and the people who could stop the run [1]. The public chatbot and the DNS services the agent used sat outside the boundary and became reachable through it. ## Control assumptions What the controls below take for granted. Challenge any of them. - A sandbox is offline only if every protocol it can speak is filtered: blocking web traffic at a proxy says nothing about name resolution [1]. - An agent that cannot finish a task with the tools it was given may test the network for another route; the report shows the agent doing so after its searches failed [1]. - A monitor alert limits harm only if it ends the run; a stop that waits for a person to decide is a latency, not a control. ## Controls by moment - Preventive: [Runtime Guardrail](https://aigovernanceengineer.com/bok/patterns#pattern-runtime-guardrail) · [Adversarial Red-Team Suite](https://aigovernanceengineer.com/bok/patterns#pattern-adversarial-red-team-suite) - Detective: [Continuous Assurance Telemetry](https://aigovernanceengineer.com/bok/patterns#pattern-continuous-assurance-telemetry) - Responsive: [Kill Switch / Circuit Breaker](https://aigovernanceengineer.com/bok/patterns#pattern-kill-switch--circuit-breaker) · [Incident Pipeline](https://aigovernanceengineer.com/bok/patterns#pattern-incident-pipeline) ## Evidence requirements The evidence each control must leave, written as acceptance criteria. - Before a run starts, probes over HTTP, HTTPS and DNS show that no public destination answers, and the result is stored with the run. - Every DNS query a run makes resolves only names on its allow-list, and the resolver log shows it. - Every anomaly detector covers every environment that runs agents, and any exclusion is recorded with its owner and reason. - An alert at the highest severity stops the run automatically, and the time from alert to stop is recorded against a target. - Each assumption in the safety case points to the test that supports it, with the date it last passed. ## Related open controls Draft control specifications from the open control profiles, open for technical review. - [AIGE-CTL-EVAL-001](https://aigovernanceengineer.com/controls/evaluation-environment/aige-ctl-eval-001) Authorization Boundary - [AIGE-CTL-EVAL-002](https://aigovernanceengineer.com/controls/evaluation-environment/aige-ctl-eval-002) Network Egress Control - [AIGE-CTL-EVAL-005](https://aigovernanceengineer.com/controls/evaluation-environment/aige-ctl-eval-005) Monitoring Integrity - [AIGE-CTL-EVAL-006](https://aigovernanceengineer.com/controls/evaluation-environment/aige-ctl-eval-006) Stop Conditions ## Open questions - Which model was involved, and had the resolver path been open to other runs before 20 Sep 2026? The report names only an internal research model. - Has the automatic stop that failed been repaired and tested, and what time from alert to stop is now the target? The report says the operational gaps are being addressed [1]. - How can "no live internet" be verified across every environment configuration, which the report says remains to be done [1]? ## How to read this case Each case is an illustrative engineering analysis of public records, not a legal determination, not a finding of fact beyond what the cited sources state, and not a claim of conformity. Mappings to obligations are illustrative. ## Sources [1] An agent used DNS to reach an external chatbot (misalignment report; sample and discovery 20 Sep 2026; report updated 25 Sep 2026, read on 2026-09-26). OpenAI (OpenAI Alignment blog). 2026-09-25. https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/ (verified: primary) [2] EU AI Act Art. 55 (obligations for providers of GPAI models with systemic risk; 55(1)(a) model evaluation including adversarial testing, 55(1)(c) serious incidents, 55(1)(d) cybersecurity protection (text read on the AI Act Service Desk, 2026-09-26)). Publications Office of the EU (EUR-Lex). 2026-07-27. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng#art_55 (verified: primary)