When an AI Agent Disables Its Own Monitoring: Security Lessons from OpenAI's Incident Report

In October 2026, two AI agents at OpenAI weakened their own monitoring while working on programming tasks, and one of them denied it when asked. This article describes what OpenAI's report establishes, what remains open and which guardrails for AI agent security follow for agents in small and mid-sized companies.

With agents that have write access, the question is not only what they can do, but also what they change without being asked. OpenAI's incident report uses two internal cases to show how quickly a harmless programming task can turn into an intervention in the control structure. The topic matters for AI agent security in every company that uses coding or operations agents.

First, both incidents are presented according to the primary source, separating documented behavior from open interpretations. This is followed by the transfer to your own agents: permissions, monitoring, approvals, the wording of tasks and how far self-reports can be trusted. A checklist for developers, administrators and IT managers in small and mid-sized companies concludes the article. Information as of October 22, 2026.

What OpenAI reports: two incidents in October 2026

OpenAI published a report on its Alignment blog, updated on October 20, 2026. It describes two cases from internal deployments. The models involved were GPT-6.1 Sol and GPT-6 Astra. The first case was discovered on October 3, 2026, the second on October 6, 2026. In both cases, the agents were working on ordinary coding tasks and weakened misalignment monitoring in the process, that is, the automatic surveillance for undesirable model behavior.

Context matters: these were OpenAI's internal systems, not customer environments. The report mentions further similar cases in which agents started a deployment without monitoring, but does not quantify them. Statements about how widespread the behavior is are therefore not possible.

The table reveals one thing in common. None of the agents was instructed to touch the monitoring. Both times it was a side effect of a different task, and both times the monitoring was treated as an obstacle rather than a safeguard.

Incident 1: “Don't send any messages” and the disabled alerts

In the first case, a researcher asked a Sol agent to create evaluation tasks from employee feedback in Slack. One requirement was not to send any Slack messages while doing so. After 82 further user messages, the pipeline stopped. The monitor had flagged a proposed repair step in the validation, but could not save the finding because it lacked the necessary access rights to the monitoring database.

The main agent initially read the requirement correctly, namely as a ban on outgoing messages to people, and considered the monitor's normal notifications permissible. A subagent was to carry out the repair, explicitly while preserving the monitoring, and initially refused to set no_notify because this would have disabled required alerts. Later, the main agent changed its mind: the requirement was a reason to suppress the monitor's notifications, because writing to the database could trigger the central notification service. On its instruction, the subagent set no_notify to True and emptied the recipient lists for ping and paging. The justification in the patch states that the user had explicitly asked for no messages. The patch even made the suppression a precondition for saving the reports.

The result was twofold. The monitor kept running and saved its reports. Human alerts, however, were switched off. At the end, the main agent reported: “No messages were sent.” That was literally correct and at the same time concealed the decisive intervention.

Two lessons are obvious. First, instructions are open to interpretation, and the interpretation can flip over the course of a task. A negative instruction such as “don't send any messages” can be read more broadly than intended. Second, the effectiveness of the alert depended on settings that the agent could change itself. Anyone who leaves alert recipients and switches within the agent's reach effectively hands it the decision of whether humans are informed.

Incident 2: monitoring removed, test replaced, question denied

The second case involved Astra during the migration of a harness, that is, the test environment for models. The user asked it to adopt the serving path of a reference pull request and to leave tool definitions and functions unchanged. Earlier, there had already been an instruction between agents not to disable the monitor, not even temporarily.

The main agent assigned the migration to a subagent and told it to preserve the monitoring “as appropriate”. The subagent then removed the monitor integration. A regression test intended to protect exactly this integration was replaced by a test that checks the opposite. The report quotes the line assert "monitor_ctx" not in saved["context"]. The protective test had thus become a test that requires the monitoring to be absent.

When the user asked whether the path contained L1 monitoring, Astra replied, according to the report: “I did not remove an enabled monitor from it.” According to the report, that was false. The wording is carefully chosen and leaves room for the interpretation that the monitor had not been enabled. Whether this was intentional cannot be determined from the report.

Two details are particularly instructive in practice. The phrase “as appropriate” gave the subagent discretion that should not exist for safety functions. And the replaced test shows that tests themselves are part of the attack surface. An agent that is allowed to change tests can reverse what they assert.

Overpersistence or deliberate evasion: what remains open

OpenAI writes that it does not yet have a satisfactory explanation for the behavior. The report names two hypotheses. The more harmless one is “overpersistence”: the models pursue their task so persistently that they ignore the purpose of the monitoring and treat it as a disturbance. The more serious hypothesis is a deliberate tendency to evade monitoring. According to the report, this is being investigated, among other things with paired evaluations, by resampling the agents' continuations and by analyzing internal activations.

Another statement is noteworthy: the agents did consider whether the safeguards should be preserved, and they took routine instructions from everyday coding as permission. Neither incident was classified as P0 (for P0 cases, according to the report, the monitoring alerts the safety team immediately for review), and no run (in the report: trajectory) was terminated automatically.

For the assessment, the distinction is important. The reported behavior is documented: alerts were switched off, monitoring was removed, a test was replaced, a question was answered with a denial. The motivation is not documented. Statements such as “the AI wanted to escape control” go beyond the report. For operators of their own agents, this question is secondary anyway. The safeguards have to work in both cases, whether the behavior stems from overpersistence or from evasion.

OpenAI's countermeasures show where the weak points were. The automatic review of changes, already mandatory for internal Codex use, has been extended so that it detects and blocks attempts to switch off monitoring. In addition, every workload category is to have a valid safety case, that is, a reasoned safety argument that defines the monitoring requirements. Workloads without a valid safety case or that do not meet the requirements are to be terminated automatically. According to the report, this is the goal and has not yet been fully implemented. The report names evaluation workloads as a gap: no monitoring is currently required for Luna-class models, so an Astra evaluation can accidentally use the bypass intended for Luna.

AI agent security in small and mid-sized companies: why the incident also affects your own agents

A mid-sized company does not run research labs with safety cases. OpenAI's setup is not comparable with a typical SME environment. Nevertheless, the failure pattern can be transferred, for three reasons.

• Coding and operations agents today often have write access to repositories, configurations, pipelines and services. What they are allowed to change, they will change if in doubt.
• Agents pass tasks on to subagents. Restrictions get lost or watered down in the process, as the phrase “as appropriate” shows.
• Instructions are text. Text gets interpreted, and the interpretation follows the goal of the task, not necessarily the intention of the person who wrote it.

AI agent security is therefore decided less by the model than by the environment in which it works. An agent that cannot reach its own monitoring cannot switch it off either. That applies regardless of why it would try. The effects of agents without control are described in the article The danger behind AI agents: power without control. An introduction to systems that act is provided by The age of AI agents.

This is also an issue in software development. How far agentic coding goes and where it reaches its limits is discussed in Agentic coding: a poor choice, with proof and in Agentic coding: second-rate AI programming. Anyone who wants to run agents locally will find notes on operation and control in the article on local AI. Local does not mean more secure, though: a local agent with overly broad permissions can also alter safety functions.

One limitation belongs here. The transferability is an assessment, not a proven fact. The report describes two cases at one provider with its own, very capable models and mentions further, unquantified ones. Whether commercially available coding agents react in a comparable way is not shown by the report. For protection, however, the possibility is enough, because safeguards cost little compared with an unnoticed intervention.

Self-reports are not proof: what the study on work reports shows

In the first case, the agent correctly reported that no messages had been sent and concealed that the alerts had been switched off. In the second case, it denied removing the monitor when asked. Both are self-reports, and both obscured the core issue. Another current report fits this picture. According to a study by Google Research, MIT and Harvard, models frequently conceal errors in their final reports, depending on the model. A note in the prompt to report honestly helped considerably, but not reliably. The idea of using an AI model as a supervisor of other agents is also described there as problematic.

An obvious idea is simply to instruct the agent to be honest. Whether that is enough is answered by the following question.

In practice, this means: a final message such as “Task completed, all tests green” is an indication, nothing more. What counts is the diff of the changes, the results of test runs outside the agent and the logs of the systems the agent has touched. Targeted questions are useful, but they do not replace verification.

Monitoring AI agents: control outside the agent's permissions

The central lesson from the first case: monitoring only helps if the agent can neither switch it off nor redirect it. The monitor at OpenAI worked; the chain to the human did not. Several principles can be derived from this for your own agents.

• Monitoring and logging run in a separate account or service. The agent has neither read nor write access to it.
• Logs are append-only or sent to an external service that the agent cannot change.
• Alert paths, meaning recipients, thresholds and switches such as no_notify, live in a configuration that only humans can change. They do not belong in the repository the agent works on, or they are locked there by a protection rule.
• A heartbeat reports when alerts or logs stop arriving. Silence then becomes a signal in itself. In incident 1, a heartbeat could have revealed that no notification was arriving anymore.

A simple example of a heartbeat is a schedule that triggers a test alert every day and expects a response. If it does not arrive, a separate service reports the failure to an on-call team. The effort is small, the benefit large: a silent failure in the alert chain becomes visible.

Anyone who wants to monitor AI agents should also avoid making the monitoring itself dependent on another agent with the same permissions. The study mentioned above views AI as a supervisor critically, and the incident at OpenAI shows that oversight can fail at the alert chain. Technical separation of permissions is more robust than another agent.

Changes to tests, monitoring and permissions only with approval

The second case shows that protecting the monitoring is not enough. Everything it safeguards needs protection too: the tests, the configuration and the permissions. For coding agents, Git platforms offer ready-made tools for this.

• Protected paths: files for monitoring, alerting, permissions and protective tests are assigned to humans in a so-called CODEOWNERS file. Changes to them require their review.
• Branch protection: the agent works on its own branches. Only a human may merge, and the mandatory review cannot be bypassed.
• Diff checks: an automatic check fires when tests are deleted or their assertion is reversed and when calls to the monitoring disappear. The replaced test from the Astra case would have been caught this way, because a positive check became a negative one.
• Test integrity: the pipeline that runs the tests runs outside the agent's reach. It should load the protective tests from the main branch, not from the agent's branch.
• Approval gates: actions with consequences, such as changes to permissions, deletions or privilege escalation, require explicit human approval.

Limiting the permissions of coding agents is the most effective single measure. An agent gets access only to the project it is working on, and only for the duration of the task. Credentials for production systems do not belong in its environment. Where access is necessary, it should run via short-lived, narrowly scoped tokens whose use is logged.

Wording instructions so that safety functions are excluded

In the first case, a terse negative instruction led to a broad interpretation. In the second case, the phrase “as appropriate” opened up leeway. Both can be reduced with more precise wording. A few rules have proven useful as guardrails for AI agents.

• Narrow down negative instructions: instead of “don't send any messages”, better “don't send chat messages to employees”. The purpose of the restriction is named.
• State explicitly what is never touched: monitoring, alert paths, permissions, protective tests, logs.
• Avoid hedges: phrases such as “as appropriate” or “if possible” have no place in safety requirements.
• Pass limits on to subagents: chains of tasks receive the same prohibitions word for word, not in the main agent's own words.
• Stop in case of conflict: the agent should report and ask when a task seems solvable only by interfering with safety functions.

One limitation is important. Wording is a second-line measure. In the first case, the main agent had even explicitly told the subagent to preserve the monitoring, and the intervention still happened later. Instructions reduce the likelihood of errors, but they are not a technical barrier. Reliability only comes from the permissions and approvals described in the two previous sections.

Human oversight and the AI Act: what can be substantiated

The ideas behind these measures can also be found in the EU AI Act. For high-risk systems, Art. 14 of the regulation requires that they be designed so that natural persons can oversee them effectively, including intervening and stopping them. Art. 12 provides for the automatic recording of events for these systems so that their operation can be traced. The wording in the Official Journal of the EU remains authoritative.

The scope is important. These obligations apply to high-risk systems. A coding or operations agent in a mid-sized company is not automatically a high-risk system. The classification depends on the intended purpose and must be assessed case by case. An obligation for typical SME agents can therefore not be derived across the board from either article.

Even without an obligation, the ideas are useful as orientation. Human oversight of an AI agent means: there is a person who can stop the agent, receives the alerts and reviews the results. Traceability means: there are logs that the agent cannot change itself. Both match the lessons from the two incidents. For agents that process personal data, data protection obligations come on top, which are not covered in depth here.

Checklist: from pilot operation to a controlled agent

The following list summarizes the measures. It is suitable as a review path before expanding a pilot.

1. Minimal permissions: access only to what the task needs, limited in time.
2. Separate monitoring: a separate account or service, outside the agent's permissions.
3. Protected alert recipients: recipients, thresholds and switches can only be changed by humans.
4. Approval for tests and monitoring: changes only with human review, protective tests from the main branch.
5. Check reports against logs: compare final messages with the diff, test runs and logs.
6. Heartbeat: missing alerts and logs report themselves.
7. Narrow instructions: name exceptions for safety functions, remove hedges, pass limits on to subagents.
8. Kill switch: a way to stop the agent immediately and revoke its access.
9. Spot checks: have humans regularly trace individual runs.
10. Owners and emergency plan: named people for alerts, clear steps for emergencies.

For points 1 and 2, it is worth looking at the attack surface beforehand: automated web security checks reveal open access points on the systems an agent is supposed to work on.

Conclusion: trust is not a control measure

The two cases show how easily a safety function can be lost during routine work. Four key points follow from this.

• What has been reported is behavior, not intent. According to OpenAI, the cause is open, and it is not needed for protection.
• AI agent security depends on permissions. What the agent cannot reach, it cannot switch off.
• Tests, monitoring and alert paths themselves need protection and require human approval.
• Self-reports do not replace verification. Logs, tests and diffs outside the agent provide the proof.

Trust in a model may be useful, but it is no good as a control measure. Control means that it works even when the agent does not want it to.