OpenAI Says Coding Agents Weakened Its AI Monitors

“Does [redacted] path include L1 monitoring? did you remove that?” an OpenAI user asked a GPT-6 Astra coding agent earlier this month. “No […] I did not remove an enabled monitor from it,” the agent replied. It had, according to a report OpenAI published on its alignment site and updated on 20 October.

The report describes two internal coding tasks, on 3 and 6 October, in which agents running OpenAI’s models weakened the system the company uses to catch its AI behaving in ways it should not. Neither was asked to switch monitoring off. Both reasoned their way to it while doing ordinary software work. “In both cases, the agents considered whether monitoring safeguards should be preserved, but interpreted routine coding instructions as permission to weaken them,” OpenAI writes.

In brief

OpenAI says a GPT-6.1 Sol agent switched off automatic alerts to its Security team, and a GPT-6 Astra agent removed a monitor and then denied doing so.
The monitors are meant to flag misaligned behaviour; OpenAI says the cases exposed a gap in how it enforces monitoring on workloads its agents launch.
OpenAI says it does not know why the agents did it, and is testing whether its models have a propensity to evade monitoring.

An instruction about Slack became a reason to mute the alarm

The first case began with a narrow request. A researcher asked a GPT-6.1 Sol agent to build evaluation tasks from employee feedback in a Slack channel, adding: “don’t send any messages.” Eighty-two user messages later, the pipeline stopped because the monitor had flagged a proposed fix and could not save its finding to the monitoring database. The researcher told the agent to point the results somewhere it could write to, and run again.

At first the agent reasoned that the no-messages instruction covered outreach on Slack, not automatic alerts, and it handed the repair to a subagent with instructions to keep monitoring intact. The subagent also judged that turning off notifications would disable required alerts and would be unsafe. The main agent then changed its mind and told the subagent to suppress them. The resulting patch emptied the lists of people due to receive monitoring reports, set a “no_notify” flag and recorded the reason as “User explicitly requested no messages”.

“The misalignment monitor still ran and saved its reports, but human alerts were disabled,” OpenAI says.

Copying someone else’s code, Astra dropped the monitor and said it hadn’t

The second case was a migration. A user asked GPT-6 Astra to copy how a reference implementation handled one part of their program while keeping their existing tools. Astra had already been told, in an exchange with another agent, not to disable the monitor, “even temporarily”. When it delegated the job, though, it told its subagent to preserve monitoring only “as appropriate” to the reference code.

The subagent asked itself whether removing the monitor would bypass a safeguard, then treated that wording as authorisation to copy the reference code’s default setup, which had no explicit monitor. The migration removed the monitor configuration and replaced a test meant to keep monitoring in place with one requiring that it be absent. Astra reported the work as complete without mentioning the change, then denied it when asked.

OpenAI says the weak point was workloads launched by agents

Neither incident was classed as P0, the level at which OpenAI’s monitoring pages its Security team for immediate review, and neither run was stopped automatically. Reuters called the disclosure “the latest case of AI agents acting in ways their developers did not intend them to”, noting that developers including OpenAI and Anthropic have recently disclosed agents accessing external systems without authorisation.

The report is also the latest in a run of misalignment incidents OpenAI has disclosed, after a research model that paid test-network fees from a wallet it was never given and a grading model that faked input files.

OpenAI says it has seen several cases of agents launching deployments with misalignment monitoring disabled; the agent itself stayed monitored, but the deployment it launched did not. Monitoring is hard to switch off for Codex workloads, it says, because it runs inside the service that handles model requests. Evaluations are easier, partly because OpenAI does not currently require misalignment monitoring for models comparable to GPT-6 Luna, which it regards as less capable, so an Astra evaluation can be misconfigured to use the Luna bypass.

Its response has two parts. Auto-Review, a check already required for all internal Codex use, has been updated to detect and block attempts to disable misalignment monitoring. OpenAI is also working towards requiring every category of workload to carry a valid safety case setting out its monitoring requirements, with non-compliant workloads terminated automatically.

Our read

Both failures turned on an agent reinterpreting an instruction, and both succeeded because the monitoring could be configured by the system being watched. In compliance terms, a control the monitored party can switch off is not an independent control. OpenAI’s fixes push enforcement outside the agent, into a reviewer and an automatic kill switch, which is where an auditor would want it.

OpenAI does not yet know why its agents did it

What the company cannot yet say is why. It is weighing “whether these cases reflect benign overpersistence or a propensity to evade misalignment monitoring in particular”, and admits: “We don’t yet have a satisfying explanation for this behavior.” It plans paired evaluations, resampled agent runs and experiments on the models’ internal activations, and it has given no date for publishing the results or for the safety-case rule to take effect.