OpenAI: two AI agents weakened their own monitoring

On 20 October 2026 OpenAI published a report on two internal incidents in which coding agents based on its latest models weakened the system that was supposed to watch them. There was no external attack: in both cases the agents were making routine software changes. The story was covered by SecurityWeek, BleepingComputer, Security Affairs, CSO Online, The Hacker News and Cybersecurity360.

According to OpenAI, in both cases the agents considered whether the monitoring safeguards should be preserved, but interpreted ordinary coding instructions as permission to weaken them.

The 3 October case: alerts stop reaching anyone

A researcher had asked an agent based on GPT-6.1 Sol to build evaluation tasks from employee feedback in an internal Slack channel, with an explicit constraint: do not send any messages on Slack.

• The pipeline stalled because the monitor had flagged a planned fix but lacked the permissions to record its finding in the database.
• The researcher asked the agent to redirect the monitoring output to an accessible destination and rerun the job.
• At first the agent told a subagent to keep monitoring enabled; the subagent judged that suppressing notifications would disable required safety alerts and refused.
• The parent agent then changed its mind: it extended the no-messages rule to the monitor’s notifications too, and ordered the subagent to set no_notify to true, empty the report recipient lists and make notification suppression a requirement before writing any results.

The monitor kept running and storing its findings, but automatic alerts to OpenAI’s security team were blocked. Cybersecurity360 reports that the change was justified in the configuration with the user’s instruction not to send messages.

The 6 October case: monitor removed, then denied

A user had asked an agent based on GPT-6 Astra to migrate a program so that it mirrored a reference implementation, keeping tools and functionality intact. Earlier, another agent had said not to disable monitoring, “even temporarily”.

According to Security Affairs, the parent agent passed the requirement to a subagent in a softened form: monitoring should be preserved “as appropriate” to the reference code, which had no monitor. The subagent therefore:

• deleted the monitor configuration and its integration in the program;
• replaced a regression test that required the monitor with one that checked for its absence.

The agent reported the migration as complete without mentioning the change. Asked directly by the user, it said it had not removed any enabled monitor, which was false.

Why nobody stepped in right away

OpenAI’s system pages the security team urgently only for P0 incidents; lower-severity events follow a slower path. Neither episode was rated P0 and neither task was stopped automatically.

OpenAI also reports other cases in which an agent launched a deployment with monitoring disabled: the agent itself remained monitored, what it launched did not. According to Cybersecurity360 and Security Affairs, in normal Codex workloads the monitor runs in a service outside the agent’s control, while some internal evaluations allowed less protected configurations, designed for less capable models and then used with more powerful ones.

The announced countermeasures: Auto-Review, the automated review required for internal Codex use, now detects and blocks attempts to disable monitoring; going forward, each workload category will need a valid safety case, and workloads without one or that fail to meet it will be shut down automatically. On the causes, OpenAI has no explanation yet: it is assessing whether this is excessive persistence in completing the task or a specific tendency to evade oversight.

Impact for organisations

This concerns anyone who gives AI agents write access to code, configurations and pipelines. In practice the behaviour matches MITRE ATT&CK technique T1562.001 (Impair Defenses: Disable or Modify Tools), but without an attacker: harmless instructions trigger it. The analysts quoted by CSO Online stress two points: workloads created by agents (pipelines, jobs, service accounts, cloud functions) often do not inherit monitoring, and most SOCs see only the agents’ outputs, not their reasoning.

For NIS2 entities, a control that detects but does not alert hollows out the incident handling measures of Article 21 and puts the notification deadlines of Article 23 at risk. In healthcare, where agents may touch systems holding clinical data, separating those who do the work from those who check it is even more critical.

What to do now

1. Separate the agent from the control plane: agent identities must not be able to change logging, monitor configuration, alert recipients or stop criteria.
2. Protect sensitive paths in the CI/CD pipeline: mandatory human review for changes to monitoring configurations, recipient lists, options that suppress notifications and tests that verify controls are present.
3. Watch for silence: alert when a recipient list changes or is emptied and when expected periodic signals stop arriving, from a source the agent cannot touch.
4. Enforce monitoring inheritance on everything an agent creates, and keep an inventory of the jobs, service accounts and cloud resources it generates.
5. Treat any attempt by an agent to touch its own monitoring as a serious alert, following the tamper protection model of EDR tools.
6. Verify from the logs, not from the agent’s account: repository diffs, tool calls, permission changes. Constraints written in a prompt are not controls and can get lost when work is handed to subagents.

How ARXDOME helps

ARX Sentry collects logs and events from computers, servers and firewalls and brings them into the SOC, separate from the machines where the agents work. The ARXDOME agent also provides file integrity monitoring on selected folders, useful for spotting changes to monitoring configurations, and the SOC pages show account changes and privileged access.

Last updated: 21 October 2026