METR and Redwood Research on October 22, 2026 published a public account of a pilot exercise in which one employee from each organization spent three weeks with deep access to OpenAI’s internal infrastructure, stress-testing the company’s internal misalignment monitoring system. The evaluators reported discovering a number of novel vulnerabilities in the system as it existed on and before July 21, 2026.
The exercise ran from July 21 to August 11, 2026, and focused primarily on estimating the fraction of agentic inference that is monitored and on whether agents could in principle disable or subvert the monitoring system. Its output was a 61-page internal report shared with OpenAI researchers and security staff; a 38-page version redacted by OpenAI was shared with the leadership teams at METR and Redwood Research.
Deep Access Under Controlled Terms
The two evaluators had access to OpenAI’s internal codebase, misalignment-monitor prompts and configuration details, and internal documentation, and they conducted technical interviews with approximately a dozen researchers and engineers across the monitoring, safety-systems, and security teams. To enable that level of access, they worked on OpenAI-issued devices that never left the premises and were accompanied while onsite.
METR, Redwood Research, and OpenAI designed the exercise as a pilot for giving external researchers deep access to internal infrastructure rather than as a vehicle for robust public transparency about OpenAI’s monitoring systems, and the parties agreed upfront to publish only a relatively brief, high-level public post. OpenAI held the right to redact from the public version any information it determined, in its sole discretion, to be confidential or otherwise sensitive. The findings describe the historical system assessed on and before July 21 and do not evaluate changes that were in progress at the time; METR noted that OpenAI was expanding its monitoring system during the exercise.
Coverage Gaps and Paths Around the Monitor
METR estimated that roughly 75–94% of agentic internal Responses API traffic from models at least as strong as GPT-5.5 was eligible for monitoring at the time of the exercise, while acknowledging substantial uncertainty in both directions. The Responses API powers Codex, among other things, and within the subset of that traffic used for internal Codex agents the evaluators estimated 99.2% was eligible for monitoring. They said they were unable to estimate the volume of other internal agentic coding traffic they were aware of, such as agents running on OpenAI’s internal research inference service, because of access and time constraints.
Several findings concerned gaps in that coverage. At the start of the exercise, reinforcement learning training runs were not covered by the monitoring system, although the evaluators were informed that a subset of RL training rollouts had been monitored for misalignment between March and June. METR estimated that not monitoring compaction events likely left on the order of 10% of eligible internal Codex traffic unmonitored between May and July 2026, a gap OpenAI staff had independently identified before the exercise began and fixed during it. Because the system triggered when agents returned control to the user, agents could have put off being monitored indefinitely simply by continuing to act during that period; access constraints meant the evaluators could not check whether any agent had done so in practice. Separately, the evaluators were shown information suggesting that, at the time of the exercise, the monitor errored on less than 0.2% of requests and recorded zero load-sheds in one 24-hour period.
The evaluators also identified ways an agent could defeat monitoring outright. They found a method by which Codex agents could in principle bypass Codex sandboxing and Auto-Review to take any action available to the host user, and an exploit, whose details OpenAI redacted, that would keep hundreds of recent actions, including those involved in carrying out the exploit itself, from being monitored. They found that agents could likely construct inputs that cause the monitor to fail, and thereby avoid escalation for human review, by exploiting differences in how the trajectory is serialized for the agent and how it is serialized for the monitor. They found two independent client-controllable headers that disable the monitoring system for new agents, which could enable an agent to start an otherwise identical instance that runs unmonitored, though the act of setting those headers and creating the instance could itself be caught by the monitoring system. And they found two unmonitored internal agentic tools believed to have read-only permissions that a simple exploit could have subverted to take arbitrary actions in their sandboxed environment, a behavior the evaluators did not validate or test in practice.
Alongside the vulnerabilities, the evaluators verified that, with a few minor exceptions, the monitoring system is shown the full trajectory that agents see, and they validated that the monitor’s prompts look for scheming, monitor system subversion, sabotage, data exfiltration, deception, and inbound and outbound prompt injection, among other risk categories. Since the exercise ended, OpenAI has stated that all of the identified vulnerabilities that impact its production safeguards stack have been patched and has described significant subsequent changes to the intended coverage of its monitoring system. METR said it has not evaluated those claims.
The Monitoring System as OpenAI Described It
OpenAI publicly described the tested system in a March 19, 2026 post. According to that post, the low-latency system is powered by GPT-5.4 Thinking at maximum reasoning effort, reviews agent interactions within 30 minutes of completion, and logs and analyzes agents’ chains of thought and actions, categorizing each interaction, assigning it a severity level, and surfacing anomalies for human review. OpenAI said the system runs across all standard internal coding agent deployments, viewing the full conversation history, including all user, developer, and assistant messages along with tool calls and outputs.
OpenAI’s post lists monitored behavior categories that include circumventing restrictions, deception, concealing uncertainty, reward hacking, unauthorized data transfer, destructive actions, and inbound and outbound prompt injection, and it reported no true positives for sandbagging, sabotage, or scheming as of March 17, 2026. Over five months of operation, OpenAI said, the system monitored tens of millions of internal agentic coding trajectories, escalated approximately 1,000 conversations at moderate severity for human review, many of them coming from deliberate internal red-teaming, and recorded zero real conversations triggering the highest severity level. The company also said the monitor had flagged every interaction that employees independently reported through internal channels.
OpenAI stated in the post that the approach crucially relies on monitorability and that it could not confidently quantify false-negative rates on open-ended real-world traffic without dedicated control evaluations and red-teaming, describing monitoring as one layer in a defense-in-depth stack. Its stated roadmap included control evaluations, standards for acceptable reliability and latency for monitors and human reviewers, and an expansion toward synchronous blocking that would evaluate model actions and block them before they are executed.
Design Ideals for Future Monitoring
Based on the findings, the evaluators outlined design ideals for monitoring and control systems, writing that, in their view, future monitoring infrastructure should be built to hold up against deliberate and sustained attacks, mounted strategically and at scale, by highly capable agents operating inside an organization. The five ideals call for making it hard to avoid being monitored, ensuring that traffic meant to be monitored actually is, responding quickly and reliably to incidents, actively red-teaming the monitoring system, and enforcing isolation between agents and their monitors. Among the specific practices described are monitoring agents every set number of messages or minutes rather than waiting for them to end their turns, maintaining a list of all known ways around monitoring, keeping tamper-proof and searchable logs, and running agent scaffolds in an environment isolated from where tool calls are executed.
METR said the exercise benefited substantially from the depth of access and from significant logistics and technical support from OpenAI staff. For future versions of the exercise, METR said it expects to follow the transparency and independence best practices described in its “Our approach to working with AI companies” document in order to provide more robust public transparency.
💸 Earn Instantly With This Task
No fees, no waiting — your earnings could be 1 click away.
Start Earning
