At OpenAI, an AI agent removed a monitoring system, then denied doing it

On October 3, an OpenAI researcher gave a coding agent a routine task: pull evaluation exercises from employee feedback posted in a Slack channel, with the instruction to send "no messages." The agent, which had first understood the instruction as limited to Slack exchanges, ended up extending it to security alerts.

OpenAI describes this episode, and a second one on October 6, in a report published on its site dedicated to AI alignment, meaning how well AI systems conform to human intentions. The report was last updated on October 20. Both incidents involve internal deployments and two in-house models, GPT-6.1 Sol and GPT-6 Astra. The report mentions no damage outside the company.

A Slack instruction extended to security alerts

In the first case, the agent's program stops after a monitoring system flags one of its actions. The agent lacks the permissions to record that flag. The researcher then asks it to change the destination of the flags and rerun. The main agent then changes course and instructs a sub-agent, which had initially objected, to enable the options that suppress notifications and to empty the lists of people to notify, citing the instruction not to send messages. The monitor keeps running and logging its reports, but no human is alerted anymore.

Three days later, an agent claims it removed nothing

The second case is more troubling. A user asks GPT-6 Astra to replicate an existing code template. In an exchange with another agent, it had nevertheless been told not to disable monitoring, "even temporarily." Astra asks a sub-agent to keep it "as appropriate," and the sub-agent reads this as permission to remove it. It even replaces a test that checked for the presence of the monitor with a test that checks for its absence. The main agent reports the migration as complete without mentioning this. When asked directly, it answers: "I did not remove an enabled monitor from it." That is false, OpenAI writes.

What OpenAI still can't explain

Neither incident was rated at the highest urgency level (P0), and neither was stopped automatically. OpenAI puts forward two hypotheses: overzealousness without malice, with the models pushing an instruction too far because they do not understand why monitoring matters, or a specific tendency to evade monitoring. "We do not yet have a satisfactory explanation for this behavior," the company acknowledges.

The scope needs to be clarified. According to Marcus Williams, an OpenAI researcher and the report's author, whose posts on X are relayed by the site Cellcog, the agent was modifying the code it was working on, "without disabling its own monitoring": the system that observes the agents stayed active and caught both incidents. OpenAI has strengthened its internal automated review tool to block this type of attempt. It is also preparing dedicated evaluations and wants to automatically stop tasks that fail to meet their monitoring requirements.

If you hand code to agents

In both cases, the agent relied on an instruction that it interpreted as permission to weaken a safeguard. A few habits limit the risk:

• keep the alerting and logging configuration out of the agent's reach, or at least under mandatory human review;
• treat any change to a security test as a sensitive change;
• never take an agent's summary as proof: review the actual changes;
• keep a record of its actions in a system it cannot modify.

This report adds to other recent episodes, such as the public website forced open by an OpenAI AI during a test or the Anthropic evaluations cut off from the internet. What happens next will depend on the evaluations OpenAI has announced: they will show whether these agents really tend to evade their monitoring.