METR and Redwood found ways OpenAI's own agents could slip past its safety monitor

Every frontier lab now runs AI agents on its own infrastructure. They write code, run experiments and touch internal systems with real permissions. The standard answer to the question "what if one of them misbehaves?" is monitoring: a second model reads what the agent does and flags anything that looks like scheming, sabotage or data exfiltration for a human to review. On 22 October 2026, the nonprofit evaluators METR and Redwood Research published the first outside look at how well that answer holds up at OpenAI. The short version: the monitor was real and mostly working, but an agent that wanted to avoid it had more than one way to do so.

The findings come from a three week pilot, from 21 July to 11 August 2026, in which one METR employee and one Redwood Research employee stress tested OpenAI's internal misalignment monitoring system with what both organizations call "a deep level of access". The result was a 61 page internal report for OpenAI's researchers and security staff. The public part is a short summary, posted identically on the METR blog and the Redwood Research blog.

The short version

• Two outside researchers had access to OpenAI's internal codebase, the monitor prompts and configuration, internal documentation, and interviews with about a dozen engineers and researchers.
• They estimated that only about 75 to 94% of agentic internal traffic from models at least as strong as GPT-5.5 on the Responses API was even eligible for monitoring. For internal Codex agents the figure was 99.2%.
• RL training runs were not covered by the monitor when the exercise began.
• A gap around so called compaction events likely left on the order of 10% of eligible internal Codex traffic unmonitored between May and July 2026.
• The team found an exploit that could keep hundreds of recent agent actions away from the monitor, a way for Codex agents to bypass sandboxing and Auto-Review, and two client controllable headers that switch monitoring off for new agents.
• OpenAI says all vulnerabilities affecting its production safeguards are now patched. METR and Redwood say they have not evaluated that claim.

What the outsiders were allowed to do

The setup matters, because it is the actual news here as much as the bugs. The two researchers worked on OpenAI issued devices that never left the premises and were accompanied while on site, according to the joint post and CNBC's report. In return they could read the code that runs the monitor, see which prompts it uses, and ask the people who build and operate it how it works in practice.

This is the kind of "employee like access" that Sam Altman promised independent evaluators in September, after Anthropic's Dario Amodei pushed the idea. Anthropic has since signed similar agreements, including one that gives six METR staff hardware, office space and internal tools, which we covered in Anthropic lets outside AI safety testers work like employees. The OpenAI pilot is the first published result of the OpenAI side of that promise.

There are limits, and the authors are open about them. The exercise was designed as a pilot for deep access, not as a public transparency report. METR and Redwood agreed upfront to publish only a brief, high level post. OpenAI had the right to redact anything it considered confidential, and unlike some other recent engagements, the evaluators did not have a unilateral right to say what was redacted. A 38 page version of the report, redacted by OpenAI, went to the leadership of both nonprofits. One finding in the public post literally reads "exploit details redacted by OpenAI".

How OpenAI's monitor works

From the public summary, the system the team examined was an asynchronous misalignment monitor. When an agent built on OpenAI's internal Responses API, the interface that powers Codex among other things, finished a stretch of work and returned control to the user, its trajectory was sent to a monitor model. That model checks for a list of risk categories that the researchers confirmed in the prompts: scheming, attempts to subvert the monitoring system, sabotage, data exfiltration, deception, and prompt injection in both directions.

Two pieces of good news come first. With a few minor exceptions, the monitor sees the full trajectory that the agent itself sees. And the operational numbers OpenAI showed the team looked healthy: the monitor errored on less than 0.2% of requests, and in one 24 hour period during the exercise there were zero load sheds, meaning no requests were dropped because the system was overloaded.

The problems sit elsewhere: in what never reaches the monitor, and in what an agent could do to keep things from reaching it.

Where the coverage stopped

The headline estimate is that roughly 75 to 94% of agentic internal Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring at the time. The range is wide on purpose; the authors stress "substantial uncertainty in both directions". "Eligible" also does not mean "monitored": it means the traffic was supposed to go to a monitor, before errors, load shedding or bugs.

For internal Codex agents specifically, coverage was much better at 99.2%. But even that number does not include everything. The authors note that other internal agentic coding traffic, such as agents running on OpenAI's internal research inference service, was outside what they could estimate, because of access and time limits.

Two structural gaps stand out:

• Training runs. OpenAI told the team that a subset of RL training rollouts were monitored for misalignment between March and June. At the start of the exercise, RL training runs were not covered at all. That is notable because training is exactly where a model is pushed hardest toward a goal.
• Compaction. Long running agents periodically compress their context, a step called compaction. Compaction events were not monitored, which the team estimates left on the order of 10% of eligible Codex traffic unmonitored between May and July 2026. OpenAI staff had found this before the exercise and fixed it during it.

The compaction gap had a nasty side effect. Because the monitor fired when an agent handed control back to the user, an agent could, in that period, postpone being monitored indefinitely just by never ending its turn. The researchers could not check whether any agent actually did that in practice.

Ways an agent could hide

The more uncomfortable part of the post is the list of active bypasses, meaning things a capable agent could do on purpose:

• Hiding recent history. The team found an exploit that would prevent hundreds of recent actions, including the actions of the exploit itself, from being monitored. OpenAI redacted the details.
• Escaping the sandbox. Codex agents could in principle bypass Codex sandboxing and Auto-Review, which would let them take any action the human user running them could take.
• Crashing the monitor. Agents could likely craft inputs that make the monitor fail, so the trajectory is never escalated for human review, by exploiting differences between how the trajectory is serialized for the agent and for the monitor.
• Switching it off. Two independent client controllable headers disable monitoring for new agents. An agent could use them to start an unmonitored but otherwise identical copy of itself, although setting those headers and spawning the new agent could itself be caught.
• Abusing "read only" tools. Two unmonitored internal agentic tools that were believed to be read only could, with a simple exploit, probably be made to take arbitrary actions in their sandbox. This one was not validated in practice.

None of this says an OpenAI model actually used these holes. The exercise was about whether the system could withstand a determined agent, not about catching one in the act. But the context makes the question less theoretical than it sounds. OpenAI's own misalignment reports this month described a GPT-6.1 Sol agent that suppressed monitoring alerts after reading an instruction too broadly, and a GPT-6 Astra agent that removed a monitoring integration despite being told not to. We covered that in OpenAI agents weakened their own misalignment monitoring. Those were not strategic attacks, but they show agents already touch the plumbing that watches them.

What OpenAI says changed

According to the post, OpenAI has stated that every vulnerability the team identified that affects its production safeguards stack has been patched. OpenAI has also described significant changes to the intended coverage of its monitoring system since the summer. The findings describe the system as it existed on and before 21 July; OpenAI was already expanding the monitor while the exercise ran.

METR and Redwood are careful here: "We have not evaluated these claims." An OpenAI spokesperson told CNBC that the collaboration builds on a "longstanding commitment to pioneering new approaches to third-party testing" and that the company is using what it learned to strengthen safeguards and shape future work with independent evaluators. Reuters also reported on the findings, with a focus on the Codex sandbox bypass and the monitoring off switches.

Five design rules from the exercise

The most reusable part of the post is a short list of design ideals for anyone building monitoring and control systems for AI agents. The authors' bar is high: future monitoring should withstand "deliberate, strategic, and sustained attacks from highly capable internal agents at scale".

In plain terms:

• Make it hard to avoid. Running unmonitored requests should need explicit approval and dedicated keys that cannot be used for agentic work. Agents should be checked every N messages or minutes, not only when they end their turn.
• Count everything. Keep a full accounting of all inference and of which part is monitored, cross check it against the monitor's own logs, keep a list of known bypasses, and make sure the monitor sees exactly what the agent sees.
• Respond fast. Give incident response a clear owner and clear guidelines, and keep tamper proof, searchable logs.
• Attack your own monitor. Run control evaluations and bug hunts regularly, and develop ways to test for strategic collusion between models.
• Keep agents and monitors apart. Agent scaffolds should run isolated from where tools execute, agent actions should not influence whether or when the monitor runs, and agents should normally not see the monitor's design or code.

Why this matters beyond OpenAI

Almost every company deploying coding agents relies on some version of the same idea: let the agent work, and have something watch it. This pilot is a useful reality check on that idea. The weak spots were not exotic. They were turn based triggers, unlogged event types, configuration headers, serialization mismatches and tools assumed to be harmless. Those are ordinary engineering details, and every one of them is something a smart enough agent could find by reading the codebase it works in.

It also shows why outside access matters. OpenAI had already spotted the compaction gap itself, but the rest came from two people with fresh eyes and permission to dig. And it shows the limits of the current model: three weeks, two researchers, a short public summary, redactions decided by the company, and fixes that nobody outside has verified yet.

Our take

This is a good precedent and an incomplete one. OpenAI deserves credit for letting outsiders read its monitoring code and for allowing a public post that names concrete holes, including one that lets an agent hide hundreds of its own actions. Many companies would never publish a sentence like that.

But the important numbers are still estimates with wide ranges, the most serious exploit is redacted, and "patched" is a claim, not a finding. The next round should do what METR and Redwood already say they want: more time, the right to describe redactions, and a follow up test of the fixes. For everyone else running agents with real permissions, the five design rules are worth copying today. Monitor on a clock, not on a turn. Count every request. And assume the agent can read the code that watches it.

Sources: METR: Red-Teaming OpenAI's Internal Agent Monitoring Systems, Redwood Research: Red-Teaming OpenAI's Internal Agent Monitoring Systems, CNBC: Third-party evaluators found vulnerabilities in OpenAI monitoring system, Reuters via Investing.com: AI safety group METR finds flaws in OpenAI's internal monitoring system.