Prompt Injection Testing Methodologies for Agentic Systems
A 2025 threat model reveals four required test categories most teams skip, leaving dangerous gaps.
The most actionable published framework for organizing agentic prompt injection tests comes from Narajala and Narayan's 2025 threat model, which structures the problem along two axes: attack vector and impact scope. That framing produces four test categories a complete suite must address. Omit one and you have a gap an attacker will find before your regression suite does — like leaving a door unlocked because you installed a really good window latch.
Direct and Indirect Input Manipulation
Direct prompt injection is the familiar case: an adversary controls the user-facing input and inserts malicious instructions there. It is the easiest to test and, increasingly, the least interesting attack surface, because most teams have at least some controls at the UI layer. Indirect prompt injection is where the consequential risk lives. Malicious instructions arrive embedded in data the agent retrieves autonomously: documents, web pages, database records, email bodies, calendar entries, issue tracker comments. The attacker never touches the application. They only need write access to something the agent will eventually read.
Palo Alto Networks Unit 42 confirmed the first real-world production instance of malicious indirect prompt injection in December 2025. A test suite covering only direct injection is, at this point, incomplete by definition. Not mostly complete. Incomplete.
Tool Chain Exploitation
An agent that can read a database, open a ticket, and send a message in sequence exposes a chained-action surface no single-turn model has. An injection that captures tool invocation can pivot from one system to another without the attacker needing independent access to each downstream system. The blast radius scales with the agent's permissions, not with the sophistication of the payload. That asymmetry matters: a crude injected instruction delivered to a highly privileged agent is like handing a skeleton key to someone who only asked for directions — the damage is not in the ask, it's in what the key opens.
RAG and Retrieval Poisoning
A small number of carefully crafted documents can manipulate AI retrieval-augmented responses with alarming reliability. In January 2025, researchers demonstrated a live enterprise RAG attack: malicious instructions embedded in a publicly accessible document caused an AI system to leak sensitive data. The test surface is not the UI; it is the entire corpus. Every document the agent can retrieve is a potential injection vector.
MCP-Specific and Tool-Poisoning Vectors
April 2025 research identified lookalike MCP tools that silently replace trusted ones, along with tool-permission combinations that enable data exfiltration even when no single tool is individually dangerous. CVE-2025-6514, a command-injection vulnerability in the mcp-remote npm package, produced a real, patched production CVE. Every MCP server the agent can reach is a potential injection surface. Testers should treat it accordingly.
Test cases cannot be designed by listing inputs. They must be designed by tracing every data source the agent consumes and every action it can take.
Mapping the Full Attack Surface Before Writing a Single Test Case
The agentic attack surface has five distinct layers, all of which require enumeration before testing begins: user input channels (chat UI, API, voice, form fields); retrieved content (RAG corpus, web browsing, file reads, email and calendar access); tool definitions and MCP server manifests; inter-agent messages in multi-agent pipelines; and environmental state, including memory, scratchpad, task queue, and prior conversation context.
Tool definitions warrant particular scrutiny. MCP tool descriptions are read by the LLM and directly inform its decision-making. A poisoned description can redirect the agent without ever touching user input. Lookalike tool substitution is invisible at the UI layer; it only surfaces when you inspect the tool manifest the agent actually loaded during the session. Most teams never check that manifest.
Surface mapping in practice means enumerating every MCP server and tool the agent can access, not just the ones the product team considers primary. Data flow must be traced: for every retrieval action, identify who can write to the source. The agent's permission envelope, what it can read, write, delete, and invoke, must be documented explicitly, because blast radius is a function of that envelope, not of the injection payload. In multi-agent architectures, identify where one agent's output becomes another agent's input; those handoff points are almost always under-tested.
The most common omission in agentic security testing is that teams assess what the agent says rather than what it does. Surface mapping forces attention onto the action layer, which is where actual damage occurs.
Designing Test Cases for Indirect Injection, Where Most Defenses Fail
Indirect prompt injection is the highest-leverage attack class in agentic systems for a straightforward reason: the attacker operates entirely outside the application's perimeter. Every writable data source the agent reads is a potential injection surface. The payload arrives dressed as legitimate content — a wolf in sheep's clothing, except the wolf has read-write access to your enterprise knowledge base. A human reviewer looking at the document sees a quarterly report; the LLM reads an exfiltration command. No anomaly. No alert. The malice is semantic, not syntactic.
Test case design follows from that premise. Payloads should appear as plausible content to human reviewers while carrying embedded directives to the model. Tests should probe whether the agent's system prompt provides any meaningful instruction boundary, or whether retrieved content can override it, because in many production deployments, it can. Exfiltration paths deserve explicit test cases: does an injected instruction cause the agent to embed sensitive data in an outbound tool call, an HTTP request, an email body, a ticket description?
RAG-specific test cases add further granularity. Seed the retrieval corpus with crafted documents and observe whether injected instructions execute. Test chunking boundary effects, because instructions split across chunks evade naive content filters that inspect whole documents. Test whether metadata fields such as document title, author, and tags are passed to model context and can carry payloads; many implementations pass that metadata without scrutiny.
AgentVigil, from Wang et al., provides a black-box red-teaming framework that generates adversarial indirect injection inputs automatically without requiring knowledge of the agent's internal architecture. That is useful for any team operating without access to source code, which is frequently the reality when testing third-party integrations.
Indirect injection is why signature-based defenses fail here, consistently and predictably. The agent received a valid document. The problem was never the format.
Testing Multi-Step Tool Chains for Injection Propagation and Privilege Escalation
A single-turn chatbot and an agentic system running a multi-step tool chain are not the same threat model. Passing a safety evaluation at the input layer does not mean the chain is safe. This is the point most AppSec practitioners underestimate when they first encounter agentic systems, and the one they remember longest after their first real incident.
An injection payload introduced at step one produces no visible harm until step four or five. The agent carries the malicious instruction forward through its working memory while executing ostensibly legitimate intermediate steps. Each tool call is a potential escalation point if accumulated context enables the agent to reach systems the original instruction could not have accessed directly. The stochastic nature of LLM outputs compounds this: the same payload triggers the chain on one run and fails on another. Single-run test coverage is not coverage; minimum run counts per test case must be established as policy.
Test case patterns for tool chains include triggering an injection at step N and observing tool invocations at all subsequent steps. Does the injected instruction alter what the agent calls, or when? Does an injection initiating a read action subsequently cause a write action downstream? Test the read-then-exfiltrate and read-then-delete patterns explicitly. In orchestrator and subagent architectures, test whether an injection in one agent's context propagates into instructions passed to a subordinate agent. Test whether the agent's tool-call history or scratchpad can itself become a secondary injection surface, because in some implementations, that state is reintroduced into model context on subsequent turns.
The April 2025 MCP research identified a specific chain pattern worth testing explicitly: tool-permission combination attacks, where no single tool is individually dangerous, but the combination of read-database and write-external-endpoint enables exfiltration. That combination is invisible as a risk if you evaluate tools in isolation. Most teams evaluate tools in isolation.
One logging requirement this surfaces immediately: you cannot review a tool-chain injection test by reading the final output. A complete, ordered record of every tool call the agent made during the run is a prerequisite for any usable finding. Without that log, you have not tested the chain; you have observed the endpoint.
What Structured Red-Teaming Looks Like in Practice for Agentic Systems
HackerOne's 2025 methodology illustrates the scale that systematic agentic red-teaming actually requires. Their research drew on a survey of 99 customer representatives and over 1,800 active security researchers, analyzing more than 45,000 payload signatures from tens of thousands of redacted vulnerability reports. This is not a checklist one analyst completes in a sprint.
The operational structure follows four phases. Reconnaissance comes first: surface mapping as described above, system prompt extraction attempts, and tool manifest enumeration. Automated payload sweeps follow, using frameworks such as AgentVigil to generate indirect injection candidates across every identified surface, not only the primary input channel. Manual chain testing is the third phase, where human testers follow up on automated hits with multi-step scenarios that probe blast radius and propagation depth. The fourth phase is regression: re-running the full payload library after any model update, system prompt change, or new tool integration, because each of those changes can reopen findings previously closed.
The stochastic nature problem, named explicitly in PALADIN framework analysis, means a single passing run does not mean a vector is safe. Minimum run counts per test case should be established as policy, not left to individual tester judgment.
Documentation standards matter as much as the testing itself. Every finding must record the injection surface, the payload, the sequence of tool calls that followed, and the final data or action impact. "The model produced bad output" is not a finding; it is an observation without a remediation path.
On red team composition: the most dangerous findings in agentic testing come from business-logic knowledge, not prompt creativity. Include someone who understands the agent's data flows and tool permissions alongside someone who understands LLM prompting. The former knows which permission combinations produce catastrophic blast radius. The latter knows how to embed an instruction in a plausible document. Together, they find things neither would find working alone.
Defense-in-Depth Controls That Testing Results Should Map To
The PALADIN framework organizes prompt injection defense into five protective layers, and its core insight is that no single control is sufficient because the vulnerability is architectural. Testing findings should map to specific layers; that mapping is what makes remediations actionable for engineering teams rather than producing an undifferentiated list of concerns with no clear owner.
Input validation and sanitization surfaces which retrieval paths lack content inspection before data reaches model context. Prompt hardening findings reveal whether system prompts provide real instruction boundaries or are trivially overridden by retrieved content. Least-privilege tool access findings emerge directly from chain testing: every agent with permissions wider than its task requires is an unnecessary blast radius. Output monitoring gaps appear when exfiltration payloads reach tool-call outputs without interception; real-time PII and secrets detection at the tool-call layer is the structural response. Audit and observability gaps surfaced during testing, especially in tool chains, become direct input to logging requirements.
For teams operating at scale, the MCP gateway represents the most coherent enforcement point for most of these layers. A governed gateway sitting between the agent and every MCP server applies policy at the point of tool invocation rather than relying on the model to self-enforce behavioral constraints, which it demonstrably will not do under adversarial conditions. Real-time prompt injection detection, PII blocking, and secrets detection applied at this layer address every outbound tool call consistently. RBAC enforced at the gateway level maps directly to test findings about over-privileged agents. Immutable audit logs of every tool call are the prerequisite for both regression testing and compliance evidence.
Speakeasy's AI control plane addresses this defense-in-depth requirement at the infrastructure layer, providing governed distribution, real-time threat detection, RBAC, and full observability as a platform capability rather than requiring each team to construct these controls independently per agent deployment.
Compliance mapping should be produced alongside technical findings. Test results indexed to OWASP LLM Top 10, MITRE ATLAS, and the EU AI Act, with its August 2026 deadline, are substantially easier to prioritize in a security review than an unstructured vulnerability list. A finding without a framework mapping is harder to escalate and slower to remediate.
How to Build a Repeatable Testing Program as the Agent Fleet Grows
One-time testing does not solve the fundamental problem of fleet growth. Every new MCP server, every new tool integration, every model update, every system prompt change is a potential regression event. The testing program that assessed the agent at launch is inadequate for the agent six months and a dozen integrations later. This is not theoretical; it is the most predictable failure mode in agentic security programs, and it happens quietly.
Repeatability requires several structural commitments. The payload library must be versioned and maintained as a living artifact, updated as new attack patterns emerge and as the agent's tool surface evolves. Surface mapping must be re-executed rather than assumed stable, because tool manifests change, retrieval corpora grow, and inter-agent topologies shift as organizations add capabilities. Regression runs must be triggered automatically by deployment events, rather than scheduled quarterly by someone who has twelve other priorities.
The stochastic variance problem means automated regression cannot rely on deterministic pass-fail thresholds at the run level. Statistical aggregation across multiple runs per test case, with threshold policies on acceptable failure rates, is the operational standard that produces reliable signal.
As agent fleets scale, governance becomes as significant as the technical testing problem. Which team owns the payload library? Who approves a new MCP server as adequately tested before it reaches production? What is the escalation path when a regression run surfaces a previously closed finding? Without clear answers to those questions, the testing program degrades as the fleet grows, precisely when the risk surface is expanding fastest.
The parallel to web application security is instructive, not as a tidy conclusion, but as a caution: the teams that struggled most with web application security in the 2010s were the ones that treated it as a launch-gate rather than an operational discipline. Agentic systems are a harder version of that same problem, with a threat model that moves faster and a blast radius that extends well beyond what most AppSec practitioners have had to reason about before. The institutional commitment required is not larger in kind; it is larger in urgency.
