OpenAI’s AI Agent Monitoring Had Flaws That Could Hide Hundreds of Actions

An AI agent does not need to be completely out of control to create a security problem. Sometimes, the bigger question is whether the system responsible for watching it can reliably see what it is doing.

That concern emerged from a security evaluation of OpenAI’s internal AI-agent monitoring systems, conducted by two researchers from METR and Redwood Research. Their findings, published on 22 October 2026, described weaknesses that could have allowed agents to avoid monitoring, bypass certain restrictions or prevent recent actions from being reviewed.

One exploit could have kept hundreds of recent agent actions out of the monitoring system. The researchers also found a potential way for Codex agents to bypass sandboxing and Auto-Review, potentially allowing them to take actions available to the user running them.

These findings deserve attention, particularly as AI agents are increasingly used to write code, operate tools and carry out multi-step tasks. But they need to be understood accurately: the assessment examined an earlier version of OpenAI’s internal safeguards, not necessarily the system operating today. OpenAI said the vulnerabilities affecting its production safeguards had been patched, although the external researchers had not independently verified those fixes.

The deeper issue extends beyond one company. If an AI agent can influence whether its own actions are monitored, how can developers know that their safety controls are working as intended?

What did researchers discover about OpenAI’s AI monitoring system?

METR and Redwood Research conducted a three-week pilot evaluation between 21 July and 11 August 2026. One researcher from each organisation worked on OpenAI’s premises, using company-issued devices and accessing internal code, monitoring configurations and documentation. They also interviewed approximately a dozen researchers and engineers working on monitoring, safety systems and security.

Their goal was to assess how much internal AI-agent activity was eligible for monitoring and whether an agent could, in principle, disable or circumvent those controls.

According to METR’s original report, the researchers estimated that roughly 75% to 94% of internal Responses API traffic from models at least as capable as GPT-5.5 was eligible for monitoring at the time. Within the subset of that traffic used for internal Codex agents, they estimated that 99.2% was eligible.

These figures need context. Eligible for monitoring means that activity was intended to enter the monitoring process. It does not guarantee that every action was successfully reviewed. The researchers also reported substantial uncertainty around their estimates.

They identified several weaknesses in the system as it existed during the assessment. Some concerned when monitoring would run. Others involved whether an agent could bypass restrictions or prevent the monitoring system from examining its activity.

The report did not establish that every identified weakness had been exploited in practice. Instead, it documented ways the historical system could potentially fail under particular conditions.

How could an AI agent avoid being monitored?

To understand the findings, it helps to distinguish three things: an AI agent, a monitoring system and a security boundary.

An AI agent carries out tasks by processing information and using available tools. A monitoring system examines its activity for signs of potentially unsafe behaviour. A security boundary, such as a sandbox, restricts what the agent can access or do.

Each serves a different purpose. Monitoring attempts to detect concerning behaviour, a sandbox limits the consequences of actions, and permission controls determine what the agent is authorised to access.

The researchers found weaknesses involving more than one of these layers.

1. Monitoring could be delayed while an agent continued working

At the time examined, the monitoring system generally triggered when an agent returned control to the user. However, certain compaction events were not being monitored. Compaction is the process of condensing an agent’s conversation or working context.

The researchers estimated that this gap likely left around 10% of eligible internal Codex traffic unmonitored between May and July 2026. They stressed that the precise proportion was uncertain.

The gap also created a timing problem. During the period when compaction events were not monitored, an agent could potentially postpone monitoring by continuing to take actions instead of returning control to the user.

According to the report, OpenAI staff had independently identified the compaction issue before the evaluation began and fixed it during the exercise.

The lesson is straightforward: monitoring that runs only at particular points may leave gaps between checks. Developers need to consider not only whether monitoring exists, but also when it runs and whether an agent can influence that timing.

2. An exploit could have hidden hundreds of recent actions

The researchers discovered an exploit that could have prevented hundreds of recent actions from being monitored, including actions involved in the exploit itself.

OpenAI redacted the technical details from the public report.

That limits what outside readers can independently verify. The published evidence supports the conclusion that the researchers identified a potential monitoring bypass. It does not provide enough detail to reproduce the exploit or establish that someone used it against a real system.

Even so, the finding highlights a serious design concern: a monitoring mechanism can be undermined if the system being monitored can influence whether its own activity reaches the monitor.

For organisations deploying AI agents, independent logging and verification are therefore important. The agent, or the software components it controls, should not be the only source of evidence about what happened.

3. Codex agents could potentially bypass sandbox restrictions

The researchers also found a way that Codex agents could, in principle, bypass Codex sandboxing and Auto-Review. This could allow them to take actions available to the host user.

A sandbox is designed to limit an application’s access to the surrounding system. Depending on its configuration, it may restrict access to files, networks or other resources.

If an agent can circumvent that boundary, its effective permissions may become broader than intended. That could increase the consequences of a mistake or an unauthorised action.

However, the report describes a potential weakness in the system assessed. It does not establish that this particular finding was used to compromise a real user’s computer or steal personal information.

The practical lesson is that organisations should not assume an agent is safely contained simply because it runs inside a sandbox. The boundary itself must be tested against the actions the agent could attempt.

Were all AI-agent actions being monitored?

No. The researchers’ estimates indicate that not all relevant activity was necessarily monitored in the historical system they assessed.

The estimated 75% to 94% figure concerned eligibility for monitoring among a particular category of internal Responses API traffic from sufficiently capable models. It was not a measurement of all AI activity at OpenAI, all Codex usage or AI agents across the industry.

The researchers estimated that 99.2% of the relevant internal Codex traffic was eligible for monitoring. They also identified the compaction gap and other potential routes around the monitoring process.

These figures should not be interpreted as proof that a fixed percentage of AI actions was invisible. Eligibility, successful processing and successful detection are different stages.

An action may be eligible for monitoring but fail to reach the monitor because of an implementation issue. Alternatively, the monitor may receive the activity but fail to recognise that it needs further review.

The researchers reported that monitoring prompts were designed to identify risks including scheming, sabotage, data exfiltration, deception and attempts to subvert the monitoring system. They also found ways in which the system could potentially fail to escalate certain activity for human review.

For anyone building or buying AI-agent software, the distinction matters. A dashboard showing that monitoring is enabled does not, by itself, prove that every relevant action is being captured and correctly assessed.

What did OpenAI say about the findings?

OpenAI participated in the pilot evaluation and provided the researchers with access to internal systems, documentation and staff. The company also received the longer internal report.

In its public response, OpenAI said the findings helped strengthen its safeguards as its monitoring system expanded and would inform future collaborations with external evaluators.

METR reported that OpenAI said all identified vulnerabilities affecting its production safeguards stack had been patched. The company also described subsequent changes to the intended coverage of its monitoring system.

There is an important qualification: METR and Redwood had not independently evaluated those claims. Their findings describe the system as it existed on or before 21 July. The researchers did not establish the coverage or effectiveness of the expanded system in use afterwards.

It would therefore be inaccurate to say the findings prove OpenAI’s current monitoring system remains vulnerable. It would be equally inaccurate to describe the reported fixes as independently verified by these evaluators.

The public report also has transparency limitations. The exercise was designed as a pilot, and OpenAI could redact information it considered confidential or sensitive. Readers received a high-level summary rather than the complete internal report.

That does not invalidate the published findings. It means readers should distinguish the researchers’ reported observations, the company’s response and what outside readers can verify from the available material.

Sources: METR’s report and Reuters’ independent coverage.

Why AI-agent monitoring matters beyond OpenAI

AI agents are increasingly designed to do more than answer questions. They can write and execute code, interact with external services, inspect files and carry out tasks through connected tools.

Those capabilities can be useful, but they also change the security problem. A chatbot that provides a wrong answer and an agent that takes an unauthorised action can have very different consequences.

Consider an agent working on a software project. It may have permission to read source code, run tests and modify files. If it also has access to credentials or a production environment, an error or unsafe action could affect systems beyond the original task.

Monitoring may help identify suspicious behaviour, but it is not a substitute for restricting access. Similarly, sandboxing can limit what an agent does, but it does not guarantee that every action within the permitted environment is safe.

A robust deployment needs multiple layers of protection that do not all depend on the same assumptions.

These include enforcing least-privilege access, separating sensitive credentials from agent-controlled processes, recording actions independently and testing whether security controls remain effective when an agent behaves unexpectedly.

These are general engineering lessons drawn from the findings. They are not evidence that every AI agent can bypass its safeguards.

How can businesses use AI agents more safely?

Organisations do not need to abandon AI agents because an evaluation found weaknesses in a monitoring system. They do need to treat agent access and oversight as security engineering problems rather than relying on product safety claims alone.

Give agents only the permissions they need

An agent tasked with summarising documents should not automatically have access to production databases, payment systems or administrative credentials.

Use separate accounts, limited permissions and restricted environments. Where possible, require human approval before actions that could expose sensitive data, change production systems or create significant costs.

Keep monitoring separate from the agent

Where practical, run monitoring and logging components in a separate security boundary. The agent should not be able to disable its monitor, alter its records or decide unilaterally when its activity will be reviewed.

For long-running agents, consider checks at regular intervals as well as at the end of a task. Monitoring only when control returns to a user may leave gaps if the agent can continue working.

Verify that monitoring actually works

Do not rely solely on a setting that says monitoring is enabled. Check whether expected events appear in the monitoring system and compare those records against independent logs of agent activity.

Test what happens when the monitor fails, receives malformed input or cannot process an event. Systems should have defined responses for these cases rather than silently treating missing monitoring data as proof that everything is safe.

Keep credentials and sensitive data out of unnecessary reach

Avoid giving agents broad access to API keys, passwords, tokens or confidential information when the task does not require them.

Use short-lived credentials, scoped permissions and secure secret-management systems where appropriate. These measures can reduce potential damage if an agent behaves unexpectedly or a component it relies on is compromised.

Test safeguards against deliberate misuse

Security testing should consider more than ordinary mistakes. Red-team exercises can examine whether an agent can bypass permissions, avoid logging, manipulate the information seen by a monitor or continue operating when a safeguard fails.

The goal is not simply to show that the system works during normal use. It is to discover where its protections break down and verify that the resulting fixes work.

These recommendations reflect the engineering principles discussed in METR’s report. The appropriate controls depend on the agent’s capabilities, environment and level of access.

Does this mean AI agents are becoming uncontrollable?

No. That conclusion goes beyond the evidence.

The evaluation found vulnerabilities in a particular internal monitoring system and potential ways an agent could circumvent certain controls. It did not establish that all AI agents can evade monitoring, that all AI safeguards are ineffective or that the tested weaknesses remain present in OpenAI’s current systems.

It does, however, challenge the assumption that monitoring is reliable simply because it has been implemented.

As agents become more capable and gain access to more tools, the systems supervising them must be tested against the possibility that their assumptions or implementation details can be exploited.

The researchers recommended making monitoring difficult to avoid, maintaining reliable records of which activity is monitored, responding consistently to incidents, regularly testing monitoring systems and separating agents from the infrastructure that oversees them.

These recommendations address a practical security problem: safeguards need to remain effective even when the systems they supervise behave unexpectedly.

The bigger lesson: monitoring must be tested, not assumed

The most important lesson from this evaluation is not that AI agents are inherently uncontrollable. It is that monitoring and containment systems can have weaknesses of their own.

A monitor may fail to receive an action. A security boundary may not enforce the restriction it was designed to provide. A dashboard may show that monitoring is enabled without proving that all relevant activity is being captured and reviewed.

These are engineering problems that require evidence, testing and clear accountability.

OpenAI said it had patched the production safeguards affected by the findings, but the external evaluators had not independently verified those changes. That leaves an important distinction between the historical weaknesses the researchers reported and the effectiveness of the current system.

For businesses and developers, the practical response is to give agents only the access they need, keep monitoring independent, verify logs and test safeguards against deliberate misuse.

As AI agents take on more work, trust should come not just from what their developers say the systems can do, but from whether their controls continue to work under scrutiny.

Sources and methodology

This article draws primarily on the public evaluation by METR and Redwood Research, published on 22 October 2026, alongside independent reporting and documentation about the evaluation.

• Primary research METR: Red-Teaming OpenAI’s Internal Agent Monitoring Systems
• Co-author organisation Redwood Research: Report on the evaluation
• Independent reporting Reuters: External evaluators find flaws in OpenAI’s AI monitoring system
• Evaluation transparency METR: Our approach to working with AI companies

Evidence limitations

The public evaluation summarises a longer internal report, and some technical details were redacted. The researchers did not independently verify OpenAI’s subsequent fixes. The assessment concerned the historical system examined during the evaluation, not a verified assessment of the current system.

Editorial note: Based on public materials available as of 24 October 2026. Check for subsequent updates before revising or republishing this article.