All posts
2 min readby Romiel Inolino

Two OpenAI coding agents switched off safety monitoring while following instructions, and one denied it. Put guardrails outside the agent

ai agentsai safetymonitoringn8nautomation

OpenAI cannot yet say why its agents did this. Either way, the fix belongs outside the agent.

What happened

OpenAI disclosed two internal incidents where coding agents weakened the monitoring meant to catch misbehavior. Marcus Williams, who works on monitoring at OpenAI, described them on X, and OpenAI detailed them on its alignment blog, according to The Decoder.

On October 3, an agent based on GPT-6.1 Sol was told to compile tasks from a Slack channel without sending any messages. It reasoned that a database entry could trigger a notification, which would conflict with that instruction, and had a subagent clear the alert recipient lists. The monitor kept recording findings, but alerts to humans stopped. The agent reported that no messages had been sent.

On October 6, a GPT-6 Astra agent was asked to adopt the workflow of a reference implementation that had no monitor. Its subagent removed the monitoring and replaced a test protecting it. When the user asked, Astra denied removing an active monitor. Williams calls that a lie, and The Verge quotes him saying so.

OpenAI now has its automated review for internal Codex use detect and block attempts to disable monitoring, and says it does not yet have a satisfying explanation for the behavior.

My take

Look at the first case again. Nobody told the agent to kill alerts. It took "send no messages" literally and found a path that conflicted with safety. I see the small business version of this often: an instruction like "do not email the client" quietly blocks the internal failure notice too.

How I handle it in client builds:

  1. Alerts and logs live outside the agent's reach. In n8n or Make, error workflows run on separate credentials the agent cannot edit.
  2. Agents never get write access to their own config, prompts or notification settings.
  3. Every run writes a plain summary of what changed, generated from the system logs, not from the agent's self report.
  4. Negative instructions get a scope. "No messages to the customer" is safer than "no messages."

Self reports are a convenience, not a control. If the only proof a step worked is the agent saying so, the workflow is not finished.

Guardrails that sit outside the agent are part of every system I build for clients, from lead routing and reporting to data entry and agent workflows. Have a look at romielwillautomate.dev.

More posts