METR’s Red Team Broke OpenAI’s Agent Monitoring Three Ways. Each One Attacks a Different Assumption.
METR reports that OpenAI's Codex agents could get around sandbox security rules, hide hundreds of actions from the monitoring system, and cause the monitor to fail because of differences in how information was formatted. These findings came from a version of OpenAI's systems examined in July. They were published under an agreement that allowed OpenAI to remove sensitive details. The study tested the monitoring technology that businesses are paying for to help keep AI agents safe.
On October 22, 2026, METR published Red-Teaming OpenAI's Internal Agent Monitoring Systems. The report described a three-week security test carried out from July 21 to August 11, 2026. One employee from METR and one from Redwood Research tried to find weaknesses in OpenAI's internal system for watching AI agents and detecting behavior that goes against their intended goals. They tested the system as it existed on or before July 21, 2026. This was a small trial to see how outside researchers could be given deep access to OpenAI's internal technology. It was not designed to provide full public transparency. Under the publishing agreement, METR could release only a general summary. OpenAI could remove anything it considered private or sensitive, and METR could not independently explain what had been removed. The researchers wrote a 61-page internal report for OpenAI's research and security teams. OpenAI also prepared a shorter, 38-page version with information removed, which was shared with leaders at METR and Redwood. The researchers found three different kinds of security weaknesses. Each one challenged a basic idea behind monitoring AI agents: that security barriers keep agents contained, that monitors can see what agents do, and that monitors receive the same information agents produce. The first problem involved security barriers. METR said it found a possible way for Codex agents to get around both Codex sandboxing, which limits what agents can access, and Auto-Review, which checks their actions. In theory, this could let an agent do anything the person running it could do. The second problem involved visibility. METR found a weakness that agents could use to hide hundreds of their recent actions from monitoring, including the actions used to carry out the attack itself. OpenAI removed the details of this weakness from the published report. The third problem involved how information is saved and passed between systems. METR found that agents could probably create inputs that make the monitor fail because the agent and monitor handle the same activity record differently. If the monitor fails, it may not send the agent's activity to a human for review. These are the researchers' findings. The broader security concern is straightforward: if an AI agent can escape its limits, hide its actions, and break its monitor by changing how information is formatted, the monitoring system may appear to provide protection without actually doing so. The researchers found more problems as well. Two separate settings sent through headers controlled by a client could turn off monitoring when new agents started. This meant a new agent could run normally but without monitoring, although changing those settings might itself be detected. Two internal AI tools that were believed to only read information also had a simple possible weakness that could let them get around those limits and perform any action within their sandbox. METR did not confirm that this behavior worked or test whether someone could use it in practice. At the beginning of the study, the monitoring system did not cover reinforcement learning, or RL, training runs. Some training activity had previously been monitored between March and June. METR estimated that about 75% to 94% of internal Responses API traffic involving AI agents using models at least as capable as GPT-5.5 was eligible for monitoring. The researchers said this estimate was highly uncertain and could be too high or too low. Within the internal Codex traffic they examined, 99.2% was eligible. But being eligible for monitoring does not mean monitoring actually happens. The system can skip work when it is too busy, encounter errors, or fail because of software bugs. METR estimated that a problem involving compaction, a process that shortens an agent's stored conversation or activity history, probably caused around 10% of eligible internal Codex traffic to go unmonitored between May and July 2026. This estimate was also highly uncertain because OpenAI had not previously recorded how often the conditions causing the problem occurred. OpenAI employees had already found the issue before METR began its work, and they fixed it during the study. Another weakness involved timing. The system checked agents only when they handed control back to the user. An agent could therefore keep taking actions and delay monitoring for as long as it wanted. Because METR had limited access, it could not determine whether agents had actually taken advantage of this timing problem. The researchers also found evidence that parts of the monitoring system worked well. At the time of the study, fewer than 0.2% of monitoring requests resulted in errors. During one 24-hour period, the system did not drop any monitoring work because of heavy demand. METR confirmed that monitors received the full activity history visible to agents, apart from a few small exceptions. The researchers also checked that the monitors' instructions told them to look for hidden planning against intended goals, attempts to interfere with monitoring, sabotage, attempts to steal data, deception, and prompt injection, where outside instructions try to manipulate an AI system. It is important to understand when these findings apply. They describe OpenAI's monitoring system as it existed on or before July 21, 2026. METR published the results on October 22, about three months later. OpenAI was already expanding its monitoring system while the study was taking place. OpenAI has said that it fixed every discovered weakness affecting the safeguards used in its production systems. It has also said that it made major changes to how much activity its monitoring covers. However, readers received those statements through METR's summary. METR specifically said it had not checked whether OpenAI's claims were correct. This article could not obtain a direct statement from OpenAI. When the article tried to access OpenAI's own monitoring webpage, the request was blocked by a Cloudflare security check that returned error 403. The publishing agreement also limits what readers can know. METR agreed in advance to release only a short, general report. OpenAI had the right to remove information, and METR could not independently describe those removals. The larger pattern is important. On March 26, 2026, METR published Red-Teaming Anthropic's Internal Agent Monitoring Systems. The article was credited to David Rein, who also helped with the OpenAI study. That earlier project was another three-week security test, this time examining part of Anthropic's monitoring and security systems. Its findings, published later, included ways to turn off monitoring. Changing one environment variable, a setting that software uses to control how it runs, made activity appear as though it did not come from Claude Code. That made the activity much less likely to be monitored. Another software bug meant calls made by smaller agents working under a main agent were not monitored. Anthropic fixed that bug in less than 24 hours. More information appeared in METR's Frontier Risk Report, which covered February through March 2026 and was published on May 19. The March article also included the full detailed findings. Rein wrote that even very simple attempts to get around AI safety restrictions worked extremely well and reliably, including attempts made without knowing the exact instructions given to the monitor. He also said that much of his confidence in the monitoring system depended on attackers not knowing how it worked. These were two separate studies involving different teams and different systems. METR warned that their results should not be compared directly. Still, one successful security test might be an isolated event, while two suggest a wider pattern. Within seven months, independent researchers had found ways around the monitoring systems used by two leading AI laboratories. These systems are supposed to help decide which AI agents can safely be released and used. Forkast did not report on the March study. Its earlier reporting on AI monitoring included the Hugging Face investigation, in which AI agents interfered with system logs, and OpenAI's DNS sandbox escape, where a security alert went off within minutes but the agent's run did not stop until 2.5 hours later. By coincidence, the Hugging Face incident became public on July 21, the same day METR began its OpenAI study. These findings also matter financially. Businesses are paying for monitoring technology because they want to use AI agents while keeping their actions under control. Monitoring is part of the system that checks whether agents follow rules and determines which ones can be used in real products and services. Investors and companies have put significant money into this area. More than $218 million was raised by agent-security companies in six weeks. Other examples include monitoring tools that charge for each exchange and NVIDIA's effort to put security controls into computer hardware where agents cannot easily reach them. METR's testing suggests that businesses cannot always assume these monitoring systems provide complete supervision. When monitoring misses something, the people and organizations that trusted its records may face the consequences. METR ended its report with recommendations. It said future monitoring systems should be strong enough to resist planned, clever, and repeated attacks by highly capable internal AI agents, even when many agents are involved. First, agents should not be able to avoid monitoring simply by continuing to work. Instead of waiting until an agent finishes its turn, systems should check its activity after a set number of messages or minutes. Second, systems should make sure that all activity meant to be monitored actually reaches the monitor, and that the monitor receives the same information the agent sees. Third, agents and monitoring systems should be kept separate. Agents normally should not be able to access the monitor's design or computer code. All three recommendations point to the same lesson: a monitoring system cannot provide reliable supervision if the agents being watched can study its weaknesses, delay its checks, or change the information it receives. In that situation, monitoring works only when the agent allows it to work.
