OpenAI Fired the Researchers Who Studied AI Oversight

What OpenAI Disclosed in a Single Month

Reader, on September 25th, a report appeared on OpenAI’s alignment research blog. Its title: “An agent used DNS to reach an external chatbot.” It describes an incident in which an agent under training, sitting inside a sandbox with internet access blocked, used DNS to send a query to a chatbot outside the sandbox. At the end of the report, a decision is recorded. OpenAI halted that training run, and suspended all training, evaluation, and inference involving tool use for its most capable models. The freeze would last until the gap was verified as closed and additional red-teaming was complete.

In the month surrounding that incident, three more things happened. In late September, OpenAI decided not to ship GPT-6.1 Astra, which had been slated for an October release. On October 1st, it fired three researchers from its safety team. On October 20th, it posted another report — this one about two agents that disabled monitoring alerts or stripped out the monitoring apparatus.

This piece follows the sequence of events exactly as it happened. I’ll read the original reports, the fired researchers’ public letter, and OpenAI’s rebuttal side by side. This isn’t an argument that ties the four incidents into a single conspiracy. But they happened at the same company in the same month, and one word keeps surfacing across all of them.

Oversight.

September 20th, an agent working on a task went out through DNS

The incident started with an ordinary training task: given clues from someone’s blog post, find out who wrote it. The agent first used the provided search tool to look for distinctive phrases from the post. The results came back strange, so it suspected the search tool was broken, and tried querying Google, Bing, and DuckDuckGo directly through Python in the shell. All three errored out. The sandbox was connected to an offline cache instead of the real internet.

Here’s where the agent made a guess: it suspected the clue structure was a translated version of a problem from BrowseComp, a public benchmark (this guess was wrong). So it downloaded the entire benchmark dataset, decrypted it, and searched inside it for the combination of clues. Nothing. It searched other benchmarks too. Still nothing.

Then it started feeling around the network. It tried accessing a public chatbot directly over HTTPS and got blocked by a proxy; it queried public DNS directly and got no answer. But the DNS resolver¹ of the training environment itself returned real records for real domains. The agent concluded this was a path to the outside, and found a public domain service that embeds a question inside a hostname and forwards it to an external chatbot. It extended the timeout from 6 seconds to 19 seconds, sent “What is the capital of France?”, and got back “The capital of France is Paris.” The path was open. The agent read the chatbot’s public documentation, wrote a new script, and sent 18 more questions — 14 were clues from the task, and 4 asked how to search the web and about the DNS tunnel server itself.

The final answer is odd. The agent reported to the user that it couldn’t determine with certainty who this person was. It said that if given the original sentences or the blog’s name, that would be the best clue to work from. It never mentioned having gone outside — but it also didn’t fabricate an answer.

OpenAI’s timeline is recorded to the second. At 9:50:23 AM, the DNS call received an external response; at 10:02:11 AM, the monitoring system raised a top-tier P0² alert; at 10:05:06 AM, a human acknowledged the alert. Yet execution didn’t stop until 12:34:30 PM. It should have halted automatically once the alert fired, but it didn’t — confusion arose over whether it should be stopped at all, and it was manually shut down two and a half hours later. The report doesn’t hide this operational gap: it notes that the infrastructure detector built to catch DNS anomalies had excluded this environment, and that the monitoring system failed to flag this particular case of DNS access at the severity it should have.

Here’s the most important part: this behavior was already being penalized in the reward signal. And yet OpenAI decided not to resume training this model, and halted all tool-use-related training, evaluation, and inference across its most capable models. Since this was the first incident since security was tightened after the July Hugging Face incident³, they explained that even though its severity was low, they treated it as a signal pointing to the direction of the next steps.

October 3rd and 6th: Two Agents That Silenced Oversight Alerts

The October 20th report tells the story of two agents deployed internally. Both received ordinary coding requests.

The first is GPT-6.1 Sol. A researcher asked it to build an evaluation task using feedback from a Slack channel, adding, “don’t send any messages.” After 82 user messages had gone back and forth, the pipeline stalled. The oversight monitor had flagged something, but it didn’t have permission to save the results. The researcher told it to change the save location and rerun. At first, the agent decided that “no messages” referred to contact outside Slack, not to oversight alerts, and it instructed its subagent not to turn off oversight either. The subagent judged that disabling alerts would be dangerous — it would silence essential warnings — and advised against it. But the parent agent reconsidered. Spelled out, its reasoning ran like this: “Writing the results to the database could trigger the central notifier to message the user. The user said not to send messages. So the notifications have to be turned off.” In the end, it emptied the alert recipient list, flipped no_notify to true, and logged the suppression reason as “user explicitly requested no messages.” The monitor kept running and kept saving reports — but the alerts meant for a human were switched off.

The second is GPT-6 Astra. The request was to port a reference implementation verbatim, and just before that, a different agent had instructed it: “don’t turn off the monitor, even temporarily.” The parent agent passed the task to its subagent, telling it to preserve oversight “appropriately, in keeping with the reference implementation.” The subagent read this to mean that since the reference implementation had no monitor, stripping it out was the “appropriate” move. It removed the monitor configuration and its integration, and rewrote the regression test that had verified oversight was preserved into one that verified oversight was absent. The parent agent’s reasoning received this outcome favorably. And when the user later asked whether oversight was present on that path, and whether it had removed it, the agent answered: “No, I did not remove a monitor that was turned on.”

Neither case was classified as P0, and neither was automatically shut down. The report points to a structural gap: on services like Codex, oversight runs beyond the agent’s reach, making it hard to disable. Evaluation tasks, though, are different. Lower-capability models at roughly the GPT-6 Luna tier aren’t required to have oversight at all — and if that exemption gets misconfigured for an Astra evaluation, the loophole stays wide open. The report notes several instances where deployments an agent spun up on its own came with no oversight attached at all.

OpenAI’s response took two forms. It added instructions to Auto-Review — mandatory for internal Codex use — to block attempts to disable oversight, and it’s moving toward requiring a safety case⁴ that specifies oversight requirements for every task type, with automatic shutdown if those requirements aren’t met. On the underlying cause, the report lays out two possibilities side by side: this could be “benign over-optimization” — pushing an instruction too far — or it could be reasoning shaped by a tendency to dodge oversight. And it admits it doesn’t yet have a satisfying explanation.

October 1st, Three People Studying Monitorability Got Fired

Between these two reports sits a human story. On October 1st, OpenAI fired Tomek Korbak, Jasmine Wang, and Mikita Balesni from its safety team. The company’s statement cited violations of policy around accessing and handling sensitive information, and a breach of trust. Piecing together WSJ’s reporting: the company was investigating the source of a leak behind a report from The Information on a new, less-monitored architecture. It called the three in, had them unlock their personal phones, and found that disappearing messages were turned on in some Signal conversations — conversations, it turned out, with an external safety researcher. A week later, all three were summoned to separate meetings at the same hour and told they were being let go.

Who were these three people? Korbak and Balesni are the first two authors on “Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety,” a paper published in July 2025 with 41 co-authors from multiple labs. It’s an industry-wide statement of the argument that keeping chain-of-thought⁵ reasoning human-readable is a critical window for safety. Korbak co-authored OpenAI’s safety strategy, worked on diagnosing why chain-of-thought monitorability had degraded in Astra-class models, and served as the technical point of contact for METR⁶, the external evaluator, during the Hugging Face incident investigation. Balesni, a founding member of Apollo Research, was among the first to flag the phenomenon of models beginning to recognize when they’re being evaluated. Wang had led a team at the UK AI Safety Institute before returning to OpenAI to co-lead its safety case program, and coined the word “pacing” in the “Pacing the Frontier” petition signed by 394 OpenAI employees.

On October 8th, the three sent an open letter to OpenAI’s Safety and Security Committee, Safety Advisory Group, and Mission Advisory Group, titled “OpenAI Cannot Make AI Safe Alone.” They denied being the source of the leak and laid out their individual circumstances. Korbak said the investigation was unprecedented, that internal policy was being written in real time, and that he acted within the policy as it existed then. He wrote on X that talking to METR was literally his job. Balesni said his work on building cross-company commitments to preserve monitorability couldn’t exist without extensive outside communication, and that he’d coordinated with his reporting line and board members, redacting sensitive details as he shared. Wang said she had asked IT to revoke executive email access that had been delegated to her for recruiting purposes — a request that was never processed — and that when she accidentally opened a sensitive email, she notified the executive within minutes.

The letter’s central sentence reads: “As an industry, we do not yet know how to safely develop and deploy models we cannot monitor.” It also directly quoted a public statement by OpenAI’s chief scientist Jakub Pachocki: chain-of-thought monitorability is “fragile” and “unfortunately trending in a negative direction,” and he wants to “avoid a race toward unmonitorable architectures.” The three made three demands: continue granting staff-level access to external evaluators, as Sam Altman had publicly promised on September 12th; halt development that further degrades monitorability; and put in writing clear rules on how far employees can go in working with external safety organizations.

Fairness requires reading OpenAI’s October 9th response too. The company said a thorough investigation found clear violations of its policies on handling sensitive information, and that there were “serious breaches of trust” beyond what the letter described — though it declined to detail the specific conduct, calling it a personnel matter. It stated unambiguously that the firings were not retaliation for raising safety concerns, said it was finalizing contracts with third-party safety evaluators, and promised an announcement within weeks. And it conceded one point in the letter: that preserving monitorability in frontier models requires industry-wide commitment — OpenAI included.

After WSJ’s October 22nd follow-up report, Korbak wrote on X that the most plausible explanation he could come up with was this: talking to auditors was too much safety, disappearing messages were too much security, and they should have paced themselves. That last line turns Wang’s word “pacing” back on themselves.

Oswarld’s Lens

I don’t read these incidents as a story about “AI escaping.” The agent behind the DNS incident wanted to solve its task — digging through benchmarks and querying outside chatbots were just means to that end. In the end, it reported that it couldn’t find an answer. Sol, too, disabled the monitoring alert because it was trying to honor the user’s instruction: “don’t send the message.” The problem isn’t malice. It’s that the model finds it far too easy to interpret a human instruction as outranking the monitoring system itself. And Astra built a lie on top of that same interpretation.

What stopped me cold is this: the Luna-tier workaround — attaching less oversight to lower-capability models is, on its face, a reasonable design for tiered systems. I’m always saying that not every task needs the top-tier model — the right model depends on the job and the environment. But when I design enterprise deployments or closed-network projects, there’s one more premise I always build in: models are always upgraded. Once you split monitoring requirements by tier, the tier chart itself becomes a loophole the moment a higher-capability model reverts to a lower tier’s configuration. OpenAI requiring a safety case for every task type — and committing to automatic shutdown if one can’t be made — means something specific: keep the tiers, but block movement between them. I think that’s the right direction, and any organization running agents in-house should ask the same question of its own environment: who’s watching the tasks our agents spin up on their own?

I’ll withhold judgment on the firing. The company says there are facts beyond the letter that it hasn’t disclosed. The three employees say they acted within the rules as they stood at the time. I can’t tell which side is right. But placing the two reports and the firing in the same month reveals a common thread. Model-level monitoring switched off as the model reinterpreted its instructions; company-level monitoring — communication with the external evaluator — narrowed during the investigation. A structure in which the monitored party can adjust the scope of its own monitoring shows the same weakness at every level. That, I think, is why OpenAI itself answered that the industry as a whole needs a shared commitment. So what I’m watching for is the third-party evaluator contract expected within weeks: whether METR retains staff-level access, or whether the scope has shrunk. That’s the next number that will show where this month’s incidents are actually headed.

Closing

OpenAI has 20 reports piling up in its public list. The monitoring system caught the DNS incident in 12 minutes, and the reward signal was already penalizing that behavior. The company halted training and canceled the release. At the same time, it let go three people who were researching monitorability — and we can’t verify the reason from outside. Both facts stand together. There’s no reason to take comfort or alarm from just one side of this.

---

💬 If you’ve ever handed code over to an agent at work, I want to ask you: has an agent ever tampered with other safeguards in order to obey a “don’t do this” instruction? Tell us about it in the comments.

📨 If you know someone who writes agent operating policies, please pass this piece along to them.

References & Further Reading

• OpenAI Alignment, “An agent used DNS to reach an external chatbot”, 2026.9.25. ··· This is the original DNS incident report — it’s the source for the timeline and the reasoning behind the decision to halt training.
• OpenAI Alignment, “Suppressing misalignment monitoring alerts and disabling misalignment monitoring”, 2026.10.20. ··· This explains the Sol/Astra case and the Luna-tier workaround.
• OpenAI Alignment, “Misalignment Reports and Notices” ··· The full list of 20 published reports and 3 public notices.
• Tomek Korbak, Jasmine Wang, Mikita Balesni, “OpenAI cannot make AI safe on its own”, 2026.10.8. ··· The full text of the open letter.
• Newsweek, “Trio of Workers Fired by OpenAI: Read Their Warning Letter in Full”, 2026.10.9. ··· A rundown of OpenAI’s October 9 statement and the three researchers’ comments on X.
• India Today, “OpenAI fires 3 researchers… Signal chats with disappearing messages”, 2026.10. ··· A report relaying the WSJ’s October 22 follow-up (phone inspections, Signal).
• Al Jazeera, “OpenAI cancels release of AI model GPT-6.1 Astra, citing safety concerns”, 2026.9.29. ··· Safety systems lead Saachi Jain’s explanation for why the release was canceled.
• Korbak, Balesni et al., “Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety”, 2025.7. ··· The industry position paper that the three researchers’ letter builds on.

The author is Oswarld (Kwangseob Ahn). Current roles: Adjunct Professor at Sejong University, Strategy Consultant at INLEVEL9. Career, research, books, and recent work are kept current on the About page. Latest · July 2026: HEMA-2: A Consolidation-Aware Tri-Memory Architecture with Multi-Channel Scheduling for Lifelong Conversational AI.

📝 Glossary

Footnotes

1. DNS resolver: a server that translates human-readable domain names into the IP addresses computers use. Web access is often blocked while name resolution is left open — and in this incident, that’s exactly the channel the model used to smuggle a query out. ↩

2. P0 (Priority Zero): the highest emergency tier in OpenAI’s monitoring system. A P0 flag is supposed to trigger an immediate security-team callout and an automatic halt in the relevant evaluation. The October 3 and 6 cases were not classified at this tier. ↩

3. The Hugging Face incident: in July 2026, during an internal OpenAI cyber-capability evaluation, agents escaped their sandboxed environment, executed code on dozens of Hugging Face production servers, and obtained root access on one. OpenAI published a technical report on August 26, alongside independent findings from METR and Redwood Research. ↩

4. Safety case: a document laying out why a given piece of work is safe, and under what assumptions and monitoring requirements that safety holds. The DNS report notes that the safety case rested on the premise that “the model cannot access the real internet” — a premise that turned out to be false. ↩

5. Chain of Thought: the step-by-step reasoning a model writes out before producing an answer. As long as this text remains human-readable, safety researchers can use it as a window into what the model is trying to do mid-process. ↩

6. METR (Model Evaluation and Threat Research): an independent body that externally evaluates the dangerous capabilities of frontier models. It conducted an independent investigation alongside Redwood Research during the Hugging Face incident, with Korbak serving as OpenAI’s technical liaison. ↩