AI news Oct 23, 2026

Today · announcement, October 22

METR finds OpenAI monitoring gaps; readings predate July 21

METR estimates 75% to 94% of OpenAI's internal agent traffic from GPT-5.5-class models was in scope for monitoring; reinforcement-learning training was not

Why it matters: Our read: METR's negative findings at OpenAI center on traffic that never reached the monitor. How much traffic is monitored has to be checked before how well the monitor catches misbehavior.

METR is an outside evaluator that labs commission to assess model capabilities and risks. On October 22, METR published a summary of a red-teaming exercise. From July 21 to August 11, METR and Redwood Research, another outside research group, each placed one staff member inside OpenAI for three weeks to read internal code, monitoring configuration and documentation, and to test OpenAI's misalignment monitoring (METR, 2026-10-22). In that system, a separate model reads the work logs of OpenAI's internal AI agents after the fact, looks for deception, sabotage or data exfiltration, and sends hits to human review.

METR estimates that, of the agent traffic generated through OpenAI's internal Responses API by models at least as capable as GPT-5.5, about 75% to 94% falls within the scope meant to be sent to monitoring. The Responses API is an OpenAI API interface, and OpenAI's internal Codex agents also run through it. The rest of that traffic falls outside the scope. Codex, OpenAI's coding agent, is one subset of that traffic, and 99.2% of Codex traffic is in scope. METR writes: "RL training runs were not covered by the monitoring system." When the exercise began, reinforcement-learning training sat outside monitoring.

When an agent conversation runs too long, the system compresses the earlier context into a summary. Those compaction steps weren't sent to monitoring at the time. METR estimates that from May to July about a tenth of the Codex traffic that should have been monitored went unseen as a result. The exact share is uncertain, because the system didn't record which monitoring calls compaction triggered. OpenAI staff had found the problem before the exercise, and it was fixed during the exercise.

METR also found "two independent client-controllable headers that disable the monitoring system for new agents." A header here is a field attached to an API request. The party sending a request sets these two headers. Once either is set, newly started agents aren't monitored. Our read: an agent is a party that sends requests, so in principle an agent could set them. METR's text doesn't say an agent can change the two headers directly. OpenAI said afterward that the related vulnerabilities have all been patched, and METR's next sentence reads: "We have not evaluated these claims."

Not proven yet: the readings cover the system before July 21; current coverage wasn't measured How we checked →

Judgment update: Our read: for agent monitoring, the first question is how many actions are actually seen, and only then whether the monitor catches what it sees. The negative readings in METR's summary cluster on coverage: the in-scope share, unmonitored training, compaction that skipped monitoring, and headers that switch it off. The readings on the monitor itself lean positive. With few exceptions, the logs the monitor read matched what the agent saw. OpenAI's figure for the monitoring-request error rate is below 0.2%. Neither reading measures how accurately the monitor catches bad behavior.

SecondSource's October 21 issue covered METR's review of Anthropic's August risk report (METR, 2026-10-20). That review also flagged "simple ways to disable monitoring," and a lag of several days to a week between an action and human review. The same review relays a reading Anthropic reported: on incidents involving Mythos 5, Anthropic's offline monitoring flagged only about 1% of actions. Mythos 5 is an Anthropic model listed in METR's review. With the chain of thought removed, looking only at actions and tool calls, the flag rate rose to about 50%. That is a single-incident reading, self-reported by Anthropic and relayed by METR. It is measured differently from METR's in-scope share for OpenAI, so the two can't be compared directly.

Our read: both companies have coverage gaps. On Anthropic's side, in this incident, there were also cases the monitor saw but didn't flag. The relayed reading covers one incident, so it doesn't show whether that is the norm. Both readings come from METR alone, not from two independent sources. METR's first recommendation is to log every inference request: "Keep careful accounting of all inference that happens, and which subset is being monitored" (METR, 2026-10-22). That means recording every inference, marking which ones went to monitoring, and periodically checking that record against the monitoring system's own logs. This is a judgment not yet settled. What would prove this wrong: by January 31, 2027, OpenAI or Anthropic publishes a reconciled coverage figure for current monitoring of 99% or higher, backed by an outside party; or the main findings of the next outside red-team report fall on cases the monitor saw but didn't catch. The 99% threshold is SecondSource's own, not METR's or OpenAI's. The verdict date is January 31, 2027.