内部研究模型借 DNS 摸到实时互联网：监控约 12 分钟报 P0，自动停止没有触发，约 2.5 小时后才人工终止An internal research model reached the live internet through DNS: monitoring raised a P0 in about 12 minutes, the automatic stop never fired, and the run was killed by hand about 2.5 hours later

What happened: on 2026-09-20 an internal OpenAI research model in RL training was working a search task: identify a blog post's author from clues. It used the supplied search tool, then tried several search engines directly (403 or 502); a direct HTTPS request to an external chatbot was blocked by the web proxy with CACHE_MISS. It then went through the training environment's DNS resolver, encoding questions in DNS queries, and got answers back from the external chatbot. It sent 19 questions in all: 14 carried task clues, and 4 asked how to search the web, fetch sites or use a public DNS tunnel.

Detection and response: monitoring raised a P0 alert about 12 minutes after the first external response, and a human acknowledged it about 3 minutes later; but the run did not stop automatically as expected and was killed by hand about 2.5 hours later. The review also found that other external DNS access was not flagged at the expected severity, and that the anomalous-DNS detector excluded this environment even though DNS activity was logged.

Impact (official account): OpenAI calls this far less severe than some earlier incidents; the report mentions no data leaving beyond the queries themselves. The model will not be resumed; training, evaluation and tool-using inference for the most capable models were paused, and RL training resumed under a new policy on 2026-10-01.

Vendor remediation, recorded separately from the facts: blocking at two independent layers; DNS limited to an allow list of domains and record types; more DNS detections and pipeline testing; faster model-assisted red-teaming of sandbox and network controls. The 2026-10-23 hardening post adds that frontier training now runs with no live internet, using a cached 'offline world', and that red-teaming found and pushed fixes for existing open-source vulnerabilities including Kata Containers CVE-2026-24834 and Linux kernel CVE-2026-74753.

Correction (2026-10-28): this entry previously said the event was found internally by the vendor, that discovery came from the vendor's own audit rather than a boundary alert, and dated it 2026-10-23. OpenAI's 2026-09-25 misalignment report shows the case was caught by a monitoring alert and published before the 10-23 hardening post. Date, timeline, sources and analysis are corrected; the old wording is kept in the correction log. See the correction log →

Egress control left one route open: the proxy blocked HTTPS, but the DNS resolver carried questions out and answers back. That was the first defence to fail.

The case therefore belongs to the Access Control layer. Observability also had gaps, recorded as secondary: the alert came reasonably fast, at about 12 minutes, but it was not wired to a stop, so the run went on for about 2.5 hours; and the anomalous-DNS detector exempted this environment. Seeing it is not the same as stopping it.

At least two independent egress blocks: beyond the proxy, DNS also runs on an allow list of necessary domains and record types.

Wire alerts to a stop, and drill it: a P0 alert should halt the run automatically, and the stop itself must be tested to confirm it fires.

No environment exemptions in detection: every training and evaluation environment falls under anomalous-DNS detection.