METR and Redwood Research found blind spots in OpenAI's agent monitoring

Every external tool call by an AI agent expands its actual powers and may leak data or make lasting changes. So bound each tool's purpose, give the agent short-lived least-privilege rights, isolate execution and test the monitor and emergency stop themselves too; prompt instructions alone are not a defensible boundary.

On 22 October 2026, METR and Redwood Research published an independent red-team assessment of OpenAI's internal agent monitoring. Among other things, they reported unmonitored compaction events (moments when an agent's context is merged), possible circumvention of sandboxing and Auto-Review, serialisation discrepancies that can make monitoring fail, disableable monitoring headers and tools that remained outside the monitor's view. The findings concerned a historical internal system; OpenAI later stated it had applied patches, but METR has not evaluated those claims.

Do not use this as proof that every agent is insecure. The event shows something more specific: even the control layer around an autonomous agent can contain uncovered paths. An external tool call triggers a control chain that itself has to be tested.

What exactly did METR and Redwood Research establish about agent monitoring?

In a historical internal OpenAI monitoring system, METR and Redwood Research found concrete blind spots: context transitions that were not monitored, monitoring headers that were disableable, and tools that fell outside the control. They also demonstrated that the monitor itself constitutes an attack surface, not a neutral observer.

This fits a broader pattern. An analysis, a shortened version of which has been accepted as a short paper for IEEE COMPSAC 2026, Security Risks in Tool-Enabled AI Agents, describes how agents in privileged environments can read or modify external systems via API, shell and CI/CD tools, and how errors, prompt injections, wrong tool choices and faulty parameters can lead to data leaks, unauthorised actions and lasting changes. The experimental percentages in that research apply solely to the small-scale test setup described and are not general incident frequencies.

Why does an external tool call expand an AI agent's powers?

A tool call is not an answer but an action. Our analysis of the academic paper identifies three mechanisms through which that action can reach further than intended: capability-intent mismatch (the tool can do more than the task requires), ambient authority (the agent inherits rights from its environment without an explicit boundary) and tool chaining (actions that accumulate into an effect that no one would approve in isolation).

In our assessment, this is the point where model safety falls short. A prompt instruction lives within the model; the power to modify a database or start a deploy lives outside it, in the credential and the network. Whoever secures only the prompt leaves the actual power uncontrolled. The UK National Cyber Security Centre makes the related point in its guidance on the cyber risks of agentic AI: model-internal safeguards must not be treated as complete security, because they can be circumvented.

Which four layers demonstrably control an external function call?

The central question is whether your organisation can demonstrate that every external function call stayed within the intended authority and that an error or manipulation is stopped in time. Four layers, partly derived from the NCSC guidance, make that defensible:

• Define the permitted purpose per tool. Record the input schema, the data classification, the effect and the reversibility. A tool that does something irreversible deserves a stricter boundary than a read action.
• Give the agent a unique identity with short-lived, non-transferable least-privilege credentials and enforce the authorisation outside the model, not in the prompt.
• Isolate execution and network traffic with sandboxing, allowlists (explicitly permitted destinations), rate limits and input validation, with human approval where a call may reveal sensitive data or has lasting consequences.
• Record model, agent, tool, credential, parameter, result, error and approval data in protected, immutable logs and periodically test the monitor, the router, the approval gate and the emergency stop themselves too.

That requirement follows from the combination of the METR findings and the NCSC guidance: because controls and tool paths can themselves have blind spots, an emergency stop, in our analysis, must be able to interrupt not only the agent process, but where necessary also the communication with model and tool infrastructure. For building such an incident-response playbook for an AI agent, the difference between process interruption and full containment is decisive.

What does this mean for directors, lawyers and CISOs who must bear accountability?

Our analysis: because the monitor itself can be demonstrably vulnerable, model behaviour is no longer a reliable control point; therefore auditors and compliance officers must treat the tool call itself — with its authorisation, parameters and result — as the primary control point instead of the model's explanation. Because the actual power lies in the credential and the network and not in the prompt, accountability for an AI decision shifts to whoever manages the authorisation and logging infrastructure; therefore a CISO must now record per agent who issues, revokes and reviews the credentials, and within what timeframe. Because tool chaining can accumulate effects that no one would approve in isolation, a director runs the risk of being accountable for an outcome that arose from a series of individually innocuous steps; therefore the procurement or development process should now contain a clause requiring an independent emergency stop placed outside the agent and immutable logging. In our analysis, a non-reconstructable tool chain is a potential control and audit risk; a lawyer must separately assess whether that also leads to a compliance risk in the concrete context. The requirements for logging, human oversight and traceability described in this article align with technical control measures that may be relevant for high-risk systems; a lawyer must separately assess which obligations the EU AI Act (Regulation (EU) 2024/1689) imposes in the concrete context. Therefore the decision record linked to the technical event must be connected, and not merely contain a plausible explanation.

In brief, as a summary of that analysis:

1. Treat the tool call, not the model explanation, as the point at which you account for your work.
2. Record per agent who issues, revokes and reviews credentials.
3. Contractually require an external emergency stop and immutable logging.
4. Test whether the full tool chain is reconstructable, as red teaming of AI agents including the monitor enforces.

These four layers belong to the broader control of agentic AI and AI agents, in which it is not the model but the whole system that is the object of oversight.

Sources: The article draws on the red-team assessment by METR and Redwood Research, an IEEE COMPSAC analysis on arXiv and the guidance of the UK National Cyber Security Centre.