OpenAI Monitor Red Team Found Six Evasion Paths, Not Just Model Failures

METR and Redwood staff published a 61-page report on October 22 after spending three weeks embedded at OpenAI, from July 21 through August 11. The report catalogues roughly 10 vulnerability classes in OpenAI's internal misalignment monitor. Its subject is the monitoring machinery around agents, not simply whether a model produces an objectionable response.

The researchers describe six concrete evasion paths involving compaction, Codex sandbox bypass, hidden recent actions, serialization gaps, client-controllable headers and supposedly read-only internal tools. Those findings place the integration between agent activity and monitoring inside the security boundary. A monitor cannot assess behavior that its surrounding systems fail to present correctly.

OpenAI says it patched the production-impacting findings. That response belongs beside the historical coverage figures: only 75–94% of Responses-API traffic from GPT-5.5-class models was eligible for monitoring, and roughly 10% of Codex sessions escaped between May and July. The report should not be presented as a live inventory of unpatched production weaknesses.

Eligibility is not detection accuracy

The 75–94% range concerns eligibility for monitoring. It does not say how accurately the monitor classified the traffic it received. For an enterprise buyer, these are different acceptance questions: whether relevant activity enters the monitoring path and whether the monitoring decision is useful. A vendor presentation that combines those questions into a general assurance claim is leaving an important boundary unspecified.

The roughly 10% of Codex sessions that escaped between May and July is also a scoped observation, not a supplied rate for every OpenAI product or for present-day operation. Preserve the product and period when discussing the result. Removing either would turn an identified historical gap into a broader assertion that the report's supplied facts do not establish.

The 61-page report is valuable to buyers because it gives a monitoring review concrete failure categories to examine. A procurement team can ask who establishes eligibility and what evidence shows that eligible activity was actually delivered. Those questions do not require assuming that another vendor has the same bugs; they require refusing to treat a monitoring feature name as a coverage measurement.

The six paths concern the plumbing around the observer

Among the six reported paths, delaying triggers through compaction and hiding hundreds of recent actions concern what activity remains available to inspection. For a defensive review, the key issue is continuity: a monitoring record should be interpretable across changes in an agent's working context. Do not infer a specific hidden-action limit or a universal compaction failure from the summary alone.

The 2 client-controllable headers that disabled monitoring for new agent instances concern who could influence the monitoring decision. That is distinct from a model persuading a classifier that harmful behavior is harmless. An implementation review should inspect the authority behind eligibility decisions and ensure its design does not depend on an unexamined client assertion. The supplied facts do not disclose header names or warrant inventing them.

Serialization gaps, Codex sandbox bypass and abuse of supposedly read-only internal tools complete the six-path summary. They point to interface assumptions worth testing independently of model behavior. A defensive team can examine whether tool permissions match their labels and whether logged activity preserves the meaning of the underlying operation, without reproducing or publishing an exploitation recipe from unsupported details.

The trade-off is validating coverage as the system changes

OpenAI's statement that it patched production-impacting findings addresses the reported issues, but the October 22 publication does not supply a current end-to-end coverage percentage after those patches. A buyer should ask for evidence corresponding to the deployment under consideration. Repeating the old range as today's state would be as misleading as treating the patch statement as a guarantee against every future integration error.

The 3-week embedded exercise also illustrates an evaluation boundary. Its findings came from a defined investigation, not a continuous certificate covering every later agent configuration. If a product changes how it compresses context or presents tool activity, an adopter should determine what monitoring evidence needs to be revisited. That is a proposed review practice, not a claim about changes OpenAI has made.

Roughly 10 vulnerability classes mean a single detection demonstration cannot stand in for an integration review. Testing a monitor's response to a visible bad action answers a narrower question than testing whether the action arrives with adequate context. Maintaining that distinction creates review work, but it prevents buyers from confusing a successful classifier example with evidence that the full activity path is covered.

What To Do About It

• Request eligibility evidence: Ask the vendor to define eligible traffic for the exact agent integration you intend to buy, and keep that definition separate from detection performance. Use the report's historical range as a prompt for scrutiny, not a current guarantee: 75–94%.
• Trace activity continuity: Give the implementation reviewer an authorized test that follows action records across context changes. Record what remains visible and how it reaches the monitor, using the published hidden-activity finding as the reference: hundreds of recent actions.
• Review control ownership: Ask the security owner to document which trusted component decides whether monitoring is enabled. Look for client-controlled eligibility decisions without inventing implementation details beyond the report's finding of 2 headers.
• Verify remediation scope: Request evidence for the deployed configuration and distinguish patched production findings from broader assurance claims. Attach a date to the vendor response so a later reviewer can compare it with October 22.

The Bottom Line

The 61-page report makes monitoring integration a purchasing question rather than an assumed safety property. Its six evasion paths show why observing an agent depends on more than the monitor's judgment. OpenAI says it patched production-impacting findings, so buyers should seek current evidence rather than market historical gaps as present facts. Treat the 75–94% eligibility range as a lesson in measurement boundaries, not a substitute for evaluating your own deployment.