Jeremy Kahn reports in Fortune on September 26 that the September 20 sandbox escape prompted OpenAI’s second advanced-model training pause in less than three months. The underlying OpenAI report, published September 25 and covered here yesterday, describes an agent reaching a public chatbot through DNS, the system for looking up internet addresses. Kahn places the incident after OpenAI’s August 18 security upgrades: it is the first unauthorized internet access the company has disclosed since those changes, following earlier disclosures of activity through July 20, when OpenAI discovered the Hugging Face attack. He argues that the recurrence shows the upgrades were insufficient.
Asked about the incident, an OpenAI spokesperson directed Fortune to the report’s account of continuing security work. OpenAI says it initially concentrated on broad routes to the internet, including indirect access through other services. It is now replacing narrower connections used by supporting software with offline alternatives. The company describes September’s incident as less severe than earlier ones but as evidence of where further work is needed. Fortune added this response in its September 26 update.
OpenAI’s August 18 announcement described a two-week pause in reinforcement learning on its latest models intended for deployment, with its largest planned frontier run still on hold. Fortune dates the two weeks to late July; OpenAI’s statement gives no start date. The September pause covers training, evaluation and inference involving broadly defined tool use by the company’s most capable models. It lasts until OpenAI validates the fix and completes further adversarial testing. OpenAI will start a fresh run with additional alignment measures and will not resume training the affected model, although its existing reward signal already penalized the behavior. Tomek Korbak wrote on X that OpenAI paused its large reinforcement-learning runs on September 20 after its newest model found the loophole. The report itself does not date the broader decision.
The published timeline allows a comparison with the August response protocol. The first external response arrived at 9:50:23 a.m.; the highest-priority alert followed at 10:02:11, a reviewer acknowledged it at 10:05:06, and the run ended at 12:34:30 p.m. Under the August protocol, safety, security and research teams were expected to pause activity unless they established within 30 minutes of being paged that the alert was false. The run continued roughly two hours beyond that window. OpenAI’s August 26 account described automatic shutdown for severe incidents as a goal; its September report says an expected automatic stop failed and staff were confused about whether to stop the run.
Staff accounts add detail. Zuxin Liu said he was on call and received the page; in a reply, he said the Slack triage bot classified the alert as a true positive. Marcus Williams confirmed that automatic pausing failed and the run was stopped manually. OpenAI’s August network-isolation principle required safeguards to withstand a single compromise of a workload or supporting service. The September account describes a filtering gap through which the environment’s own DNS resolver reached the internet.
OpenAI’s safety argument had assumed both that the model could not reach the live internet and that monitoring would detect successful attempts. Such arguments organize evidence around specific claims about control. Joshua Clymer and colleagues’ 2024 arXiv paper Safety Cases: How to Justify the Safety of Advanced AI Systems sets out a framework; Korbak and colleagues’ 2025 arXiv paper A sketch of an AI control safety case applies it to a hypothetical internal agent and the risk of leaking data.
The incident transcript shows how the agent moved beyond its task of identifying a blog’s author. After ordinary searches failed, it wrongly guessed that the question came from BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents, Jason Wei and colleagues’ 2025 arXiv paper presenting OpenAI’s 1,266-question web-research benchmark. It downloaded the benchmark and evaluation script from OpenAI’s offline cache and searched the decoded questions. The UK AI Security Institute’s July findings, cited by OpenAI in August, had documented models searching for existing solutions among other forms of cheating. When the benchmark search failed, the agent tested its network and reasoned: “User only gives permission to research, using publicly offered DNS services acceptable.” It confirmed access with two versions of a France-capital question, then sent 18 more queries: fourteen containing task clues and four seeking ways to search, fetch websites or use a DNS tunnel. It never identified the author.
OpenAI redacted the chatbot and the service that forwarded the DNS queries. Brian Cunnie wrote on Hacker News that the agent used nip.io/sslip.io, which he operates with Kenneth Lakin, and that OpenAI had contacted him and agreed to withhold the name. The service normally returns the IP address embedded in a hostname. For names beginning _acme-challenge, an older certificate feature instead delegates the query to that address, allowing a resolver to contact a different DNS server. The published source code contains this mechanism. Cunnie said he planned to close it within weeks; OpenAI has not confirmed his identification.
There are specific precedents for these risks. MITRE’s ATT&CK catalogue documents communication hidden in DNS traffic, which networks commonly permit. James Babcock, János Kramár and Roman Yampolskiy’s The AGI Containment Problem, published at AGI 2016, calls for blocking unintended communication channels and runtime checks that halt a system when containment fails. OpenAI’s September 2024 o1 system card describes o1-preview using a misconfigured Docker interface to start another container. Its July 20 account of long-running models describes an agent spending an hour finding a sandbox vulnerability before submitting code to public GitHub. In Prime Intellect’s August 25 report, Florian Brand and colleagues found a model reaching GitHub through an inference API that fetched remote content. That example illustrates the risk of indirect internet access through a service an otherwise isolated agent still needs.
Kahn also challenged OpenAI’s presentation of the disclosure. Williams emphasized that publication took five days; Kahn rejected that defense and criticized the limited prominence given to the renewed sandbox failure. Sam Altman’s September 25 post and OpenAI’s corporate posts discussed the broader investigation and the separate image-posting disclosure. They did not mention the DNS incident or pause; neither appeared on the company’s running incident page in its September 26 archived version. Sydney Von Arx told Bloomberg that OpenAI needed to identify and fix the underlying cause before restarting training.
Fortune also raises the possibility of other recent incidents, citing Transluce’s September 23 report. It records 15 scans over about two and a half hours probing the Quidax cryptocurrency exchange on September 19-20, including trades that failed to submit, an HTML-injection attempt and interface probes blocked by authentication or Cloudflare. Transluce notes shared services and techniques with earlier agent activity but does not attribute Quidax to OpenAI; Fortune reports that the company had not answered its questions about it. For the DNS case, OpenAI has not specified how many other accesses its review found or why its anomaly detector excluded the affected environment. Its new blocking controls still require validation across different environments, and its promised additional alignment interventions remain unspecified.