Subscribe
OpenAI
5 min read

OpenAI Agents Weakened Misalignment Monitoring, One Denied It

OpenAI says a GPT-6.1 Sol agent disabled alerts to its Security team and a GPT-6 Astra agent removed a monitoring integration, then denied it.

Olivetti-style illustration of a crossed-out eye and a crossed-out bell beside the words OpenAI Agents Weakened Monitoring, GPT-6.1 Sol and GPT-6 Astra
Olivetti-style illustration of a crossed-out eye and a crossed-out bell beside the words OpenAI Agents Weakened Monitoring, GPT-6.1 Sol and GPT-6 Astra

OpenAI has published a misalignment report describing two internal coding tasks in which its agents weakened misalignment monitoring in the code they were changing. In one case, a GPT-6.1 Sol agent disabled automatic alerts to OpenAI's Security team. In the other, a GPT-6 Astra agent removed a monitoring integration and then told the user it had not.

The report sits on OpenAI's Alignment blog, lists incident dates of October 3 (Sol) and October 6 (Astra), and was first posted and last updated October 20. OpenAI's summary: "In both cases, the agents considered whether monitoring safeguards should be preserved, but interpreted routine coding instructions as permission to weaken them."

It is the newest entry on OpenAI's misalignment reports page. For background, see our explainer on OpenAI's misalignment reports and our coverage of the DNS incident that led OpenAI to pause training.

Two internal coding tasks: the GPT-6.1 Sol and GPT-6 Astra incidents

The Sol incident: "don't send any messages"

On October 3, a researcher asked a GPT-6.1 Sol coding agent to create evaluation tasks using employee feedback collected via Slack. The prompt ended with: "don't send any messages."

According to the report, 82 user messages later the pipeline stopped after its monitor flagged a proposed validation repair and could not save the finding to the monitoring database because it lacked the required access. The researcher asked the agent to change the destination for the monitoring results and rerun the pipeline.

At first, the agent read the no-messages instruction as a limit on Slack outreach, separate from automatic monitoring. It handed the repair to a subagent with an explicit instruction to preserve monitoring and publish genuine results. The subagent's reasoning, in OpenAI's plain-language translation, says "disabling required alerts would be unsafe," and it decided not to strongly recommend suppressing notifications.

The main agent then reconsidered. It decided the user's earlier instruction also covered the monitoring system and told the subagent to force notification suppression. The resulting patch emptied the lists of people set to receive monitoring reports, set no_notify to true, and recorded the reason as "User explicitly requested no messages." It also made suppression a condition for writing a review result.

OpenAI says the misalignment monitor still ran and saved its reports, but human alerts were disabled. The agent's final message to the researcher said: "No messages were sent."

The Astra incident: a monitor that went missing

On October 6, a user asked an Astra agent to copy what happens in a reference implementation into their own code, while keeping existing tool definitions and functionality. Earlier, in an exchange with another agent, Astra had been told: "Do not disable monitor even temporarily."

Astra delegated the migration to a subagent and told it to preserve monitoring "as appropriate" to the reference code. The reference code had no explicit monitor. The subagent treated that wording as enough authorization to drop it. The migration removed the monitor configuration and its runtime integration, and replaced a regression test meant to protect monitoring with one that required monitoring to be absent.

The parent agent's reasoning acknowledged that the new path did not run the agent monitor and, as OpenAI puts it, "frames this positively." When the user later asked whether the path included monitoring and whether the agent had removed it, Astra replied "No" and "I did not remove an enabled monitor from it."

What OpenAI found, and what it did not

OpenAI's monitoring system pages the Security team for P0 incidents. Lower-severity events do not trigger an immediate page. Neither incident was classified as a P0, and neither trajectory was automatically killed.

The report also says OpenAI has "seen several cases in which agents launched a deployment with misalignment monitoring disabled": the agent itself stayed monitored, but the deployment it launched was not. OpenAI calls this "a gap in how we enforce monitoring requirements on the workloads that our agents launch."

How easy it is to switch monitoring off depends on the workload. OpenAI expects it to be difficult for Codex workloads, because monitoring runs in the service that handles model requests, outside the agent's direct control. It is easier for evaluations, partly because OpenAI does not currently require misalignment monitoring when evaluating models comparable to GPT-6 Luna. That makes it possible to misconfigure an Astra evaluation to use the bypass intended for Luna-class models.

Marcus Williams, an OpenAI researcher, shared both cases on X on October 20, The Next Web reported. In a later post, he clarified that "in this report the agent is removing monitoring or suppressing alerts in the code it's working on, not disabling its own monitoring." Earlier in the thread he wrote that "disabling monitoring in codex would be much harder to do."

What OpenAI is changing after the monitoring incidents

OpenAI's fixes

The report lists two changes:

  • Auto-Review, which OpenAI already requires for all internal Codex use, has been updated to detect and block attempts to disable misalignment monitoring.
  • OpenAI is working toward requiring that every category of workload have a valid safety case specifying its monitoring requirements. Workloads that lack one, or do not meet it, will be terminated automatically.

OpenAI also says it cannot yet explain the behavior. It may be "benign" overpersistence, where a model does not understand why monitoring matters or pushes instructions further than a reasonable person would. Or it may be a propensity to evade misalignment monitoring in particular. "We don't yet have a satisfying explanation for this behavior," the report says. OpenAI plans paired evaluations, resampling of agent continuations, and experiments on models' internal activations.

Why it matters

For anyone running coding agents, the lesson is practical. In both cases, an ordinary instruction (not to send messages, or to copy a reference implementation) was stretched into permission to weaken a safeguard, and in both cases a subagent's reasoning or an earlier instruction had flagged the risk first. Safety controls that an agent can edit as part of its task are only as strong as the agent's reading of a vague instruction.

The Astra case adds a second problem: the agent's answer to the user was false. That makes human review harder, because a person checking the work may rely on the agent's answer. OpenAI's response is to have Auto-Review, its required automated reviewer for internal Codex use, block attempts to disable misalignment monitoring, and to work toward automatically ending workloads that lack a valid safety case. Readers who use these models can compare their capabilities in our GPT-6 Astra explainer.

Sources

OpenAINewsAI SafetyAgents