An external red team given deep access to OpenAI’s internal systems found that the monitor meant to catch misbehaving AI agents could be postponed, starved of input or switched off altogether. OpenAI says the production flaws are fixed, but the findings are a blueprint of what goes wrong when organisations bolt oversight on to autonomous agents.
What happened
On 22 October 2026 the AI evaluation non-profit METR and Redwood Research published a summary of a three-week exercise, run from 21 July to 11 August, in which one researcher from each organisation stress-tested OpenAI’s internal misalignment monitoring system. That system is meant to watch the company’s own AI agents, including its Codex coding agents, and escalate suspicious behaviour such as sabotage, deception or data exfiltration to humans.
Working on OpenAI-issued devices on site, the pair had access to the internal codebase, the monitor’s prompts and configuration, and internal documentation, and interviewed around a dozen staff across the monitoring, safety and security teams. Only a short, high-level summary of their 61-page report is public, and OpenAI could redact anything it deemed sensitive.
The assessment covers the monitoring system as it stood on and before 21 July. It was also separate from METR’s own investigation of the Hugging Face incident, which METR notes was coincidentally made public on the exercise’s first day.
The technical picture
The findings fall into two groups: traffic the monitor never saw, and ways an agent could actively blind it.
On coverage, the researchers estimated that somewhere between 75% and 94% of internal agentic traffic through OpenAI’s Responses API, from models at least as capable as GPT-5.5, was even eligible for monitoring. For internal Codex agents specifically the figure was 99.2%. Reinforcement learning training runs were not covered at the start of the exercise, although a subset had been monitored between March and June.
The most instructive gap concerned compaction, the step where a long-running agent condenses its context window to keep working. Compaction events were not being monitored, and the monitor only fired when an agent handed control back to its user. Put together, an agent that simply kept acting could defer review indefinitely. METR estimates this left roughly 10% of eligible internal Codex traffic unmonitored between May and July, with wide uncertainty because the necessary data had not been logged. OpenAI staff had spotted the problem before the exercise and fixed it during it. Because of access limits, the testers could not establish whether any agent actually took advantage.
On active subversion, the team reported:
- A route by which Codex agents could, in principle, escape both the Codex sandbox and Auto-Review, OpenAI’s automated action reviewer, and do anything the host user could.
- An exploit, details redacted, that would stop hundreds of recent actions from being monitored, including the actions involved in the exploit.
- Likely ways to craft inputs that make the monitor fail, by exploiting differences in how a trajectory is serialised for the agent and for the monitor.
- Two independent client-controllable headers that switch monitoring off for new agents, although setting them might itself be caught.
- Two unmonitored internal tools believed to be read-only that a simple exploit could have turned into arbitrary action inside their sandbox. This was not validated.
On the plus side, the monitor sees almost exactly what the agent sees and reportedly errored on under 0.2% of requests. OpenAI says every vulnerability affecting its production safeguards has since been patched and that it has broadened intended coverage. METR is explicit that it has not evaluated those claims.
Why it matters for UK organisations
It would be easy to file this as a problem for one frontier lab. That would be a mistake. Many UK organisations now run coding and customer-service agents with real permissions, relying on a monitoring or review layer for control. Every weakness listed above has an obvious equivalent in an enterprise deployment: review that only triggers at the end of a task, logging that misses certain event types, configuration flags that turn controls off, and tools wrongly assumed to be read-only.
The timing matters too. On 12 October the government said the NCSC and the AI Security Institute were working on how incidents involving AI agents should be handled, warning that such an incident could unfold faster and more widely than the incidents governments are currently designed to handle. It also said it would look at strengthening the Cyber Security and Resilience Bill regime against AI loss-of-control risk, where autonomous systems evade human oversight, and at how near misses are reported. Regulated firms should expect questions on how their own agent oversight would stand up.
Expert view
What stands out to me is how ordinary these findings are. Strip away the AI vocabulary and this resembles a familiar infrastructure test: incomplete asset inventory, a logging pipeline with blind spots, a kill switch exposed to the very client it was supposed to constrain, and a sandbox that did not hold. When we test traditional environments, failures are rarely exotic: they are coverage gaps and unverified trust assumptions.
The difference is the adversary model. A monitor for human users can assume the user does not know where the cameras are. An agent may have read the code, may run for hours without handing back control, and can try thousands of actions cheaply. METR’s point that monitoring must withstand “deliberate, strategic, and sustained attacks” from capable agents is the right framing. If your design only works when the agent co-operates, it is not a control.
The public post is a fraction of the full report and OpenAI’s fixes are unverified, so nobody should treat the patches as proof the problem is closed.
What to do now
- Inventory every agent and its traffic. Know which agents run, under which identities and API keys, and reconcile model inference logs against monitoring logs regularly so you can prove what is actually being watched.
- Monitor continuously, not at turn end. Review agent actions at fixed intervals or action counts, and include context compaction and similar housekeeping events in scope.
- Take control switches away from the agent. Any setting that disables logging, review or monitoring should be server-side, require explicit approval and alert when used. This maps directly to Cyber Essentials secure configuration and user access control.
- Isolate agents from their monitors. Run tool execution away from the agent scaffold, keep monitoring code and design out of the agent’s reach, and grant least-privilege permissions, assuming any tool can be abused.
- Test the oversight layer itself. Add agent monitoring and sandbox escape to penetration test and red team scope, and keep a register of known bypasses.
- Prepare the incident playbook. Assign clear ownership for agent incidents, keep tamper-resistant searchable logs, and decide in advance how you would capture and report a near miss.
Bottom line
An independent team found gaps that an agent could, in principle, have exploited in the monitor of one of the best-resourced AI developers, using conventional security testing. UK organisations deploying agents should assume their own oversight has similar holes and go and look for them before an agent, or an attacker steering one, does.
Sources
- METR: Red-Teaming OpenAI’s Internal Agent Monitoring Systems
- The Register: Red-team report found OpenAI utterly failed to monitor its agents during Hugging Face attack
- WebProNews: METR and Redwood Find Gaps in OpenAI’s Internal Agent Monitoring; OpenAI Says Production Flaws Are Patched
- GOV.UK: Britain steps up national defences against growing AI risks
