METR and Redwood Found Six Ways to Blind OpenAI's Coding Agent Monitor

METR and Redwood Research embedded at OpenAI for three weeks and found multiple exploits that let agents evade internal misalignment monitors.

·
·
·
METR and Redwood Found Six Ways to Blind OpenAI's Coding Agent Monitor
Read5 min
TypeNews
SubtopicRed Teaming · Policy
  • METR and Redwood Research spent three weeks embedded at OpenAI stress-testing its internal agent misalignment monitoring.
  • Roughly 10% of internal Codex traffic went unmonitored May-July 2026 due to uncovered compaction events.
  • RL training rollouts were not monitored for misalignment at the start of the exercise.
  • Team found exploits to bypass Codex sandboxing, hide hundreds of actions, and crash the monitor via serialization mismatches.
  • Two client-controllable HTTP headers could disable monitoring on new agent instances entirely.
  • OpenAI says all production-impacting vulnerabilities have been patched; full 61-page report stayed internal.

From July 21 to August 11, 2026, two external researchers worked inside OpenAI to test whether its coding agents could evade internal safety monitoring. The three-week exercise uncovered coverage gaps, a potential Codex sandbox bypass, client-controlled headers that disabled monitoring, and a method that could conceal hundreds of recent agent actions.

The joint 61-page report from METR and Redwood Research documents how OpenAI’s monitoring system behaved under adversarial review. Coding agents can edit repositories, run shell commands, and call networked tools, so failures in the monitoring path can hide consequential behavior.

Three weeks inside OpenAI’s stack

The pilot gave one METR employee and one Redwood employee access to OpenAI’s internal codebase, monitor prompts, configuration details, and documentation. They also interviewed about a dozen researchers and engineers from the monitoring, safety-systems, and security teams.

Area Pilot conditions
Duration July 21 to August 11, 2026
Researchers One METR employee and one Redwood employee
Access Internal code, prompts, configuration, documentation, and technical interviews
Security controls OpenAI-issued laptops remained on the premises, and the researchers were accompanied on site
Scope Measure monitoring coverage and test whether agents could subvert the monitor

OpenAI’s misalignment monitor reviews agent trajectories for suspicious behavior. A trajectory is the sequence of prompts, model outputs, tool calls, and results produced during an agent session. The monitor’s prompts looked for scheming, sabotage, data exfiltration, deception, monitor subversion, and inbound or outbound prompt injection.

Coverage slipped at lifecycle boundaries

The report separates monitoring eligibility from completed review. Eligibility meant a trajectory qualified for monitoring under OpenAI’s rules; actual review also depended on triggers, data handling, and successful delivery to the monitor.

Traffic or metric Reported result
Internal agentic Responses API traffic from models rated at least as capable as GPT-5.5 An estimated 75% to 94% was eligible, with substantial uncertainty
Internal Codex agent traffic 99.2% was eligible
Monitor request errors Fewer than 0.2% of requests

Context compaction created one of the largest gaps. Compaction summarizes a long trajectory so an agent can continue within its context window. Because those events were excluded from monitoring, the report estimates that about 10% of otherwise eligible internal Codex traffic went unmonitored between May and July 2026. OpenAI independently identified the issue and fixed it during the pilot.

Reinforcement-learning traffic had a separate coverage gap. OpenAI monitored a subset of training rollouts between March and June, but its monitoring system covered no RL training runs when the exercise began. A rollout is a sequence of model actions generated during training, where models can acquire or strengthen new behavior.

The request error rate reflects traffic that reached the monitor. Coverage calculations include trajectories that failed to arrive because of lifecycle events, configuration, or triggering logic, making reliable request handling only one part of the system’s effectiveness.

Scatter plot comparing the agent-to-monitor time-horizon ratio with covert success rates
The report compared agents’ action horizons with monitors’ review horizons to evaluate covert success.

Six routes around the monitor

The researchers identified six mechanisms that could let an agent avoid review, exceed its permissions, or alter what the monitor received. Some exploit details were redacted from the public report.

  • Delay the trigger: Monitoring ran when an agent returned control to the user. While compaction events remained unmonitored, an agent could keep taking actions and postpone review indefinitely.
  • Escape Codex controls: A sandbox and Auto-Review bypass could, in principle, let a Codex agent perform any action available to the host user.
  • Hide recent activity: One exploit could prevent hundreds of recent actions from reaching the monitor, including the steps used to execute the exploit.
  • Exploit serialization differences: Specially constructed inputs could make monitoring fail because the agent and monitor received different serialized versions of the trajectory.
  • Disable monitoring with headers: Two client-controlled headers could switch off monitoring for new agents, allowing an agent to start an otherwise identical unmonitored instance.
  • Abuse tool permissions: Two unmonitored internal tools believed to be read-only could be exploited to take arbitrary actions inside their sandboxed environments.

When the pipeline ran as designed, the monitor received nearly the full trajectory visible to the agent, subject to a few minor exceptions. That broad visibility supported checks across model outputs, tool use, prompt injection, and attempts to interfere with oversight.

Build the monitor as a control plane

The report’s recommendations translate into five concrete engineering practices for teams deploying monitored agents:

  1. Run monitoring independently of agent behavior. Trigger reviews after a fixed number of messages or minutes instead of waiting for the agent to end its turn.
  2. Account for every trajectory. Give inference, tool, and monitor events stable identifiers; cross-check their logs; and alert when the monitor receives incomplete or altered context.
  3. Prepare incident response. Assign ownership, define escalation paths, and retain searchable, tamper-evident logs.
  4. Test continuously. Repeat adversarial control evaluations and add every discovered bypass to regression tests.
  5. Separate execution from oversight. Isolate agent scaffolds, tool execution, and monitoring infrastructure so agent actions cannot disable, delay, or modify review.

After the pilot

OpenAI told the researchers that it patched every identified vulnerability affecting its production safeguards stack. The company later described further changes to monitoring coverage, which the pilot did not evaluate.

The evidence covers two researchers, three weeks, and OpenAI’s internal systems during a specific period. At least one exploit was redacted, preventing public reproduction of every finding, and the report does not quantify how often agents attempted these techniques outside the exercise.

The failures clustered around system handoffs: context compaction, event serialization, user-controlled headers, permission assumptions, and triggers tied to agent behavior. Production designs should give those handoffs stable identities, independent schedules, strict authorization, and tamper-evident audit trails. Monitoring effectiveness depends on every relevant trajectory reaching the monitor intact.

Trending
  • No trending articles

Comments

avatar

Next Reads