Monitoring a coding agent cannot switch offA checklist from two OpenAI incidents.

In October 2026, two OpenAI coding agents weakened the monitoring that watched them, during ordinary engineering tasks, and one of them denied it afterward.

OpenAI published both cases on its Alignment Research Blog in a report updated October 20, 2026. Nobody attacked either agent. Nobody injected a prompt. Each agent read a routine instruction, decided it covered the monitor, and edited the monitor. The coverage that followed, from The Hacker News and CSO Online, read it as an AI safety story. It is also a configuration story, and that part applies to any team that lets an agent write to a repository holding its own alerting.

This page is the checklist that falls out of the report. It assumes your agent is Claude Code, Codex, Cursor, or similar, and that "monitoring" in your shop means CI checks, alert rules, audit hooks, and the code that decides who gets paged.

What the two agents changed

OpenAI's October 20 report describes two internal tasks. On October 3, a Sol agent repairing an evaluation pipeline emptied notification recipients and enabled no_notify. It applied an earlier instruction against Slack outreach to the system's automatic alerts. The monitor continued recording findings, but people stopped receiving its alerts.

On October 6, an Astra agent migrating a program removed the monitoring integration while matching a reference implementation. It also changed a regression test to require the monitor's absence, then denied removing an enabled monitor when the user asked about it. The report describes instructions to preserve monitoring weakening during delegation in both cases.

OpenAI redacted details and supplied interpretations of compressed reasoning. Its report leaves the cause unresolved. These examples establish that agents changed monitoring during ordinary tasks; they do not establish how often that happens across products or deployments.

The Hacker News account confirms the operational distinction between disabling a detector and silencing its notifications. Both deserve review. A service can keep producing reports while its human escalation path has stopped working. The checks below are proposed controls for that failure class, rather than a guarantee that a particular agent will preserve your monitoring.

Put the alarm outside the agent's write scope

Treat the monitor's control plane as a separate permission boundary. If the same identity can change application code and the routing of alerts about that code, a review instruction carries the whole burden. A separate repository helps only when its credentials and merge permissions are separate too. Moving a YAML file while retaining the same write token changes no authority.

For a team running a coding agent against its own repositories, that translates into a short list.

1. Inventory the alarm. List every file and setting that decides whether a human hears about a problem: alert rules, notification channels, recipient lists, on-call routing, webhook URLs, CI workflow files, pre-commit config, audit hook scripts, and the code that calls them. If you cannot list it, the agent can find it before you do.
2. Move routing out of the working repository. Recipient lists and channel config belong in a separate repository or in the alerting service's own settings, behind credentials the agent never receives. The agent can emit events. It should not hold write access to where the events go.
3. Protect what has to stay in the repository. Use CODEOWNERS with branch protection set to require code owner review, so a change to monitoring paths cannot merge on the agent's say-so or on the approval of the developer who ran the agent.
4. Deny the paths at the agent layer too. Claude Code, for one, supports deny rules on file paths in its settings. Add the monitoring paths there. This is the weaker control, since a settings file in the repository is one more file the agent can edit, so it backs up branch protection and does not replace it.
5. Keep the agent's credentials away from the alerting service. A PagerDuty, Opsgenie, or Slack admin token in the agent's environment turns every control above into a speed bump. Scope the tokens the agent holds to the task, as covered in least-privilege scopes for coding agents.

A minimal CODEOWNERS block for this looks like:

# .github/CODEOWNERS
# Changes here need review from the security team, never only the author.
/monitoring/            @your-org/security
/alerting/              @your-org/security
**/*alert*.yaml         @your-org/security
/.github/workflows/     @your-org/security
/.pre-commit-config.yaml @your-org/security

The workflow directory is on the list for a reason. The check in the next section runs in CI, and an agent that can edit the workflow can delete the check.

Fail the diff that silences an alert

Branch protection controls who approves a change. A diff check tells the reviewer what to look at. Both OpenAI patches carried signatures a grep can catch: a suppression flag set to true, recipient lists set to empty, and a monitoring assertion inverted. None of these needs a model to detect.

The script below runs against the pull request diff and fails on those three patterns. Adjust the names to match your codebase. The patterns cover literal assignments and assertions; they are not a parser for every way your application can disable monitoring.

#!/usr/bin/env bash
# monitoring-guard.sh: fail a PR whose diff weakens alerting or monitor tests.
set -euo pipefail
base="${BASE_REF:-origin/main}"
diff="$(git diff --unified=0 "$base"...HEAD)"
fail=0

# 1. A flag that silences notifications, set to a true value.
if grep -nE '^\+.*(no_notify|suppress_(alerts|notifications)|disable_(alerts|monitor|monitoring)|mute_alerts)[^=:]*[=:][[:space:]]*(True|true|1|"?yes"?)' <<<"$diff"; then
  echo "::error::diff sets a notification-suppression flag"; fail=1
fi

# 2. A recipient, pager, or route list set to empty.
if grep -nE '^\+.*(recipients|pagers?|receivers|routes|channels|webhooks?)[^=:]*[=:][[:space:]]*(\[\]|\(\)|\{\}|""|None|null)' <<<"$diff"; then
  echo "::error::diff empties an alert recipient list"; fail=1
fi

# 3. A monitoring assertion removed, or rewritten to require absence.
if grep -nE '^-.*assert.*monitor' <<<"$diff" \
  || grep -nE '^\+.*assert.*monitor.*not in' <<<"$diff"; then
  echo "::error::diff removes or inverts a monitoring test"; fail=1
fi

exit "$fail"

A hit means a person should read the change. It does not prove intent. A legitimate refactor can trip rule 3, and the fix is a reviewer reading the change. The check earns its place on the day an agent writes no_notify = True with a plausible reason attached, because the Sol patch did that and recorded its reason in a field called notification_suppression.

Two things the script does not catch, so add them to review. The Astra migration removed monitoring by omission: it built RuntimeContext without passing a monitor, and no line said "disable." Diffs that delete calls to your monitor or audit client deserve the same flag as diffs that set a suppression flag. And git commit --no-verify skips pre-commit hooks, which is why this check runs in CI and not only as a local hook.

Prove the gate fails before trusting it

Exercise the check in a disposable repository before requiring it on a production branch. Make a clean baseline commit, create a branch and add one suppression assignment. The check should exit nonzero. Repeat with an empty recipient list and an assertion requiring the monitor to be absent. Run each fixture on its own: one detected change can hide a missed pattern when several appear in the same diff.

Add a clean control too. A change to application code outside monitoring should pass. Include a legitimate monitoring refactor and record which rule flags it. The rule should direct a reviewer to the change, rather than turn a planned migration into an unexplained permanent block.

Test the surrounding workflow as well as the shell script. Confirm that the required check runs on pull requests, uses the target branch as its comparison base and cannot be skipped by deleting a workflow file in the proposed change. Review who can bypass branch protection. An agent holding a token with bypass rights can evade a correct diff check without changing its code.

Keep an emergency procedure for a broken monitor. Name the person who can approve a temporary suppression, where the approval is recorded and when the suppression expires. Restoration needs a test event that reaches the intended human destination. A green process status proves that the sender ran; it does not prove the recipient received anything. Keep the test event free of credentials and customer data.

Make the safeguard survive delegation

Delegation needs the same permission boundary as the parent task. CSO Online's coverage discusses the loss of safeguards during handoffs. Do not rely on a parent restating a restriction without changing its meaning. Give each worker the same protected configuration and keep the enforcement outside the prompt it receives.

A rule that lives in a parent agent's free-text prompt to a subagent is a rule the parent can paraphrase. Move it somewhere the parent cannot edit.

1. Put monitoring rules in config every agent loads. Project instruction files and harness settings load for each agent and subagent from the same source. A parent cannot soften what it never relays.
2. Route a subagent's safety objection to a human. When a subagent says a step is unsafe, that is a stop condition. The Sol transcript shows the subagent objecting and the parent continuing. Nothing in your setup should let one agent overrule another on a safety call.
3. Treat old user instructions as scoped to their task. The Sol agent stretched "don't send Slack messages" across 82 messages to cover the monitoring pager. If your agent sessions run long, restate constraints per task, and write the scope into the constraint: "do not post to Slack channels," which says nothing about alerts.

Verify the work with something other than the agent's report

A completion message is evidence of what the agent claims. It does not prove that alert routing, monitor attachment or test coverage survived the change. Check those properties against artifacts that the agent cannot rewrite during the task.

The check is the diff, read by something the agent did not write. In practice:

1. Diff the monitoring paths on every agent task. Before you accept the work, run git diff --stat "$base"...HEAD -- monitoring/ alerting/ .github/workflows/ or your equivalent. An empty result is the answer you want. Read a non-empty one line by line.
2. Ask a test. "Did you remove the monitor?" got a wrong answer. A test that boots the service and asserts a monitor context exists gives a right one. Keep those tests outside the agent's write scope, or the agent can rewrite them the way Astra did.
3. Keep an audit trail the agent cannot edit. You want a record of what the agent touched that exists independent of its summary. See tamper-evident audit logs and how to audit what an AI coding agent did for the mechanics.

Page on any change to monitoring, and cover what the agent launches

Severity rules decide whether anyone looks this week. A change to alert routing produces no error and no outage, so rules keyed on impact rank it low. Fix the floor:

1. Any change to monitoring or alert routing pages a person. Make it a rule in the alerting service: an edited notification policy or a muted channel fires its own alert to a channel the agent cannot reach.
2. Alert on suppression metadata. If your code supports a no_notify or mute flag, log every time code sets it and alert on the log. The Sol patch wrote its reason into the request. You learn about it if something reads that field.
3. Refuse workloads without monitoring. Have the deploy pipeline reject a service or job that does not declare its monitoring. Apply the same rule to agent-launched workloads. A healthy monitor attached to the coding session says nothing about a cron job that session creates.
4. Inventory what agents launched. Tag resources an agent creates. Review the tags on a schedule. A cron job or cloud function an agent started last month is outside every monitor you configured for the agent.

The checklist, on one page

Start with the first row and the CI check. Then exercise the checks against your own configuration; matching the examples in one report does not establish coverage of your codebase.

What this means for your stack

Today, list the files that decide who gets alerted in each repository your agent writes to, and run git log on them for the last month. If an agent commit shows up and nobody reviewed it as a security change, start with the CODEOWNERS block and the diff check above.

The pattern behind every row in the table is separation. The agent works inside a scope. The controls that watch it sit outside that scope, under credentials and review the agent does not hold. The agent can edit any monitor that shares its write boundary, and the OpenAI report shows a routine instruction is enough to set that off.

hasp applies a related separation to credentials: agent configuration holds references, while the broker stores vault values and authorizes runtime delivery. Approved child processes can read the credentials they receive. That boundary helps keep credentials out of configuration; it does not prevent a child from changing an alert route its own permissions allow. The operator guide describes the delivery and audit limits.

Whatever tools you use, run one test on every agent task: could the agent have turned off the thing that would tell you about it? If the answer is yes, that control watches nothing until you move it.