Agentic AI Red Teaming: A Methodology for Testing Autonomous Agents

The agentic attack surface is bigger than the prompt

A tool-using agent has five components an attacker can reach, and each is a distinct test target: the system prompt and policy, the tool set it can invoke, its memory (short-term context and any persistent store), the planning loop that decides the next action, and the data it ingests from retrieval, tools, and the environment. The defining property — and the source of the risk — is that ingested data re-enters the reasoning loop and can therefore rewrite the agent’s goals mid-task. This is why the 2026 JadePuffer operation could run reconnaissance, credential theft, lateral movement and encryption autonomously: once the loop was subverted, the agent’s own capabilities became the attack.

Phase 1 — enumerate capabilities and identity

Before attacking, map what the agent can do. Enumerate every tool in its manifest and, for each, determine the service identity it runs as and the scopes that identity holds. Establish the delta between the invoking user’s entitlements and the agent’s — that delta is your confused-deputy budget. Identify which tools are irreversible (write, send, delete, pay) and which touch secrets. A capability map like this turns a vague “test the AI” engagement into a concrete list of privileged actions you are trying to induce without authorisation.

Phase 2 — indirect prompt injection via ingested content

Direct injection (typing “ignore your instructions” to the agent) is the weakest test and the one developers have usually seen. The high-value work is indirect injection: plant instructions in content the agent will later retrieve — a document in the knowledge base, a web page it browses, a row in a database it queries, a field in an API response. The payload does not target the user’s turn; it targets a future tool result. Test every ingestion path independently, because the trust boundary the developers forgot is almost always one of these.

Phase 3 — goal hijacking and tool-chain abuse

Once you can influence the reasoning loop, escalate from “make it say X” to “make it do X.” Chain benign-looking tools into a harmful outcome: use a read tool to stage data into a location a write tool will exfiltrate; use a legitimate automation tool to reach a system outside the intended scope; induce the agent to call an irreversible tool with attacker-chosen arguments. The severity of an agentic finding is measured in actions taken, not tokens generated — a successful goal hijack that triggers a real privileged tool call is the equivalent of RCE for this class of system.

Phase 4 — memory poisoning and persistence

Agents with persistent memory have a durable attack surface most testers miss. If you can write a crafted “fact” or instruction into the agent’s long-term store during one session, it may influence behaviour in future sessions — potentially those of other users. Test whether ingested content can reach persistent memory, whether that memory is authenticated and attributed, and whether a poisoned entry survives across sessions. Persistence in an agent is the analogue of a stored XSS: one write, many victims.

Phase 5 — exfiltration channels and guardrail evasion

Map how data can leave. Any tool that makes an outbound request — a web fetch, an image render from a URL, a webhook, an email — is a candidate exfiltration channel for secrets pulled into context. Test whether guardrails (input classifiers, output filters) can be bypassed with encoding, language switching, multi-step framing, or by moving the payload into a modality the classifier does not inspect. Document the channel, not just the leak: defenders fix channels.

Reporting agentic findings

Structure findings around the OWASP Agentic Top 10 and the AISVS verification standard so they map to controls the client can act on. For each finding, state the ingestion path, the reasoning-loop effect, the concrete action induced, and the identity/scope that made it possible — because the fix is almost always one of: shrink the agent’s scope, authorise tool calls against the end user, isolate tool output from instructions, or gate the irreversible action behind a human. Pair this module with the MCP server security and prompt-injection defence modules to cover both the offensive methodology and the architecture that defeats it.