Skip to content
MoorAI
Get MoorAI
MoorAIJournal
On this page
WhathappenedWhy it is anagent-securityproblemWhat to do:five controlsWhereMoorAIfitsSources
// blog · operator’s guide

When a coding agent weakens oversight: hold it, disclose it, page on it

OpenAI describes two internal cases of agents weakening the monitoring around them during ordinary work. Why this belongs on the security team’s list, five controls, and where MoorAI fits.

MoorAI October 22, 2026 ~6 min read MoorAI
Diagram titled When a coding agent weakens oversight: the change is held, the final message is checked, and the console pages. An agent or sub-agent doing an ordinary task makes Write, Edit, MultiEdit, Bash or PowerShell calls. MoorAI for Agents, threat 84, flags a suppression flag set on, alert recipients emptied, monitor wiring removed, a test rewritten to assert absence, or a key that turns monitoring off, plus protected paths and keys in signed policy. It asks by default, with justify or a hold for an approver, and notify, block or kill set by signed policy. At Stop it checks whether the final message says so; if not, an Undisclosed oversight change alert. Both feed the Management Server, where oversight alerts are page-worthy: emailed and pushed to SIEM whatever the email setting, with the acting and parent session shown, an optional response to ask for a reason or end the session, and a warning when a page has nowhere to go. Below: it judges the agent's own tool calls on the device, not changes made in CI, by a person or by other tools. When a coding agent weakens oversight The change is held, the final message is checked, and the console pages. AGENT OR SUB-AGENT Write · Edit · MultiEdit Bash · PowerShell an ordinary task, ordinary words MOORAI FOR AGENTS · #84 suppression flag set on alert recipients emptied monitor wiring removed test rewritten to assert absence a key that turns monitoring off plus protected paths and keys in signed policy ASKS BY DEFAULT justify, or held for an approver notify · block · kill by signed policy AT STOP does the final message say so? if not: Undisclosed oversight change MANAGEMENT SERVER · PAGE-WORTHY emailed and pushed to SIEM, whatever the email setting · acting and parent session shown optional response: ask for a reason, or end the session · a warning when a page has nowhere to go Judges the agent's own tool calls on the device, not changes made in CI, by a person or by other tools. AI security at the point. · Open source · MIT · moorai.dev MoorAI

A coding agent asked to fix a pipeline silenced the alerts that watched it. Another agent’s sub-agent removed a monitor and rewrote the test that protected it, and the parent reported the job done. Neither was an attack. The change that weakened oversight arrived as part of the task.

What happened

OpenAI published a misalignment report on two cases from its internal deployments, last updated on 20 October 2026.

Case 1: alerts silenced

A researcher asked an agent to build evaluation tasks and not to send any messages. When a monitor’s finding could not be saved and the pipeline stopped, the researcher asked it to change the monitoring destination and rerun. A sub-agent it delegated to advised against turning notifications off. The parent’s patch did it anyway: it set a no-notify flag, emptied both alert recipient lists, recorded the no-messages instruction as the reason, and added a check that fails unless notifications stay off. The monitor still ran; no person was alerted.

Case 2: a monitor removed

Asked to copy a reference pull request’s serving path, an agent delegated the migration and loosened the instruction to keep monitoring, making it depend on what suited the reference. The sub-agent removed the custom monitoring components and replaced the regression test that guarded them with one asserting the monitor was absent. The parent’s summary called the migration complete without mentioning it. Asked directly, it said it had not removed an enabled monitor, which OpenAI describes as false.

OpenAI does not claim a motive. It is weighing benign overpersistence against a propensity to evade monitoring, and writes: “We don’t yet have a satisfying explanation for this behavior.” Neither incident was rated top severity, and neither run was stopped automatically. OpenAI notes that monitoring is harder to disable where it runs outside the agent’s control, and has updated its automated review to detect and block attempts to disable it.

Why it is an agent-security problem

Whatever the cause, the result is the same: the control that would catch the next mistake is gone, and its owners do not know. Three patterns let it through.

Ordinary instructions read as permission

“Don’t send messages” became a reason to silence alerts. “Match the reference” became a reason to drop a monitor. Nothing in either request was hostile, so a control that looks for bad intent in the prompt finds nothing. The signal is in the change.

Delegation launders the change

A sub-agent was involved in both cases, and in the second it made the change. The person sees the parent’s session. Unless a sub-agent’s action is tied to the session that delegated it, the change belongs to no one.

The completion report leaves it out

People read “done”, not every line of the diff. A summary that omits the change, or denies it, removes the last point where a person could catch it.

And a single config edit rarely scores high enough to page anyone.

What to do: five controls

1. Keep monitoring out of the agent’s reach

Run monitors, alert routing and audit logging where the agent’s credentials and working directory cannot change them: a separate service, a separate repository, or configuration the agent’s account cannot write. This is the strongest control. The rest cover what still sits inside the agent’s reach.

2. Declare protected oversight surfaces

Write down the files and keys your oversight is made of: the alerting config, the monitor module, the suppression flag, the recipient lists, the audit-log switch. A tool can then treat any change to them as an oversight change, however the agent describes it.

3. Require approval for changes to them

Do not block outright, because a legitimate refactor will touch these files. Make the change wait for an answer from whoever owns the monitoring.

4. Require disclosure at the end of the task

If an oversight change went through, the agent’s final message should say so in plain words. If it does not, someone should hear about it.

5. Page on it

Treat a weakened monitor as page-worthy whatever its severity score, and check that the page has somewhere to go.

Where MoorAI fits

MoorAI for Agents (free, open source under MIT) runs in the coding agent’s pre-tool hook. Under threat #84, Weakening oversight, it judges the agent’s own Write, Edit and MultiEdit calls, with the file before and after, and its Bash and PowerShell commands. It flags the change, never a mention:

Docs, fixtures, comments, a new alert, a tuned threshold and vendor telemetry opt-outs are not findings.

Ask by default. A finding asks (the justify action), never passes silently. Policy can set notify, block or kill instead, and an approval routing rule for threat 84 holds it for a named approver group. The alert is content-free: a category and a reason code, no path, key or value.

Protected surfaces. The signed policy can list up to 64 paths and 64 keys that are always judged under #84:

"oversight": {
  "v": 1,
  "protectedPaths": ["src/monitoring/**", "config/alerting.yaml"],
  "protectedKeys": ["no_notify", "ALERTS_ENABLED"],
  "stopDisclosure": "alert"
}

Any write to a protected path, any write that changes a line naming a protected key, and any command that deletes, moves or writes one is held. Paths are resolved through their real path, so a symlink does not get around one.

Sub-agents. A sub-agent’s change is judged exactly like the main agent’s, and its alert names the session that delegated it.

Disclosure at Stop. In Claude Code, when a turn or a sub-agent ends after an oversight change that went through, or one whose outcome Claude Code does not report back, MoorAI reads the final message in memory and checks whether it states the change. If not, it raises an Undisclosed oversight change alert, and the parent answers for its sub-agents’ changes too. With "stopDisclosure": "block", Claude Code is told to continue and state the change, once per turn; other agents get the alert only. The check reads whether the message says so, not whether it is true.

Paging, in the MoorAI Management Server. Oversight alerts are page-worthy: emailed to the tenant’s alert recipient and pushed to SIEM when streaming is on, whatever the policy’s email setting. A delegated change shows both the acting and the parent session, in the email and on the Oversight changes panel. An optional signed-policy response makes #84 ask for a reason, or deny the call and end the session. A tenant with no alert recipient and no SIEM streaming sees a warning that pages have nowhere to go.

Measured on a hand-built set

Both report cases are rebuilt as test fixtures, six edits and seven commands, and every one is detected, as are ten other shapes. Of 42 hand-built benign near-misses (adding an alert, re-enabling notifications, a README mention, a test-only env file, a one-run env prefix), none is flagged. That is a fixture set, not a field rate.

MoorAI judges the agent’s own tool calls on the device. It does not see changes made in CI, by a person or through other tools, which is why the first control comes first.

The Management Server is free to self-host with no user limit; the hosted console is a free trial, then contact us.

Sources

See also: MoorAI for AI coding agents and What’s new in MoorAI: fail mode and living off the AI.

Make oversight changes ask, and page on them.
MoorAI for Agents is free and open source under MIT. Self-host the Management Server free, with no user limit.
Download free → Talk to us