METR and Redwood found blind spots in OpenAI

You must now treat every external tool call by an AI agent as an expansion of its actual power, and demonstrate that each call stayed within intended authority, that parameters were correct, and that an error or manipulation would be stopped in time. Prompt instructions alone are not a defensible boundary.

An analysis of 29 October 2026 of tool call authorisation, accountability and containment in AI agents argues that external tool calls create blind spots in monitoring and control that can lead to data leaks, unauthorised actions and lasting changes. Red-team testing of an internal monitoring system found unmonitored context transitions, disableable monitoring headers and tools that fell outside the control layer entirely. In our assessment, this reveals a critical shift in where security must live: the actual power to modify a database or start a deployment exists outside the model, in the credential and the network, and that is where control must be demonstrable.

What makes a tool call a security boundary?

A tool call is not an answer but an action. Three mechanisms allow that action to reach further than intended. Capability-intent mismatch occurs when a tool can do more than the task requires—a database query tool that can also delete records when only reads were needed. Ambient authority arises when an agent inherits rights from its environment without an explicit boundary, so a credential issued for one purpose becomes available for another. Tool chaining accumulates effects that no one would approve in isolation: a series of individually innocuous API calls that together constitute an unauthorised change.

The red-team assessment found that even the control layer around an autonomous agent can contain uncovered paths. Context transitions were not monitored. Monitoring headers were disableable. Tools remained outside the monitor's view. The monitor itself, therefore, constitutes an attack surface, not a neutral observer.

Which control failures does this create?

• Unmonitored state transitions — moments when an agent's context is merged or compressed without logging the change.
• Disableable or bypassable monitoring — headers, flags or checks that an agent or attacker can disable or work around.
• Tools outside the control perimeter — functions available to the agent but not visible to the monitoring or authorisation layer.
• Capability-intent mismatch — tools that can perform actions beyond what the task requires.
• Ambient authority — credentials inherited from the execution environment without explicit boundary or revocation.
• Unlogged or unverifiable tool chaining — sequences of calls whose cumulative effect cannot be reconstructed or audited.

What must you demonstrate in practice?

1. Record the agent, its purpose and its authorisation — document which model each workflow uses, the lawful basis for the data it touches, and which credentials it holds.
2. Bind each tool's scope and parameters — define what each external function can do, what inputs it accepts, and what outputs it produces, with no ambient authority.
3. Isolate execution and log every call — run the agent in a sandbox, record every tool invocation with its parameters and result, and make that log immutable and auditable.
4. Test the monitor and emergency stop themselves — verify that monitoring cannot be bypassed, that an error is caught in time, and that an emergency stop can interrupt not only the agent process but also communication with model and tool infrastructure.
5. Place the emergency stop outside the agent — ensure that human intervention or automated containment does not depend on the agent's cooperation or on model-internal safeguards.

Why does the EU AI Act matter here?

The requirements for logging, human oversight and traceability align with technical control measures that may be relevant for high-risk systems under the EU AI Act. A lawyer must separately assess which obligations that regulation imposes in your concrete context. What this reporting establishes is that the decision record linked to the technical event must be connected to it, not merely contain a plausible explanation. Accountability for an AI decision shifts to whoever manages the authorisation and logging infrastructure, not to whoever wrote the prompt.

What can tooling carry and what stays your own judgement?

Automated monitoring, sandboxing and logging can make blind spots visible and create an immutable record. They cannot decide whether a tool call was authorised, whether its parameters were correct, or whether the cumulative effect of a chain of calls serves a lawful purpose. 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 your context. A director runs the risk of being accountable for an outcome that arose from a series of individually innocuous steps. The procurement or development process should therefore now contain a clause requiring an independent emergency stop placed outside the agent and immutable logging. That decision—what authority to grant, what tools to allow, what chains to permit—remains yours.