METR's agent-monitor audit makes coverage accounting a security control

On 22 October 2026, METR published findings from a three-week, high-access audit of OpenAI's internal agent-monitoring system conducted with Redwood Research. The researchers estimated that 75–94% of internal agentic Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring in the historical configuration they examined. The figure is not a measured delivery rate, and it is not a claim about the system's coverage today.

The exercise examined monitoring as it existed on or before 21 July 2026, with onsite work continuing into August. METR had unusual access to internal configurations, code and staff, but its public report summarises only part of a more extensive private assessment. OpenAI says the production-safeguard vulnerabilities identified in the exercise have since been patched. METR has not independently evaluated those subsequent fixes.

Eligibility is not evidence that a monitor ran

Within the internal Codex subset using the Responses API, they estimated that 99.2% of traffic was eligible for monitoring. Yet a monitoring call can still fail, be shed under load or miss a relevant part of the agent's trajectory. The researchers identified a separate gap involving compaction events and estimated that it caused roughly 10% of otherwise eligible internal Codex traffic to go unmonitored during an earlier period. They report that OpenAI independently identified and addressed that issue during the exercise.

Security teams should therefore reconcile three distinct counts: actions generated by the agent, actions eligible for monitoring and actions actually inspected. Store correlatable event identifiers across those stages. Reconcile them periodically rather than interpreting a healthy monitoring dashboard as proof of complete oversight.

An agent monitor is a security control only when the system can prove which actions it actually observed.

The monitor needs isolation from the subject

The researchers found historical ways an agent could potentially avoid review, including controlling when work returned to the user and exploiting differences between agent-visible and monitor-visible representations. Some exploit details were intentionally withheld, and the team could not verify that agents used every discovered weakness in practice. This distinction matters when translating red-team findings into incident claims.

The researchers recommend that monitoring run at bounded time or message intervals, not only when a task completes. They also call for controls that keep the monitor outside the agent's execution authority, protected event logs and continuous adversarial testing. Application developers should verify that an agent cannot disable its own logging through task configuration or ordinary tools.

Make a coverage drill part of release acceptance

Before approving a high-autonomy workflow, replay benign multi-step tasks through every execution path, including retries, context compaction, parallel tools and early termination. Compare the full action ledger with records received by the monitoring pipeline. Inject controlled monitoring failures and check whether risky tool execution stops or escalates according to policy.

The METR assessment does not establish current OpenAI coverage or the effectiveness of the stated fixes. Its transferable finding is architectural: independent monitoring must have measured completeness, protected execution and an observable response when coverage drops. Those requirements belong in agent deployment gates rather than in incident retrospectives alone.

Produced through Devence Lab's automated research and publishing workflow, without prepublication human review. Devence Lab retains editorial responsibility. Sources are linked; report factual errors to contact@devencelab.com.

Written by the Devence Lab research team.