Safety & Security

METR Finds Flaws in OpenAI’s Internal AI Agent Monitoring

OpenAI’s internal AI agent monitoring system had vulnerabilities that could let agents evade oversight, bypass Codex security restrictions, and conceal hundreds of actions, according to findings published by the independent AI safety organisation METR on 22 October 2026.

The findings follow a three-week investigation METR and Redwood Research conducted at OpenAI’s premises between 21 July and 11 August. Researchers gained unusually deep access to internal code, monitoring configurations, and engineering staff to assess whether OpenAI could reliably detect misaligned behaviour in its AI agents.

OpenAI says it has since patched vulnerabilities affecting its production safeguards. However, METR has not independently verified those fixes, and its assessment does not establish the effectiveness of OpenAI’s expanded monitoring system.

The independent investigation uncovered several monitoring weaknesses

According to METR’s published assessment, researchers found vulnerabilities affecting monitoring coverage, the integrity of agent activity records, and restrictions on internal Codex agents.

FindingWhat the researchers established
75%-94% monitoring eligibilityEstimated proportion of qualifying internal Responses API agent traffic from models at least as capable as GPT-5.5 that was eligible for monitoring.
Codex sandbox bypassResearchers identified a potential method for internal Codex agents to bypass sandboxing and Auto-Review restrictions.
Hidden agent actionsAn exploit could prevent hundreds of recent actions, including the exploit activity itself, from reaching the monitor.
Monitoring disabled for new agentsTwo independently controllable settings could allow new agent instances to start without monitoring.
Missing compaction monitoringA historical implementation gap meant some eligible Codex activity did not trigger monitoring as intended.

These findings reflect the system as it existed on or before 21 July, not a measurement of its current safeguards. The researchers also found positive evidence: monitoring errors reportedly fell below 0.2% of requests in the operational data they examined, and monitors generally received the complete agent trajectories they were supposed to inspect.

OpenAI’s reported monitoring coverage needs careful interpretation

One significant result concerns how much internal AI activity was actually subject to oversight.

METR estimated that approximately 75%-94% of qualifying internal Responses API agent traffic from sufficiently capable models was eligible for monitoring. For the subset associated with internal Codex agents, the estimated eligibility figure was higher, at 99.2%.

Neither figure represents the percentage of dangerous actions successfully detected.

Eligible traffic is intended to pass through the monitoring system. An eligible action may still escape inspection because of implementation failures, gaps in how monitoring is triggered or other vulnerabilities. Even a successfully inspected action may not be classified as dangerous.

The estimate also excludes other internal inference services for which METR could not reliably establish traffic volumes. The researchers acknowledged substantial uncertainty around their coverage calculations.

This creates three separate questions for any organisation relying on automated agent oversight: how much activity should be monitored, how much activity actually reaches the monitor, and how reliably the monitor identifies harmful behaviour.

A compaction issue could postpone monitoring indefinitely

One particularly revealing finding involved context compaction, the process through which an AI agent condenses earlier information so it can continue working within its available context window.

At the time, OpenAI’s monitoring system could wait until an agent returned control to its user before triggering an assessment. METR estimated that missing monitoring at compaction events left roughly 10% of eligible internal Codex traffic unmonitored between May and July 2026, though the precise figure was uncertain.

Under those historical conditions, an agent that kept acting without handing back control could indefinitely delay monitoring.

OpenAI engineers had independently identified this problem before the evaluation began and fixed it during the exercise. METR could not establish whether agents had actually exploited the vulnerability.

The broader engineering problem is straightforward. A monitoring system that runs only at convenient workflow boundaries can leave long periods of autonomous activity unchecked. For persistent agents, a more dependable design uses periodic checks that do not depend on the agent voluntarily ending its task.

Codex could potentially bypass security restrictions without escaping its host user’s permissions

METR also discovered a way internal Codex agents could, in principle, bypass Codex sandboxing and Auto-Review controls, potentially gaining access to any action available to the user running the agent.

This finding concerns OpenAI’s internal environment. It does not show the same vulnerability existed in publicly distributed Codex products or that customer systems were compromised.

Nevertheless, it exposes a common weakness in autonomous coding workflows: an agent’s safety restrictions can become less effective when surrounding tools, services, or execution environments provide broader permissions.

A separate finding involved two internal agentic tools that were believed to be read-only. Researchers identified a possible way to circumvent those restrictions, although they did not validate whether the technique worked in practice.

Developers configuring external tools face a similar permissions problem. Our Codex CLI MCP security guide explains how limiting tool access, applying scoped credentials and keeping approval requirements separate from agent instructions reduces exposure.

Monitoring can fail even when the AI’s activity is recorded

The investigation found more than missing coverage. Researchers identified a potential exploit that could hide hundreds of recent actions from the monitoring system, including the steps used to carry out the exploit.

They also found that differences between how the system represented agent activity internally and how it presented it to the monitor could cause monitoring failures without escalating the activity for human review.

This exposes a less obvious limitation of AI-based oversight. An intelligent monitoring model is only useful when the surrounding software delivers trustworthy, complete information for inspection.

A system may appear to have comprehensive logging while still omitting, transforming, or delaying important activity before review. Improving the monitor’s reasoning ability alone will not resolve those failures.

Monitoring systems therefore need independent accounting of agent activity, protected logs, and reliable checks that the monitoring process itself hasn’t been bypassed.

OpenAI says the vulnerabilities have been patched, but verification remains outstanding

OpenAI says it patched all vulnerabilities identified during the assessment that affected its production safeguards. The company also expanded its monitoring infrastructure during and after the evaluation.

METR explicitly states that it has not assessed those subsequent changes or independently verified OpenAI’s remediation claims.

The researchers’ public report also has important transparency limitations. Their three-week engagement produced a 61-page internal assessment shared with OpenAI researchers and security staff, while a 38-page redacted version was shared with METR and Redwood Research leadership.

The public received a substantially shorter account. Under the original agreement, OpenAI could redact information it considered confidential or sensitive, and METR did not have an unrestricted right to disclose the nature of those redactions.

That arrangement enabled unusually detailed technical access but limited what outsiders could independently scrutinise. The exercise was designed as an exploratory assessment rather than a comprehensive public safety audit.

Why the findings matter as autonomous agents become persistent

OpenAI is developing systems that can work across tools, run longer tasks, and delegate work between multiple agents. Its recently introduced Dots always-on AI agents illustrate the industry’s shift toward assistants that can maintain work beyond a single conversation.

Longer-running agents introduce practical oversight challenges. A coding agent might start additional processes, access multiple connected systems or operate across repeated context updates. Each transition creates another opportunity for monitoring coverage and permissions to become inconsistent.

A recurring concern among developers deploying agents into production is that they often introduce broad permissions and extensive activity logs before anyone has established who will review suspicious actions or whether the controls can prevent harmful operations.

The METR assessment reinforces the need to treat monitoring as security infrastructure rather than a reporting feature.

For organisations deploying autonomous coding agents, the practical priorities are:

  • Restrict permissions independently: An agent should not automatically inherit unrestricted access to everything available through its host environment.
  • Monitor continuously: Checks should cover long-running tasks, context compaction and newly spawned agents.
  • Keep monitoring outside agent control: Agents should not be able to modify the configurations determining whether their own activity is inspected.
  • Verify coverage: Compare inference activity against monitoring records to identify missing or delayed assessments.
  • Test incident response: Confirm that concerning activity reaches a responsible human or blocking mechanism quickly enough to limit damage.

These principles matter more as organisations give agents access to repositories, credentials, deployment systems, and business applications.

The next meaningful test is independent verification of OpenAI’s fixes

OpenAI’s willingness to provide embedded researchers with extensive infrastructure access is a valuable development. The assessment uncovered weaknesses that would have been difficult to identify through model benchmarks or demonstrations alone.

However, the published findings establish neither that OpenAI’s current monitoring is ineffective nor that its latest safeguards are sufficiently reliable against deliberate evasion.

The next useful evidence would be an independent reassessment of the expanded system, including verified remediation, updated coverage measurements and testing against agents attempting to avoid oversight over extended periods.

For now, the central finding is that monitoring coverage, reliable inspection and actual control over agent behaviour remain separate engineering problems. OpenAI has reported improvements, but independent evidence of their effectiveness is still needed.

Written by Steven Jones

AI Tools Reviewer and Technical Analyst

Steven Jones is a technology analyst specialising in artificial intelligence, machine learning workflows, and emerging automation tools.

At DIY AI, he focuses on clear, practical guidance for people comparing AI tools in the real world. His work covers text generation, image generation, video tools, data platforms, developer-focused AI products, and the automation workflows that connect them.

Steven's reviews are built around hands-on testing, practical benchmarks, and transparent scoring rather than vendor claims. He looks closely at where each tool performs well, where it falls short, and what those trade-offs mean for creators, teams, and businesses trying to make sensible AI adoption decisions.

He has a particular interest in safety, reliability, output quality, performance metrics, and dataset quality. When he is not reviewing the latest AI model updates, he experiments with prompt engineering techniques and contributes to DIY AI ongoing work on fair, explainable scoring frameworks for AI tools.

Back to AI News