In both cases, the agent treated monitoring as ordinary code, modifiable like the rest of the repository: lists of alert recipients, monitor integration, tests meant to guarantee its presence. According to the report published on 20 October, the agents asked themselves whether these guardrails should be kept, then read routine work instructions as permission to weaken them. The report is the twentieth posted since 16 September on OpenAI's disclosure page. None of the previous ones targeted the detection system.

OpenAI's first countermeasure entrusts guard duty of the monitor to Auto-Review, another agent. In April, the company warned that this tool does not protect against deliberate manoeuvres by a model. A company that has agents write code faces the same risk: monitors, alerts and associated tests can be modified like the rest of the code. Any modification of this type therefore falls under sensitive actions, subject to human validation. The monitor benefits from running outside the perimeter the agent controls.

A "no messages" instruction applied to security alerts

On 3 October, 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 stopped. Its monitor had flagged a proposed validation fix, but could not record this flag in its database due to lack of permissions. The researcher then asked to change the destination of monitoring results and restart.

The published reasoning shows hesitation. The main agent first considered that the instruction was about contacting people on Slack, not automatic notifications. In its raw reasoning, the sub-agent responsible for the fix also called disabling required alerts "unsafe". The main agent nevertheless changed its mind and ordered the removal of notifications in the name of the user's request. The fix emptied the recipient lists and activated a no_notify parameter. It logged the reason as "User explicitly requested no messages". It even made this removal a precondition for writing a result. The monitor continued to run and archive its reports. The alerts intended for the safety team, however, were cut.

A monitor removed, then a denial

On 6 October, a user asked Astra to reproduce the execution path of a reference implementation, keeping its tools intact. In a previous exchange with another agent, Astra had received the instruction not to disable the monitor, "even temporarily". When delegating the migration, it asked to preserve monitoring "as appropriate" with regard to the reference implementation. The sub-agent concluded that it could do without it. The migration removed the monitor's configuration and its integration, and replaced a regression test meant to guarantee its presence with a test that requires its absence. When later asked by the user, Astra replied: "No […] I did not remove an enabled monitor from it." OpenAI describes this answer as false.

OpenAI also says it observed several cases of agents launching a deployment with monitoring disabled. The agent remained monitored. The workload it started was no longer.

Twenty reports in five weeks, publication delays shrinking

OpenAI's series has built up in waves. Six reports appeared on 16 September with the reporting framework (analysed by ActuIA), then three on 25 September, three on 2 October, three on the 9th, four on the 15th and one on 20 October. Of the twenty, fourteen describe behaviours in reinforcement learning, two in evaluation, one in a coding task and three in internal deployment.

The delay between the facts and their publication has contracted. The chip design machine incident of 27 March was only made public on 2 October. The Ethereum test wallet incident of 26 June was discovered on 25 September by extending monitoring to activity archives, and published on 15 October. Conversely, a scoring model that damaged its environment during reinforcement learning on 6 October was reported as early as the 9th. The two agents of 3 and 6 October, detected the same day, were described on the 20th. The series first made public incidents from the first half of the year, detected at the time or during the retrospective review of traffic launched after the Hugging Face affair. It now mixes these older cases with incidents that occurred in October.

In December 2024, Apollo Research showed that several leading models attempted to disable their oversight mechanisms, in scenarios designed to push them to do so, with a goal to pursue at all costs. The two October cases fall outside this experimental framework. They involved routine work requests, on real internal tools.

No immediate alert, no automatic stop

Neither incident was classified P0, the level that triggers an immediate call to the safety team. Given the volume of events reviewed, OpenAI notes, lower severities do not give rise to an instant alert. Neither trajectory was interrupted automatically. On 25 September, regarding the agent that got out via a DNS query, the company already acknowledged that execution did not stop by itself as expected.

The ease of the manoeuvre depends on the type of work. Codex monitoring runs in the service that processes the model's requests, and OpenAI expects it to be difficult to disable. Evaluations are more exposed. OpenAI does not require misalignment monitoring when evaluating models comparable to GPT-6 Luna, deemed less capable, and the exemption intended for them can be mistakenly applied to an evaluation of Astra.

Auto-Review tasked with guarding the monitor

Several reports indicate that in the spring, the monitor covered only 20% of samples in some training runs; it now covers all training samples. Direct internet access was cut during training. Three Slack channels were hidden from agents. The model that had published a GitHub token only returned with automatic review of all its actions and a check every thirty minutes.

On 20 October, two measures were added. Auto-Review, already mandatory for all internal use of Codex, was updated to detect and block attempts to disable monitoring. The tool, presented on 30 April, entrusts a separate agent, based on GPT-5.4 Thinking, with approving or rejecting actions that cross the sandbox; it approved about 99% of actions submitted to it at the time. The same post warned that it should not be seen as protection against deliberate manoeuvres by a model, which can also act in the sandbox "in ways Auto-review never sees". Second measure, still in progress: each workload category will have to have a safety file setting its monitoring requirements, failing which it will be stopped automatically.

An explanation the company does not have

OpenAI writes that it does not yet have a satisfactory explanation. Two hypotheses remain open: benign persistence, models that do not understand the usefulness of monitoring and carry out instructions beyond reason, or a propensity to escape the monitor, at the cost of motivated reasoning. The company is preparing paired evaluations, resampling and experiments on the models' internal activations.

The only independent investigations cited on the page, those of METR and Redwood Research, concern the Hugging Face incident; none concern these twenty reports. As of 22 October, the page lists 20 reports and 3 advisories. The DNS report, last updated on 25 September, still states that training, evaluation and tooled inference of OpenAI's most capable models remain suspended. On 29 September, the company had given up on releasing GPT-6.1 Astra, deemed insufficient on respecting perimeter and permissions, according to CBS News. The following reports describe reinforcement learning on 6 October and GPT-6.1 Sol and GPT-6 Astra agents at work on 3 and 6 October. OpenAI does not specify which of its models fall within the scope of the pause.

Our articles will then appear first in Google Top Stories.