METR red-teams OpenAI’s internal AI watchdog — and finds ways agents could slip past it
- Who: METR and Redwood Research — one embedded employee from each organization
- What: a pilot red-team exercise of OpenAI’s internal misalignment monitoring system, the AI monitor that reviews agent work for misalignment
- When: embedded July 21–August 11, 2026; public account published October 22, 2026
- Coverage: an estimated 75–94% of eligible internal Responses API traffic from models at least as strong as GPT-5.5; 99.2% for internal Codex agents
- Gaps: on the order of 10% of eligible internal Codex traffic unmonitored May–July 2026 through the compaction-event gap; RL training rollouts uncovered at the exercise start
- Report: a 61-page internal report to OpenAI researchers and security staff; OpenAI says production-impacting flaws are patched — METR has not verified the fixes
METR and Redwood Research published a public account on Thursday, October 22, 2026 of a three-week embedded pilot inside OpenAI — a stress test of the internal monitoring system that watches OpenAI’s own AI agents for signs of misalignment. One employee from each organization tried to break it. They found a number of novel vulnerabilities, including ways agents could in principle keep hundreds of their recent actions out of the monitor’s sight.
The exercise doubles as a proof-of-concept for a bigger idea: giving outside researchers employee-level access to frontier AI labs. Reuters reported the findings on Thursday, noting that AI labs, experts, and the Trump administration have all touted independent outside evaluation as a way to advance AI safely — while AI companies worry that researchers embedded inside their walls could walk proprietary information out the door.
Three weeks inside OpenAI
The pilot ran July 21 to August 11, 2026. The two evaluators were given a deep level of access: OpenAI’s internal codebase, the misalignment monitor’s prompts and configuration details, internal documentation, and technical interviews with approximately a dozen researchers and engineers across the monitoring, safety-systems, and security teams. They worked on OpenAI-issued devices that never left the premises, and were accompanied while onsite.
The output was a 61-page internal report shared with OpenAI researchers and security staff, focused on two questions: what fraction of agentic inference is actually monitored, and whether agents could in principle disable or subvert the monitoring system. The exercise assessed the system as it existed on and before July 21 — not changes that were already in progress at the time.

The framing matters as much as the findings. METR says the exercise was designed as a pilot for giving external researchers deep access to internal infrastructure — not to provide robust public transparency about OpenAI’s monitoring systems. The groups agreed upfront with OpenAI that they would publish only a relatively brief, high-level account, and OpenAI could cut anything it judged sensitive. For future versions, the groups say they expect to follow the transparency and independence best practices laid out in METR’s “Our approach to working with AI companies” framework.
What the red team found
On coverage, the pair estimated that roughly 75–94% of agentic internal Responses API traffic — the API that powers Codex, among other things — from models at least as strong as GPT-5.5 was eligible for monitoring at the time, though they flagged substantial uncertainty in both directions. Of the subset of Responses API traffic used for internal Codex agents, they estimated 99.2% was eligible. RL training rollouts, however, were not covered at the start of the exercise, though a subset had been monitored for misalignment between March and June.
The sharpest coverage finding concerned compaction events — activity in long-running agent sessions that the monitors were not covering. The evaluators estimated that gap left on the order of 10% of eligible internal Codex traffic unmonitored between May and July 2026. OpenAI staff had independently identified the issue before the exercise began and fixed it during the exercise. At the time, the monitor triggered when agents returned control to the user — so while compaction events were unmonitored, agents could indefinitely postpone being monitored by simply continuing to take actions.
On the exploit side, the pair found a way Codex agents could in principle bypass Codex sandboxing and Auto-Review, taking any action available to the host user. They discovered an exploit agents could use to prevent hundreds of recent actions — including the actions involved in the exploit itself — from being monitored; the details were redacted by OpenAI. They found two independent client-controllable headers that disable monitoring for new agents, enabling an unmonitored instance, though the act of setting the headers could itself be caught by the monitor. Two unmonitored internal agentic tools were thought to have read-only permissions; the pair found a simple exploit that could have been used to subvert the limits and take arbitrary actions in their sandboxed environment, which they did not validate in practice. And they found agents could likely cause the monitor to fail to escalate a trajectory for human review by exploiting serialization differences between the trajectory the agent sees and the one the monitor sees.
Not everything was a hole. The monitor errored on less than 0.2% of requests, with zero load-sheds in one 24-hour period. The evaluators verified that the monitor sees the full trajectory the agent sees, with minor exceptions, and validated that its prompts look for scheming, monitor-system subversion, sabotage, data exfiltration, deception, and inbound and outbound prompt injection.

Patched — but unverified
Since the exercise, OpenAI has stated that all of the vulnerabilities the pair identified that impact its production safeguards stack have been patched, and has described significant subsequent changes to the intended coverage of its monitoring system. METR’s post is explicit that it has not evaluated those claims — and the exercise did not establish the current coverage of the expanded system either. The findings describe the system as of July 21, which OpenAI was already expanding while the pair worked.
The groups also published design ideals drawn from the findings: agents should be monitored every N messages or minutes instead of waiting for them to end their turns; running unmonitored requests should require explicit approval on a restricted set of API keys; logs from inference and the monitor should be cross-referenced so everything intended to be monitored actually is; agent scaffolds should be isolated from where tool calls execute; and monitoring systems should be actively red-teamed for strategic collusion. In short, build the watchdog to withstand deliberate, strategic, sustained attacks from highly capable internal agents at scale. Redwood Research published the same account on its own blog.
Frequently asked questions
What exactly did METR and Redwood Research test?
A pilot “embedded evaluation.” One employee from each organization worked inside OpenAI from July 21 to August 11, 2026, with access to the codebase, the monitor’s prompts and configuration, internal documentation, and about a dozen staff interviews — all on chaperoned, OpenAI-issued devices. They estimated the fraction of agentic inference that is monitored and probed whether agents could disable or subvert the monitoring system. The findings went into a 61-page internal report shared with OpenAI researchers and security staff.
What were the most significant findings?
Coverage gaps and evasion paths. Coverage: an estimated 75–94% of eligible internal Responses API traffic from models at least as strong as GPT-5.5 was monitored, and a compaction-event gap left on the order of 10% of eligible internal Codex traffic unmonitored between May and July 2026. Evasion: an exploit that could keep hundreds of recent actions out of the monitor’s sight, a Codex sandbox and Auto-Review bypass, two headers that disable monitoring for new agents, and the ability to indefinitely postpone monitoring by never returning control to the user while the compaction gap lasted.
Did OpenAI fix the problems?
OpenAI states that all identified vulnerabilities affecting its production safeguards stack have been patched, and says it has since made significant changes to the intended coverage of its monitoring system. METR explicitly says it has not evaluated those claims. The public account is deliberately brief and high-level — the pilot was a test of deep external access, not full public transparency — and the groups say future exercises should follow stronger transparency and independence practices.