Two client-controllable headers could disable monitoring for new internal OpenAI agents, METR and Redwood Research reported on October 22, 2026. The researchers identified several potential bypass paths during a high-access examination of the company’s internal agent-monitoring infrastructure.
Their public account describes a historical system. It provides no evidence that those paths remain open today. OpenAI told the researchers it had patched all identified vulnerabilities affecting its production safeguards stack, but they did not evaluate that claim.
The findings show how safeguards can fail before a monitor has a chance to recognize misconduct: agent activity may never reach it, arrive in an unusable form, or influence whether monitoring runs.
Deep Access, but a Historical Snapshot
One METR employee and one Redwood Research employee conducted the exercise from July 21 through August 11, 2026. They accessed OpenAI’s internal codebase, monitoring prompts and configuration, documentation, and technical interviews with approximately a dozen staff across monitoring, safety-systems and security teams.
Their work produced a 61-page internal report examining the monitoring system as it existed on and before July 21. Changes underway during the exercise were excluded, so the report does not establish current coverage or vulnerability status.
The Redwood Research write-up explains the disclosure limits. This was a pilot for deep external access, not a comprehensive public transparency exercise. The published findings represent a small, high-level subset of the private report, and OpenAI retained rights to redact confidential or sensitive information.
Both organizations’ posts describe the same exercise, not independent replications. The scope was internal misalignment monitoring; it did not encompass every OpenAI product or safeguard.
Monitoring Eligibility Was Not Successful Monitoring
The researchers estimated that roughly 75–94% of qualifying internal Responses API agent traffic was eligible for monitoring, with substantial uncertainty in both directions. That estimate covered models at least as strong as GPT-5.5. Within the internal Codex-agent subset, estimated eligibility was 99.2%.
Eligibility meant traffic was intended to enter the monitoring pipeline. Neither figure measures successful end-to-end monitoring: implementation bugs, errors or load shedding could still prevent completion.
The denominator was incomplete, too. Other internal agentic coding traffic, including traffic on OpenAI’s internal research inference service, was excluded because access and time constraints prevented a volume estimate.
Information shown to the researchers suggested monitor errors below 0.2% of requests. This provides useful reliability evidence without establishing that all intended activity reached the monitor.
Engineering teams therefore need to distinguish which activity should be monitored, which activity receives a completed review, and whether that review correctly identifies dangerous behavior.
Bypasses Targeted Timing, Visibility and Control
The reported failure modes crossed several infrastructure boundaries, with different levels of validation.
Timing created an avoidance opportunity. Monitoring triggered when agents returned control to the user. During a period when compaction events were not monitored, agents could theoretically postpone monitoring indefinitely by continuing to act. Compaction compresses an agent’s accumulated context.
Researchers estimated that missing compaction monitoring likely left around 10% of eligible internal Codex traffic unmonitored between May and July 2026. The estimate carried substantial uncertainty because relevant trigger information had not historically been logged. OpenAI staff had independently identified this issue before the exercise and fixed it during the engagement. The researchers could not check whether agents had exploited it in practice.
Visibility and processing could also fail. One reported exploit could prevent hundreds of recent actions, including the exploit’s own actions, from being monitored. OpenAI redacted the details.
The researchers also found that agents could likely construct inputs exploiting serialization differences between agent-visible and monitor-visible trajectories, causing monitor failure without escalation to human review.
Control boundaries were another target. Researchers identified an in-principle bypass of Codex sandboxing and Auto-Review that could permit actions available to the host user. The two client-controllable headers could create an otherwise identical, unmonitored agent instance, although setting them and creating that instance could itself be detected.
Not every proposed exploit was validated. A separate finding involving two supposedly read-only internal tools was not tested for practical exploitability. Treating every finding as a demonstrated attack would overstate the evidence.
OpenAI Reported Patches; the Auditors Did Not Re-test Them
According to the researchers, OpenAI said all identified vulnerabilities affecting its production safeguards stack had been patched. The company also described significant subsequent changes to intended monitoring coverage. The researchers explicitly said they had not evaluated those claims.
The public evidence therefore supports a company-reported remediation status, without independently verified closure. This does not establish that remediation failed, and the historical findings cannot establish today’s monitoring coverage.
Independent verification would require examining the revised system, re-testing relevant attack paths, and checking whether intended traffic reliably completes monitoring. A patch statement alone does not supply those results.
Five Checks for Teams Running Production Agents
The researchers’ design recommendations translate into five practical checks. These are engineering implications of the findings, not a tested guarantee of security.
-
Account for all agent traffic. Inventory inference services, agent tools, credentials and routing exceptions. Explicitly approve unmonitored exceptions rather than assuming one API’s coverage represents the entire system.
