OpenAI's agent monitor worked. Much of the traffic never reached it.

Outside reviewers spent three weeks inside OpenAI's agent monitoring. The biggest gaps were in what the monitor was never shown, the way TD Bank never monitored 92% of its volume.

Share
A man sitting in front of several computer monitors
Illustrative, not OpenAI. Photo by Tasha Kostyuk on Unsplash

On 22 October 2026, Redwood Research and METR published a short account of three weeks that two of their staff spent inside OpenAI this summer, testing the system OpenAI uses to watch its own coding agents for misbehaviour. The headlines went to the exploits. The finding I keep coming back to is plainer: a real share of agent activity never reached the monitor at all.

So, did OpenAI's agent monitor watch its agents? Partly. The reviewers estimated that only about 75 to 94% of OpenAI's internal agent traffic on the Responses API, from models at least as strong as GPT-5.5, was even eligible for monitoring. Inside the eligible part, one unmonitored event type likely left about 10% of internal Codex traffic unwatched from May to July 2026. OpenAI says the flaws that touch production are patched. The reviewers say, in so many words, "We have not evaluated these claims."

What did METR and Redwood Research actually find?

One employee from each organisation worked on site at OpenAI from 21 July to 11 August, on OpenAI devices that never left the building, with access to the internal codebase, the monitor's prompts and configuration, and about a dozen people across the monitoring, safety and security teams. They wrote a 61-page internal report. The public post is brief by agreement, and OpenAI could redact it.

The monitor itself is asynchronous. It reads agent conversations on OpenAI's internal Responses API, which powers Codex, and looks for scheming, sabotage, data exfiltration, deception, prompt injection and attempts to subvert the monitor. The gaps the reviewers describe are mostly about what got to it:

  • The monitor fired when an agent returned control to the user. An agent that simply kept working could put off being checked indefinitely.
  • Context compaction events, when an agent squeezes its history to keep going, were not monitored. That is the roughly 10% of eligible Codex traffic. OpenAI had found this before the exercise and fixed it during.
  • Reinforcement learning training runs were not covered when the exercise began.
  • Two client-controllable headers could switch monitoring off for new agents, though setting them would likely be caught.
  • A redacted exploit could keep hundreds of recent actions, including its own, out of the monitor's view.

There were also ways to break things once traffic did arrive: a path around Codex sandboxing and Auto-Review, and differences between what the agent sees and what the monitor sees that could make the monitor fail on purpose-built input. But look at what the post never gives: a catch rate. Every number in it is about coverage.

3 weekson site at OpenAI, 21 Jul to 11 Aug 2026
75 to 94%of GPT-5.5-class internal agent traffic eligible for the monitor
about 10%of eligible internal Codex traffic unmonitored, May to July (compaction)
under 0.1%outside coverage, in OpenAI's own March 2026 account

Sources: Redwood Research and METR, 22 Oct 2026; OpenAI, 19 Mar 2026. The two percentages use different populations.

Didn't OpenAI say the monitor covered almost everything?

It did. In March, OpenAI wrote that its monitor "privately runs across all standard internal coding agent deployments" and that under 0.1% of traffic, mostly bespoke or local setups, fell outside it. Over five months it had read tens of millions of agent trajectories, raised about 1,000 moderate alerts and none at the highest level.

My first reaction was that the two accounts contradict each other. Checking the wording, they don't, quite. OpenAI's 0.1% is a share of "standard internal coding agent deployments". The reviewers' 75 to 94% is a share of all agent traffic on the internal Responses API from GPT-5.5-class models, which includes work that isn't a standard Codex deployment. For the Codex subset alone they found 99.2% eligible. And eligible is not the same as watched: the compaction gap sat inside the eligible traffic.

So both numbers can be true at once. That bothers me more than either number. The March figure read like an answer to "how much do you watch?" when it was an answer to a narrower question, and the 1,000 alerts tell you how the monitor behaved on the slice it saw, not how big the slice was.

Where have I seen a monitor that only saw part of the traffic?

In banking, at a scale that makes this look small.

TD Bank ran a transaction monitoring system for years. Roughly what share of its transaction volume, January 2018 to April 2024, never went through it?

92%, about $18.3 trillion of transactions, according to the US Department of Justice (10 Oct 2024).

A cash machine set into the front of a building
A cash machine; illustrative, not one of CBA's deposit machines. Photo by Andrew Valdivia on Unsplash

On 10 October 2024 the US Department of Justice announced TD Bank's guilty plea and a penalty of about $1.89 billion. The bank's monitoring did not fail by raising bad alerts. It failed by never being shown most of the money: "92% of total transaction volume going unmonitored from Jan. 1, 2018, to April 12, 2024", about $18.3 trillion. From 2014 through 2022 its monitoring program "remained effectively static". It added no new scenarios, and it launched new products, "like Zelle, without ensuring appropriate transaction monitoring coverage".

Australia's Commonwealth Bank had the same shape. AUSTRAC's $700 million settlement in 2018 covered 53,506 late reports on cash deposits of $10,000 or more through its intelligent deposit machines between November 2012 and September 2015, and three years in which it did not "monitor transactions" on 778,370 accounts.

Same failure, two industries

TD Bank, 2014 to 2024

  • Monitor transaction monitoring scenarios, left "effectively static" 2014 to 2022
  • What never reached it 92% of transaction volume, 2018 to 2024
  • How the gap opened new products such as Zelle launched without monitoring coverage
  • Found by US regulators and prosecutors, years later

OpenAI agent monitor, 2026

  • Monitor asynchronous misalignment monitor on internal Responses API traffic
  • What never reached it 6 to 25% of GPT-5.5-class agent traffic not eligible; about 10% of eligible Codex traffic during compaction
  • How the gap opened new agent behaviour (compaction, long runs without returning control) not routed to the monitor
  • Found by an embedded outside red team, within months

Sources: US Department of Justice, 10 Oct 2024; Redwood Research and METR, 22 Oct 2026.

Chart: OpenAI internal agent traffic from GPT-5.5-class models, 75 to 94% eligible for its monitor in July 2026; TD Bank transaction volume January 2018 to April 2024, 92% never monitored, about $18.3 trillion
What a monitor never sees. Sources: Redwood Research and METR, 22 Oct 2026; US Department of Justice, 10 Oct 2024.

Zelle and compaction are the same kind of event. Something new gets added to the system, it works, people use it, and nobody routes it through the thing that is supposed to be watching. The monitor goes on reporting healthy alert numbers, because from where it sits nothing is missing.

Is this just OpenAI?

No. In March METR ran the same kind of three-week exercise with Anthropic. Among the routes it found: an environment variable change that made agent traffic look as if it didn't come from Claude Code, and a bug that left subagent calls unmonitored, fixed within 24 hours. Different lab, same pattern: a new way for work to happen, and the monitor not on that path.

I find this more reassuring than the headlines suggest, in one way. Both labs let outsiders in with real access, and both times the outsiders found plumbing problems that can be fixed. It is less reassuring in another way. Agent products keep adding new paths for work to take, like subagents, compaction and new tools. Each one is a Zelle.

"Make it hard to avoid being monitored."

Buck Shlegeris, Redwood Research, 22 Oct 2026, one of the report's design recommendations

What should you ask of an agent monitor, yours or a lab's?

My own view, marked as mine: ask for coverage before you ask for catches, and measure it from outside the monitor. Count every agent action where it happens, at the gateway or in the billing logs, and compare that with what the monitor actually received. The reviewers say much the same in their own recommendations: make it hard to avoid being monitored, check that intended traffic really is monitored, red-team monitors regularly, and keep agents isolated from their monitors.

If you run agents yourself, the practical version is short. List every path an agent's actions can take, including the new ones from last month's release. For each, ask one question: does the monitor see this? Then check the answer against a count you didn't get from the monitor.

This connects to two earlier pieces. In September, OpenAI's own timeline showed a fast alert and a slow kill. In October, METR showed an agent could change what its reviewer saw. One was about how fast people acted on an alert, the other about whether the record could be trusted. This one comes before both: whether the work reached the monitor at all.

What I don't know is whether any agent used these gaps. The reviewers couldn't check that either.

The claim, in one sentence

An agent monitor's alert counts mean little until someone outside it counts the traffic that never reached it, so coverage, checked at the source, is the first number to ask for.

How sure am I?

Established
The findings and figures from Redwood Research and METR (22 Oct 2026), OpenAI's March 2026 figures, METR's March findings at Anthropic, the TD Bank figures from the DOJ and the CBA figures from AUSTRAC.
Inferred
That OpenAI's March 0.1% and the reviewers' 75 to 94% measure different populations, so they don't contradict each other; and that the compaction gap is the same kind of failure as TD Bank's Zelle gap.
Guess
That coverage gaps, not weak detection, will turn out to be the common failure in agent monitoring. Two exercises at two labs is not yet a pattern.

More on Daily Ferment: An AI agent could change what its reviewer saw and Nvidia sandboxes each agent. The breach went between them..

Sources