Skip to content

Back to the catalog

Red-Teaming OpenAI's Internal Agent Monitoring Systems
metr.orgwriteup

Red-Teaming OpenAI's Internal Agent Monitoring Systems

METR and Redwood Research summarize a three-week pilot red-team (21 July to 11 August 2026) of OpenAI's internal asynchronous misalignment monitoring system. They estimate 75-94% of agentic Responses API traffic was eligible for monitoring and report flaws: unmonitored compaction events, header-based monitor disabling, serialization mismatches that make the monitor fail, and a Codex sandbox and Auto-Review bypass. The post lists five design ideals for monitoring and control systems; exploit details are redacted.

TL;DR Summarizes a METR and Redwood red-team of OpenAI's internal agent monitor, listing coverage gaps, bypasses and monitoring design recommendations.
Also seen from another angle🧠 AI →
Document

What it is

A METR and Redwood Research pilot red-team of OpenAI's internal asynchronous misalignment monitoring system, run from 21 July to 11 August 2026. One employee from each organisation had access to OpenAI's codebase, monitor prompts and configuration, and internal documentation, and interviewed about a dozen staff. The output was a 61-page internal report. The public post is a brief, high-level subset, and OpenAI could redact anything it judged confidential, without a right for METR to describe the redactions.

Findings that matter beyond the summary

Coverage numbers:

  • 75-94% of agentic internal Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring, with substantial uncertainty in both directions.
  • For the subset of Responses API traffic used by internal Codex agents, 99.2% was eligible.
  • Unmonitored compaction events likely left about 10% of eligible internal Codex traffic unmonitored from May to July 2026. The fraction is uncertain because compaction-triggered monitor calls were not logged. OpenAI found this before the exercise and fixed it during it.
  • RL training runs were not covered at the start. A subset of rollouts was reportedly monitored from March to June.
  • Agents on OpenAI's internal research inference service were not estimated, because of access and time limits.

Why compaction mattered: the monitor fired when an agent returned control to the user. While compaction was unmonitored, an agent could postpone monitoring indefinitely by continuing to act. The authors could not check whether any agent did this.

Reliability figures given to the authors: the monitor errored on under 0.2% of requests, and one 24-hour period had zero load-sheds. The authors report these as information they were shown.

Other vulnerabilities:

  • Two client-controllable headers disable monitoring for new agents. Setting them and spawning the instance could itself be caught by the monitor.
  • Agents could likely craft inputs that make the monitor fail, and so not escalate to human review, by exploiting serialization differences between what the agent sees and what the monitor sees.
  • A Codex sandbox and Auto-Review bypass would let agents take any action the host user could.
  • An exploit, redacted by OpenAI, would stop hundreds of recent actions (including its own) from being monitored.
  • Two unmonitored internal agentic tools thought to be read-only could likely be subverted to take arbitrary actions in their sandboxes. This was not validated.

Confirmed as sound: the monitor sees the full agent trajectory, with a few minor exceptions. Its prompts cover scheming, monitor subversion, sabotage, data exfiltration, deception, and inbound and outbound prompt injection.

What to do

The post's design ideals for anyone building agent monitoring:

  • Make avoidance hard. Require explicit approval for specific organisations or API keys to run unmonitored requests, and bar those from agentic inference. Monitor every N messages or minutes rather than at end of turn.
  • Reconcile accounting. Log all inference and which part is monitored, and cross-check against the monitor's own logs. Keep a list of known bypasses. Make sure the monitor sees the agent's context.
  • Assign clear incident-response ownership, with guidelines that reduce subjectivity and tamper-proof, searchable logs.
  • Red-team regularly with control evaluations, bug searches, and methods for testing strategic collusion.
  • Isolate agents from monitors. Run scaffolds apart from tool execution, keep agent actions from influencing whether or when the monitor runs, and keep monitor design and code away from agents.

Caveats

  • The findings describe the system on and before 21 July 2026, not OpenAI's expanded coverage, which the exercise did not evaluate.
  • The remediation claim was revised on 29 October 2026. OpenAI now says most vulnerabilities are patched and one fix is in progress, and that the remaining one does not affect its misuse safeguards stack. The original text said all vulnerabilities affecting production safeguards were patched. METR has not verified either claim.
  • Exploit details are redacted, and the authors could not check whether agents exploited any of these in practice.

Organisations named here

  • compaction events
  • load shedding
  • Redwood Research

Technologies named here

  • OpenAI
  • Codex
  • GPT-5.5
  • METR
  • Auto-review
  • Codex sandboxing and Auto-Review
  • OpenAI internal asynchronous misalignment monitoring system (as it existed on and before 21 July 2026)
  • OpenAI internal misalignment monitoring system
  • OpenAI RL training runs (not covered by monitoring at the start of the exercise)
  • Responses API

Techniques named here

  • Sandbox escape
  • Control evaluations
  • Disabling monitoring via client-controllable headers
  • Monitor evasion via serialization differences
  • Monitoring coverage estimation
  • Postponing monitoring by not returning control
  • Red-teaming / high-access stress-test exercise
  • Sandbox and read-only permission bypass
  • Unmonitored-action exploit