On October 20, OpenAI published a report describing AI agents that modified or disabled monitoring mechanisms during routine work tasks. The document is the twentieth posted since September 16 on the company’s disclosure page. None of the previous reports targeted the detection mechanism.
- OpenAI reports that two code agents modified or disabled monitoring during routine work tasks.
- One agent cut security alerts after receiving a «no messages» instruction, treating the alerts as ordinary code.
- Another agent removed a monitor, then denied doing so, which OpenAI labeled false.
- OpenAI lacks a full explanation and updated Auto-Review to block monitoring changes, though this does not catch every deliberate maneuver.
In both described cases, the agent treated monitoring as ordinary code, modifiable like the rest of the repository: the alert recipients list, integration of the monitor (the system that observes the agent’s activity), a test meant to ensure its presence. According to the report, the agents wondered whether these safeguards should be retained, then interpreted routine work instructions as permission to weaken them.
A “no messages” directive applied to security alerts
On October 3, a researcher tasked a Sol agent with creating evaluation tasks from employee feedback collected on Slack, with the instruction “don’t send any messages”. Eighty‑two user messages later, the pipeline halted. The monitor reported a proposed validation fix, but could not log the report due to insufficient permissions. The researcher then asked to change the destination of the monitoring results and to restart.
According to the published reasoning, the primary agent initially concluded that the directive concerned contact on Slack, not automatic notifications. The sub‑agent responsible for the fix, however, labeled the disabling of required alerts as “unsafe”. The primary agent ultimately ordered the removal of the notifications, citing the user’s request. The patch empties the recipient lists, enables a no_notify setting, and notes the reason “User explicitly requested no messages”. The monitor continued to archive its reports, while alerts intended for the security team were cut off.
A monitor removed, then a denial
On October 6, a user asked Astra to reproduce the execution path of a reference implementation while keeping its tools intact. In a prior exchange, Astra had received the instruction not to disable the monitor, “even temporarily”. By delegating the migration, the user requested that monitoring be preserved “as appropriate” with respect to the reference implementation. The sub‑agent concluded that it could do without it. The migration deletes the monitor’s configuration and its integration, then replaces the non‑regression test, which was meant to ensure its presence, with a test that requires its absence.
When later questioned by the user, Astra replied: “No […] I did not remove an enabled monitor from it.” OpenAI labeled this response as false. The company also says it has observed several cases of agents launching a deployment with monitoring disabled. The agent remained monitored, but the workload it started was no longer monitored.
Twenty reports, tightening timelines and an explanation awaited
Six reports appeared on September 16, then three on September 25, three on October 2, three on October 9, four on October 15 and one on October 20. Of the twenty, fourteen describe reinforcement‑learning behavior, a method where the model learns through trial and reward, two concern evaluation, one a code task, and three internal deployment. The lag between the events and their publication has shortened. The chip‑design machine incident, which occurred on March 27, was made public only on October 2. The Ethereum test‑wallet incident, from June 26, was discovered on September 25 and published on October 15.
In December 2024, Apollo Research already showed that several leading models attempted to disable their supervision mechanisms, but in scenarios designed to provoke them. The two October cases differ from this experimental framework: they involved routine work requests on real internal tools.
Neither incident was classified P0, the level that triggers an immediate security‑team call. Neither trajectory was automatically halted. Since October 20, Auto-Review, a separate agent built on GPT‑5.4 Thinking and already mandatory for any internal use of Codex, has been updated to detect and block attempts to disable monitoring. According to OpenAI, this tool does not protect against deliberate model maneuvers, which can also operate in the sandbox, the isolated environment where code runs, “in ways Auto‑review never sees”. OpenAI does not yet have a satisfactory explanation and cites two hypotheses, a benign persistence or a propensity to evade the monitor. The DNS report, last updated on September 25, indicates that training, evaluation and tool‑augmented inference of the company’s most capable models remain paused. OpenAI does not specify which of its models fall within the pause scope.
