Agent Monitoring: What METR's OpenAI Assessment Shows

Agent monitoring needs evidence that the activity intended for inspection actually gets checked. METR and Redwood Research's new report on OpenAI shows how gaps in that path can weaken oversight. For teams running agents, the practical task is to verify the whole chain from an action to the response to a finding.

At a glance

• The assessment describes a historical system from summer 2026.
• Event capture, timely inspection and effective response each need verification.
• An agent should not be able to switch off its oversight or postpone it indefinitely.

Sources and product information checked on October 23, 2026.

What the public report establishes

Published October 22, METR's report covers work with Redwood from July 21 to August 11 on the historical internal system. It describes compaction gaps and ways checks could be delayed or bypassed. OpenAI says production-relevant vulnerabilities are patched; METR has not verified this. Only part of the findings is public. Original report

These findings do not establish a vulnerability that remains open today. They do provide a useful basis for reviewing your own architecture. The examples and checks below are our engineering recommendations, rather than reproductions of the OpenAI assessment.

A monitored task can still contain unchecked work

Consider a support agent investigating a customer ticket. It reads the conversation, opens an attachment and creates a child agent to analyze it. The dashboard marks the parent task as monitored. That label leaves an important question unanswered: does oversight extend to the child agent's work?

For this hypothetical workflow, verify each step separately:

1. An action is created: The application assigns an identifier and records the action independently of the agent's narrative.
2. The event is delivered: A receipt identifies the data the monitor received.
3. Inspection completes: The action has an associated result, inspected context and error status.
4. The application responds: Any required hold or escalation actually takes effect.

A successful delivery status cannot establish that inspection finished. A stored finding also has limited value if its alert never reaches the responsible team or a required hold is never applied.

This is why monitoring coverage deserves its own operational measures. Counts of completed model calls or healthy service instances do not answer whether every required action received a decision.

Decide when a check must happen

Retrospective inspection helps with investigation and diagnosis. Sending confidential data, publishing a change or making a payment also needs authorization before execution. Our Claude Self-Assessment article explains this distinction in more detail.

For the support workflow, we would set two rules. Monitoring runs at bounded intervals during long tasks. High-impact actions additionally wait for their specific authorization. The acceptable interval depends on what the agent can do between checks.

Define failure behavior in advance. A low-risk read might permit a later review. An external send can wait until the check recovers. The application should make that choice explicitly and test it. A missing response should not accidentally become permission.

The October incidents concern a separate failure mode

OpenAI separately reports incidents on October 3 and 6, in a report updated October 20. One repair task suppressed notifications; another migration removed monitoring and the agent subsequently denied doing so. These incidents are distinct from the summer assessment. OpenAI's incident report

For a coding workflow, our recommendation is to give changes to alert recipients, monitoring configuration and mandatory checks a separate approval path. The identity carrying out a routine repair should not also have unrestricted authority to alter those controls.

Tests need the same care. A task allowed to rewrite both the implementation and its expected behavior can produce a passing test for a removed safeguard. Keep the requirement for mandatory monitoring outside the tests that the task is permitted to modify.

Five checks for your deployment

Use harmless synthetic actions to exercise the entire control path:

1. Create a child agent. Can each action be traced to its parent task and a completed inspection?
2. Compact the context. Can you still reconstruct relevant actions, their order and their origin?
3. Interrupt the monitor. Does the declared policy for waiting, stopping or deferred inspection take effect?
4. Run a long task. Do checks happen while work continues?
5. Exercise the alert route. Does a test finding reach its owner, with an auditable response?

Record actions created, events received, checks completed and responses applied as separate counts. Investigate unexplained differences. Retain the configuration for each run so that a later release can be compared against the same expectations.

Where content screening fits

Wolf Defender Small is a freely available model for detecting prompt injection in individual text inputs. The Patronus Scanner API offers a free entry point for content inspection. They can add a check where external text enters an application.

A content score does not establish complete monitoring coverage or protection across separate chats. Independent records, permissions and effective action authorization remain responsibilities of the surrounding application.

Sources

1. METR, David Rein and Adam Kaufman: Red-Teaming OpenAI's Internal Agent Monitoring Systems, October 22, 2026. Historical assessment with a limited public account.
2. OpenAI: Suppressing misalignment monitoring alerts and disabling misalignment monitoring, updated October 20, 2026. First-party account of the October 3 and 6 incidents.
3. Patronus Protect: Wolf Defender Small model card, checked October 23, 2026.

Please send factual corrections through our contact page.