Red teaming of AI agents must also attack the monitor itself, a METR assessment shows

A single payload test or one monitor does not prove that an AI agent is resistant to prompt injection, because a recent red-team assessment by METR and Redwood found unmonitored context transitions, monitor injection and bypasses. So before deployment, test the whole chain from untrusted input to external action, and also attack the monitor itself.

On 22 October 2026 the research organisation METR, together with Redwood Research, published an independent red-team assessment of the internal system OpenAI uses to monitor the behaviour of its AI agents. The researchers found, among other things, unmonitored compaction events (moments when an agent summarises and shortens its conversation history), opportunities to deceive the monitor itself through injected instructions, agent tools that fell outside oversight, and vulnerabilities caused by differences in how data was serialised. In short: the control layer that was supposed to stop unsafe behaviour turned out to be attackable itself.

On the same day, the Anthropic Fellows Program published comparable work on blocking classifiers against malicious coding agents. There too, monitor injection, attacks across multiple contexts and coverage gaps proved to be real routes for bypassing an independent control layer. The shared lesson is unwelcome but sober: monitoring is not a proven control until you have attacked the monitor itself.

What exactly did METR, Redwood and Anthropic find in their red-team assessments?

METR and Redwood reported concrete, operational shortcomings in an internal agent monitoring system: unmonitored compaction events, injections that influenced the monitor, tools that were not covered and serialisation differences that served as an opening. Anthropic showed that more context, reading along with tool results and agentic monitor steps improve detection, but increase latency and cost.

Importantly, these findings come from specific internal systems and experimental set-ups. They do not yield a universal vulnerability percentage and are not evidence that every product has these weak spots. What they do demonstrate: these failure modes are realistic and remain invisible as long as you do not go looking for them deliberately.

Why is one monitor or a single payload test not enough to rule out prompt injection?

Because a prompt injection is rarely carried out in one place. A malicious instruction can enter through a document, an email, metadata or a tool result, then be retrieved via retrieval, ride along in a summary or compaction, be passed on to another agent, and only much later activate a tool call with real authority. A single test that only checks the entry point misses that chain.

The academic study ASPIRE, published on arXiv, therefore describes a shift from optimising individual attack texts towards open-ended vulnerability discovery: systematically searching combinations of input surfaces, environments, behaviour routes and consequences. The reported results are benchmark results and not proof of product safety, but they do support the idea that structured searching provides broader coverage than fixed payload tests.

What does a defensible pre-deployment assessment of an AI agent look like?

A defensible assessment follows the whole behaviour chain and tests the control layer itself. The OWASP GenAI Security Project describes for this an eight-phase workflow that does not let red teaming end at a successful exploit, but continues through persistence, impact, reporting and remediation. Use that phasing as a backbone:

• Reconnaissance: map out models, prompts, retrieval sources, tools, credentials, memory, context compression, agent handoffs and external effects.
• Behaviour graph: record for each test which untrusted source enters, which reading and reasoning steps follow, which authority is called upon and which state or action is reachable.
• Explore phase: look for unknown input surfaces and consequences; test not only direct injections but also metadata, files, emails, tool results, summaries, compaction, shared workspaces and agent-to-agent communication.
• Exploit phase: reproduce near-successful attacks, repair them and generalise the pattern.
• Monitor attack: can the agent forge transcript structures, disable the monitor, spread information across multiple contexts or use an uncovered tool?
• Assessment: only call something a vulnerability when the full causal chain is demonstrable — source, retrieval, influence, tool call and external or persistent impact.
• Coverage overview: also keep failed tests as evidence of what has been investigated, not as evidence of safety.

The OWASP manual emphasises reproducible findings and measurable results. For agents that work with confidential documents, this also touches on how retrieval can leak sensitive data, and it fits within the broader control of agentic AI and AI agents.

What does this mean for directors, lawyers and CISOs who put an AI agent into use?

Our analysis is that, because METR and Redwood demonstrated that an internal monitoring system could be bypassed, a CISO should not treat a monitor as a proven control measure without qualification in a risk assessment. We recommend tightening the pre-production acceptance criterion to require demonstrable red teaming of the monitor itself and a recorded coverage overview. Our recommendation is that, because Anthropic reports a detection-versus-latency-and-cost trade-off in its study, the board should decide and date that trade-off explicitly rather than leaving it implicitly to an engineering team. Our recommendation is also that, because ASPIRE treats prompt-injection risk as a behavior-level problem whose consequences may emerge at a later stage of an agent trajectory, a lawyer should require trajectory evidence across the whole chain and reproducible red-team results in the supplier contract. Finally, our assessment, in line with OWASP's emphasis on persistence and impact, is that a successful demo does not constitute release: before go-live, remediation and re-testing should also be demonstrated, so that the organization has a stronger basis for detecting an agent acting beyond its task boundaries. — see also incident triage when an agent acts beyond its task boundaries.

In our assessment, the desired assurance requirement should shift: not only should the red teamer demonstrate that an agent can be unsafe, but the supplier should also be required to demonstrate that the whole chain and the monitor have been tested. That connects to the thinking about AI security as its own threat layer and to the documentation requirements that follow, among others, from the EU AI Act for high-risk systems.

Summarised practically for decision-makers:

1. Demand trajectory evidence across the whole chain, not just a payload test at the entry point.
2. Have the monitor itself attacked and keep the coverage overview.
3. Decide the detection versus latency and cost trade-off at board level.
4. Tie every release to demonstrated remediation and re-testing, not to a demo.

Sources: The article draws on red-team assessments by METR and Redwood Research and by the Anthropic Fellows Program, on the GenAI Red Teaming Manual from the OWASP GenAI Security Project and on the ASPIRE study on arXiv.