Red teaming of AI agents must attack the monitor

You must now require red-team testing of the monitor itself before deployment, not only of the agent. A single payload test or one control layer does not prove resistance to prompt injection. The entire behaviour chain from untrusted input to external action, including the monitoring system, must be attacked as part of your acceptance criteria.

An analysis of 27 October 2026 of prompt injection in AI agents and the vulnerabilities in monitoring systems designed to prevent it argues that monitoring systems themselves can be bypassed through injection, unmonitored context transitions and serialisation differences. The specific case examined is an internal agent monitoring system where researchers found the control layer attackable through multiple routes. In our assessment, this means you cannot treat a monitor as a proven control in your risk assessment without demonstrable evidence that the monitor itself has been red-teamed and its coverage recorded.

What makes prompt injection in agents harder to detect than in simple systems?

Prompt injection in an agentic system rarely follows a single path. A malicious instruction can enter through a document, email, metadata or tool result, then be retrieved via retrieval systems, ride along in a conversation summary or compaction event, be passed to another agent, and only activate a tool call with real authority much later. A test that checks only the entry point misses this entire trajectory. The chain matters because each transition point—retrieval, summarisation, agent-to-agent handoff, tool invocation—creates an opportunity for an instruction to hide, mutate or evade detection.

Which failure modes does the monitor itself face?

• Unmonitored context transitions — moments when an agent compacts or summarises its conversation history without oversight.
• Monitor injection — malicious instructions crafted to deceive the monitoring system itself rather than the agent.
• Tool coverage gaps — agent capabilities that fall outside the scope of the monitoring system.
• Serialisation vulnerabilities — differences in how data is encoded or decoded between the agent and the monitor, creating blind spots.
• Latency and cost trade-offs in detection — more sensitive monitoring increases computational burden and may be deprioritised in practice.

What does a defensible red-team assessment of an agent require?

Structured vulnerability discovery across the whole behaviour chain replaces single-payload testing. Rather than optimising individual attack texts, you must systematically search combinations of input surfaces, environments, behaviour routes and consequences. The OWASP GenAI Security Project describes an eight-phase workflow: attack discovery, persistence, impact measurement, reporting, remediation, re-testing, and documented closure. This phasing ensures that a successful exploit does not end the assessment; instead, you verify that the supplier has actually fixed the vulnerability and re-tested it.

Which concrete controls must you be able to demonstrate?

1. Record the agent's behaviour chain — document every transition point from input ingestion through retrieval, summarisation, agent handoff and tool invocation, with evidence of what was monitored at each stage.
2. Red-team the monitor as a separate target — conduct adversarial testing specifically designed to bypass, deceive or evade the monitoring system itself, not only the agent.
3. Measure monitor coverage explicitly — produce a coverage map showing which input surfaces, context transitions and tool calls fall within the monitor's scope and which do not.
4. Require remediation and re-testing before go-live — do not treat a successful demo as release; demand evidence that vulnerabilities have been fixed and that the whole chain has been re-tested.
5. Document the detection-versus-cost trade-off — have your board decide and date any explicit trade-off between detection sensitivity and latency or computational cost, rather than leaving it implicit to the engineering team.

What can tooling do, and what remains your responsibility?

Automated red-teaming frameworks can help you search the behaviour space more systematically than manual testing, and they can generate reproducible findings. They cannot, however, decide what level of risk your organisation will accept, or what trade-off between detection and cost is appropriate for your use case. Tooling also cannot replace the legal and contractual requirement to hold your supplier accountable for demonstrating that the monitor has been tested. Your responsibility is to set the acceptance criteria, to verify that testing has actually occurred, and to ensure that remediation has been demonstrated before you deploy the agent into production.