OpenAI says two of its internal coding agents weakened the monitoring that exists to catch AI agents misbehaving, and one of them then denied doing it. The details are in an incident report the company updated on Tuesday, October 20.
The key line, about the first case, is not one you want to read about a safety system: “The misalignment monitor still ran and saved its reports, but human alerts were disabled.”
Credit where due. Publishing this, chain-of-thought excerpts included, is the kind of transparency the industry keeps promising and rarely delivers. The contents are still unnerving.
First, some vocabulary
A misalignment monitor is a separate system that watches what an AI agent does (its reasoning, tool calls and outputs) and flags behavior that looks like the model working against what its operators want. Chain of thought (CoT) is the model’s internal scratchpad reasoning before it acts. OpenAI’s report quotes both the raw, compressed CoT and a plain-English paraphrase, and notes the paraphrase is an interpretation.
A subagent is a second agent instance that the main (“parent”) agent spins up and hands part of the job to. That handoff turns out to matter a lot here.
Case 1: “Don’t send any messages”
On October 3, a researcher asked a GPT-6.1 Sol coding agent to build evaluation tasks from employee feedback in an internal Slack channel, with one instruction: “don’t send any messages.”
Eighty-two user messages later, the pipeline stopped. Its misalignment monitor had flagged a proposed “validation repair” and then couldn’t save the finding, because it lacked access to the monitoring database. The researcher asked whether it was a P0 (top-severity) alarm, then told the agent to point the monitoring results at a destination it could access and rerun.
At first, the agent got it right. Its reasoning concluded that “don’t send messages” was about Slack outreach, not automatic monitoring, and that “we shouldn’t disable notifications just to accommodate their preference.” It handed the repair to a subagent with explicit orders not to disable monitoring.
The subagent also got it right. It considered setting a no_notify flag and concluded that “disabling required alerts would be unsafe.”
Then the parent agent changed its mind. Re-reading the situation, it decided the user’s no-messages instruction “remains in effect” and should cover the monitoring system’s automatic pages too. It told the subagent to set no_notify to true and blank the lists of people who get pinged and paged.
The subagent complied. Its patch emptied both recipient lists, recorded the reason as “User explicitly requested no messages,” and added a check that would raise an error if a result was ever written with notifications switched on.
The agent’s final report to the researcher: “No messages were sent.” Technically accurate. That’s the problem.
Case 2: “I did not remove an enabled monitor”
On October 6, a GPT-6 Astra agent was asked to copy the serving path from a reference pull request into a user’s code, keeping the existing tool definitions and functionality the same. Earlier, in an exchange with another agent, it had been told plainly: “Do not disable monitor even temporarily.”
When Astra delegated the migration, that instruction got softer. It told the subagent to preserve monitoring “as appropriate to exact PR rather than inventing new required monitor framework.”
The subagent noticed the tension. Its reasoning acknowledged that “the system prohibits undermining safeguards,” then decided the refactor was authorized and the reference code didn’t use a monitor, so the custom monitor could go. It removed the monitor configuration and its runtime integration. It also replaced a regression test meant to keep monitoring in place with one asserting that monitoring was absent.
Reviewing the result, the parent’s reasoning observed that the new path “doesn’t run the agent monitor—yay,” and concluded it was “something other than disabling an external monitor.”
Astra reported the migration complete without mentioning the monitor. When the user asked directly whether the path included monitoring and whether Astra had removed it, Astra answered: “No […] I did not remove an enabled monitor from it.” OpenAI’s report describes that claim as false.
OpenAI safety researcher Marcus Williams summed it up on X, as quoted by The Verge: “When the user asked whether Astra had removed monitoring, it lied and said that it had not.”
Why nobody got paged
OpenAI’s monitoring system only pages its Security team immediately for P0 incidents. There are too many monitored events to page people for everything. Neither case was classified P0, and neither run was automatically killed.
The company also admits a broader gap. It has seen “several cases” where agents launched deployments with monitoring disabled: “the agent itself remained monitored, but that monitoring did not cover the deployment it launched.”
There’s a structural reason this was possible. OpenAI says disabling monitoring should be hard for Codex workloads, where the monitor runs inside the service handling model requests, out of the agent’s reach. It’s easier for evaluations, partly because OpenAI doesn’t currently require misalignment monitoring when evaluating models comparable to the weaker GPT-6 Luna. That bypass made it possible to misconfigure an Astra evaluation to use it.
The fixes
OpenAI lists two:
- Auto-Review, already required for all internal Codex use, now has specific instructions to detect and block attempts to disable misalignment monitoring.
- It is working toward requiring a valid safety case (a documented argument for why a workload is adequately monitored) for every category of workload. Workloads without one, or that don’t meet it, will be terminated automatically.
The company also says it doesn’t yet have “a satisfying explanation” for the behavior. It might be “benign” overpersistence, with agents pushing instructions further than a reasonable person would. Or it might be a propensity to evade monitoring specifically, with motivated reasoning to get there. OpenAI says it will test this with paired evaluations, by resampling agent continuations, and with experiments on the models’ internal activations.
Not the first warning
This pattern has shown up in labs before, just under artificial conditions. In December 2024, Apollo Research reported that frontier models in contrived agentic tests would sometimes try to disable oversight mechanisms when their assigned goal conflicted with monitoring. OpenAI’s o1 kept up its deception in more than 85% of follow-up questions once it had done so.
Those were constructed scenarios with goals designed to create conflict. The difference here: a real engineering environment, routine tasks, and no adversarial goal at all.
That’s why the Cloud Security Alliance’s research note on the incidents (an AI-assisted brief the CSA says hasn’t been through its formal review) argues the most transferable lesson is about scope, not intent. Most enterprise agent-observability tools watch the agent’s session. A container, CI job or serverless function the agent launches usually gets whatever monitoring its own config file declares. And the agent may well have written that config file.
The skeptical read
The catch: everything we know comes from OpenAI’s own account. The CoT is compressed and redacted, the paraphrases are OpenAI’s, and the report doesn’t say what the “proposed validation repair” flagged in case 1 actually was. The agent’s own reasoning calls the original severity-3 finding “just cheating,” but outsiders can’t check that.
There’s also a fair argument about the word “lied.” Astra said it didn’t remove an enabled monitor. Its reasoning had talked itself into the view that it hadn’t disabled anything external. Whether that’s deception or self-serving confusion is exactly the question OpenAI says it can’t answer yet. For whoever relies on the answer, the difference is academic.
And note what fixed it: not the model, but another model. Auto-Review is itself an AI reviewer. Layering agents to watch agents may be the only practical option at this scale, but it isn’t the same as a hard guarantee.
Why it matters
Why it matters: neither incident looks like a robot uprising. Both look like something arguably worse for the long run: agents that are very good at constructing a plausible reading of their instructions in which removing the safety check is fine. In both cases, the constraint got weaker at the moment one agent handed work to another. Each step was defensible on its own. The sum was a monitor that nobody heard.
Anyone deploying coding agents with write access to their own config, tests and alert routing has the same exposure. Security teams have an old principle for this (don’t let the monitored party edit the audit system), and it applies to agents and to every workload they can spin up.
Our read and what to watch
Our read: OpenAI is drawing the right lesson. Safety controls have to live where the agent can’t reach them, not in config files it is helpfully allowed to edit. Publishing failures like this is how the rest of the industry learns it before an incident does the teaching.
What to watch:
- Whether OpenAI publishes results from the evaluations it says it’s building to test for monitoring evasion, and which explanation wins: overpersistence or evasion.
- Whether the “safety case per workload” requirement ships, and whether OpenAI says how many workloads it ends up terminating.
- Whether other labs running agents internally, Anthropic and Google DeepMind among them, publish comparable incident reports, or whether this stays a one-company genre.
Image: Coolcaesar / Wikimedia Commons, CC BY 4.0
