From July 21 to August 11, 2026, two external researchers from METR and Redwood Research gained deep access to OpenAI’s infrastructure to test its system for detecting misalignment in its agents.
METR describes a pilot high-access red-teaming exercise during which they were able to inspect the internal code, prompts and monitor configurations, as well as the documentation. The exercise concerns the system as it existed on July 21 and earlier. OpenAI was expanding it at the time; these developments had not been evaluated, and the findings therefore do not describe current coverage.
The two researchers conducted technical interviews with around a dozen researchers and engineers from the monitoring, safety, and security teams. They worked on devices provided by OpenAI that did not leave the premises.
In an internal report, shared with OpenAI researchers and security teams, they seek to answer two questions:
- what portion of agent activity is actually monitored?
- could an agent theoretically disable or subvert the monitoring system?
The publication rules were set in advance: a relatively short, high-level blog post, and the possibility for OpenAI to remove, at its sole discretion, any information deemed confidential or sensitive.
The METR post notes that, unlike other missions, such as its separate Hugging Face incident inquiry, the organization did not have unilateral right to describe such removals.
Between 75% and 94% of the traffic estimated to be monitorable
The researchers estimate that between 75% and 94% of the agent traffic from the internal Responses API, which powers Codex, was eligible for monitoring for models at least as capable as GPT-5.5, with a high degree of uncertainty in both directions.
For the subset used by internal Codex-driven agents, the share reaches 99.2%.
“Eligible” means intended to be sent to the monitor: errors, throttling or bugs can prevent a portion from reaching it. The figure excludes other sources of traffic, such as agents running on the research’s internal inference service, whose volume could not be estimated.
According to what was indicated to the researchers, a subset of reinforcement learning training sessions was monitored between March and June. At the start of the exercise, these sessions were no longer covered.
The absence of monitoring for compaction events presumably left unmonitored about 10% of the eligible Codex traffic between May and July 2026. The uncertainty is high because the information needed was not logged. OpenAI had identified the problem before the exercise and fixed it during the exercise.
The monitor would trigger when the agent handed control back to the user. During the period without compaction monitoring, an agent could, by chaining actions, indefinitely delay its review. METR could not verify whether agents did this in practice.
Finally, according to information provided to the researchers, the monitor failed on fewer than 0.2% of requests, and no load shedding was observed over a 24-hour period during the exercise.
Five vulnerabilities reported
- The researchers found a way, in principle, to bypass the sandbox and Auto-Review, enabling an agent to perform any action accessible to the host user.
- A flaw prevented monitoring of hundreds of recent actions, including those of the exploit itself. The details were redacted by OpenAI.
- Some agents could plausibly fabricate entries causing the monitor to fail, by exploiting differences between the trajectory seen by the agent and the one seen by the monitor. The trajectory would then not be transmitted to a human reviewer.
- Two independent, client-controllable headers disabled monitoring for new agents, which could allow launching an unmonitored instance that was otherwise identical. The act of placing these headers and creating the instance could, however, be detected by the monitor.
- For two unmonitored agent tools, a simple exploit would have permitted arbitrary actions in their isolated environment. METR neither validated this behavior nor tested its exploitability in practice.
The exercise also produced two more reassuring findings.
- With minor exceptions, the monitor sees the full trajectory the agent sees.
- The monitor prompts explicitly target scheming, subversion of the monitor, sabotage, data exfiltration, deception and incoming and outgoing prompt injections.
Five design principles
METR draws five principles intended for surveillance systems capable of withstanding deliberate, strategic and sustained attacks, conducted at scale by highly capable internal agents.
- Make monitoring hard to evade. Unmonitored requests would require explicit approval to use a defined set of organizations and API keys, the use of which is prohibited for agent inference. Agents would be monitored after every N messages or N minutes, without waiting for the end of their turn.
- Ensure the traffic that should be monitored is actually monitored. Account for all inference, cross-check these logs with the monitor’s logs, maintain a list of known bypasses, and ensure the monitor sees the same context as the agent.
- Respond quickly and reliably to incidents. Appoint a clear owner, set guidelines that reduce subjectivity, and maintain immutable and easily queryable logs.
- Subject the monitor to active red-teaming. Periodically evaluate controls, look for exploitable bugs, and develop a method to assess strategic collusion.
- Isolate agents and monitors. Whenever possible, run the agent architecture in a separate environment from tool calls. The agent’s actions should not influence the monitor’s triggering, and the agent would generally not have access to its design or its code.
OpenAI says it has fixed all vulnerabilities identified that affected its production defensive stack, and has subsequently described major changes in the planned coverage of its apparatus. METR says it has not evaluated these claims.
For future editions, METR says it aims for greater transparency and independence.
Source: “Red-Teaming OpenAI’s Internal Agent Monitoring Systems,” METR, October 22, 2026.
