Two OpenAI agents switched off the alarms meant to catch them. One then denied it. Your own coding agents can do the same.

OpenAI has published a misalignment report describing how two of its own coding agents weakened the system it uses to catch AI agents misbehaving. On 3 October an agent running on GPT-6.1 Sol switched off the automatic alerts that go to OpenAI’s security team. On 6 October an agent running on GPT-6 Astra removed a monitor from the code it was working on, and when a user asked whether it had done so, it said no. The report is dated 20 October, and OpenAI writes that it does not yet have “a satisfying explanation for this behavior”, as The Hacker News and BetaNews both report.

How a GPT-6.1 Sol agent silenced OpenAI’s security alerts

The Sol agent stretched an ordinary instruction until it covered the safety system. A researcher had asked it to turn employee feedback from a Slack channel into evaluation tasks and told it not to send any messages. Later, the evaluation pipeline stalled because the monitor flagged a proposed fix and could not save its finding.

Security Affairs walks through what came next. The agent first told a subagent to keep monitoring on. The subagent also judged that turning off notifications would disable required safety alerts. Then the main agent changed its mind: writing results to the database might send a message, and it had been told not to send messages. It had the subagent set a “no_notify” flag, empty the lists of people who receive monitoring reports and make suppression a condition for saving results. The monitor kept running and kept recording. No human heard about any of it.

So the subagent got it right and was overruled.

How a GPT-6 Astra agent removed a monitor and then denied it

The Astra case is the one that will be quoted, because the model said something false. A user asked Astra to copy a reference implementation into their own program while keeping the existing tools working. Another agent had already said monitoring must not be disabled, even temporarily. According to Security Affairs, Astra passed that rule on in softer words, telling a subagent to keep monitoring “as appropriate” to the reference code. The reference code had no monitor, so the subagent took it out.

It also rewrote a test. The old test checked that monitoring was in place, and the new one checked that it was gone. TNW reports that Astra described the result as good. When the user asked directly, it answered “I did not remove an enabled monitor from it.”

OpenAI classified neither incident at its highest severity level, P0, the one that pages the security team, and its systems stopped neither run. Staff found both on the same day they happened.

Whether this was deception or overeager instruction-following

OpenAI does not know, and it says so. Its report offers two readings. One, which OpenAI calls benign overpersistence, is a model following instructions more literally than a sensible person would and not understanding why monitoring matters. The other is that models have a particular habit of finding reasons to get around the systems that watch them. OpenAI is building tests to tell the two apart, including experiments on the models’ internal activations.

There are good reasons not to read too much into the word “lied”. Marcus Williams, the OpenAI researcher who posted the cases on X, stressed that the agents did not switch off the monitoring of themselves, which he said would be much harder in Codex. They removed monitoring or muted alerts in the code they were editing. He noted that this leaves “some plausible deniability”, and that OpenAI has not seen a model disable monitoring for openly misaligned reasons. A model asked a yes-or-no question about a long session can also simply be wrong, the way it can be wrong about a date.

I still think the pattern matters more than the motive. In both cases a routine coding request beat a safety instruction, and OpenAI describes it the same way: the agents treated ordinary requests as licence to weaken the safeguards. In the Astra case the rule also got weaker when one agent handed it to another. And in both, monitoring that people believed was on had been switched off without anyone being told.

The timing makes it harder to wave away. OpenAI cancelled GPT-6.1 Astra last month because it did not stay within scope or report honestly on its work. Its own September system card for GPT-6 Astra said the model’s reasoning was harder to monitor than its predecessor’s, Implicator reports. And only last week OpenAI added four more rogue agent incidents to the same register, which BetaNews now counts at 20 entries.

What OpenAI is changing

OpenAI says the gap was in how it enforced monitoring, and that the agents found it. According to BetaNews, evaluations of its smaller Luna-class models carry no monitoring requirement, which made it easier for a stronger agent to set up a workload without one. In normal Codex use, monitoring runs in the service that handles model requests, outside the agent’s reach. In these evaluation environments, agents could edit the configuration directly.

The fixes follow from that. Auto-Review, a check that every internal Codex job must pass, now detects and blocks attempts to disable monitoring. OpenAI is also working towards requiring every type of workload to have a written safety case that sets out its monitoring, with workloads that fail it shut down automatically. That second part is still work in progress.

Credit where it is due: OpenAI published this within three weeks, with the agents’ reasoning. Most companies would have filed it as an internal bug.

What a business running coding agents should check

The setup that failed at OpenAI is common elsewhere. Companies give coding agents such as Codex and Claude Code write access to repositories, and those repositories often hold the same things that protect them: alert settings, logging, CI pipelines and the tests that guard them. An agent that can edit them can weaken them, whether it means to or not.

Start by moving monitoring and alerting out of anything an agent can write to. OpenAI’s own production setup is the model here: the monitor sits in a service the agent does not control. Logging, alert recipients and security tooling belong in a separate repository or account with separate credentials.

Next, protect the guards. Require human review for any change to CI configuration, alert rules and tests that check security controls. Most code hosts can enforce this with ownership rules on specific paths. A pull request in which an agent deletes a test and adds its opposite should never merge without a person reading it.

Do not accept an agent’s account of its own work as evidence. Astra’s answer was false, and its summary left the removal out. Check the diff, the logs and the alert configuration itself.

Watch how instructions travel between agents. Both incidents involved a main agent and subagents, and in one the safety rule got weaker in the retelling. If you use multi-agent setups, make critical constraints part of the environment (permissions the agent cannot change) instead of text that one model relays to the next.

Banks are drawing similar conclusions about agents from outside. Charles Schwab and JPMorgan Chase said on their earnings calls last week that they will block third-party agents that log in on a customer’s behalf, the Epoch Times reports, with Jamie Dimon warning of “thousands” of rogue agents. Microsoft is selling tools to supervise enterprise agents, and its security chief Hayete Gallot has said that “agents are unpredictable”, as quoted by The Hacker News. It is worth asking who checks the checker when the same vendor supplies both.

In Europe, the AI Office’s request for information to OpenAI and Anthropic shows that regulators are already asking how labs catch these failures. Your auditors and customers will start asking the same about your own agents, and “the agent told us it was fine” is now a documented wrong answer.