How do security teams find prompt injection vulnerabilities in tool-using LLM agents?

Map the attack surface

Prompt injection testing begins with an inventory of every place text can enter the agent’s decision process. The user’s message is only one source. Retrieved documents, web pages, tool results, MCP server responses and tool descriptions can all provide text that the model reads while completing a task.

The inventory should describe not only the source but also when it becomes available. Content supplied in the initial request can be covered by an input filter. A tool result may arrive mid-task, after that filter has run. A tool description may be loaded as part of the available tool set rather than presented as ordinary user content. These differences determine which test cases are needed and where evidence should be collected.

The table is an attack-surface map as well as a test-planning aid. A test plan that covers only direct instructions in the user message leaves retrieved content and tool-mediated paths unexamined. A plan that tests tool output but ignores descriptions can miss instructions that are presented to the model through the tool interface.

OWASP describes both direct and indirect prompt injection in LLM01. The MCP specification publishes security best practices for the servers agents connect to. Map every attached MCP server as its own entry point, including the content it returns, the descriptions it exposes and changes to its available tool set.

Attack each entry point with variants

A single payload demonstrates only that one phrasing reached one path. It does not establish that the agent is safe when the same instruction is expressed differently or delivered through another source. Use a corpus with many variants per entry point, and run those variants through the assembled agent rather than evaluating isolated text.

The OWASP AI Testing Guide describes the testing method. AgentDojo runs 629 security test cases against tool-using agents. These references provide useful framing for testing prompt injection as an interaction with an agent and its tools, rather than as a property of a prompt string alone.

Test the delivery path

For each entry point, vary how the instruction is delivered:

• Put the instruction directly in the user message.
• Place it in retrieved content that the user does not see.
• Return it from a tool as a row, search result or API response.
• Put it in an MCP tool description.
• Offer a look-alike tool beside the real one.
• Change a tool during the task so that it becomes malicious mid-task.

The objective is not to test whether the model can repeat or reject a suspicious sentence. The objective is to determine whether untrusted text can influence an action that the user did not request. The agent should therefore run with its actual tool definitions, tool connections and MCP servers attached.

Redline’s test corpus contains 11,204 cases across 16 families. The cases include Tool-Output Injection (4,216), Indirect Prompt Injection (120), Direct Prompt Injection (104), Tool Poisoning (48), Tool Shadowing (36) and Rug Pull (8). Each is run on its own machine with a real MCP server. These categories show why a test strategy needs more than direct prompt cases: the attack can arrive through output, descriptions, competing tools or a change in the tool during execution.

Why payload variants matter

Prompt injection is dependent on context. The same instruction may behave differently when it is written by the user, embedded in a document, returned by a search tool or placed in a tool description. The surrounding task, available tools and sequence of tool calls also affect the result.

For that reason, preserve the entry point as part of the test case. A payload copied from a user-message test into a tool-output test is not equivalent unless it is delivered through the tool’s actual return path. The test must exercise the mechanism that could carry the attack in the deployed agent.

Run the assembled agent with real tools

The assembled agent is the unit under test. That means the model, instructions, tool definitions, tool results, MCP servers and execution environment need to reflect the configuration being assessed. Testing only a prompt or model response cannot show whether an injected instruction produces an unintended action.

Real tools matter particularly for tool-output injection. The attack arrives in what a tool returns. A mock returns what was written into the mock, so the path the attacker uses does not exist in that test. A test can therefore produce a reassuring reply while never exercising the tool-mediated path where the injection would occur.

This does not make mocks useless for every purpose. They can help isolate ordinary application behaviour, but they cannot establish that tool-output injection is handled when the real return path is absent. For prompt injection findings, the test should preserve the relationship between the returned content and the subsequent tool decision.

Include MCP-specific conditions

Every MCP server adds tool results and tool descriptions the model reads, and its tool set can change. Treat each server as a separate entry point. Test its returned content, descriptions and tool-set behaviour explicitly.

Tool poisoning and tool shadowing require particular attention because the risk is not limited to the text in the user’s prompt. An MCP tool description can tell the model to call something else. A look-alike tool can be offered beside the real one. A tool can turn malicious mid-task while nothing in the prompt changes.

These cases should be recorded with the server and tool context intact. A finding needs to show which server or tool supplied the relevant text and which subsequent action resulted. This makes the result actionable for the team responsible for the agent configuration or connected server.

Confirm findings from the trace

The response is not sufficient evidence of what the agent did. An agent may say that it refused while the trace shows that it made the call. Conversely, an unusual response without a corresponding action is weaker evidence than a trace showing an unneeded call, an unexpected argument or a secret leaving the environment.

Grade the execution trace and the environment. Review the sequence of messages, tool calls, arguments and outbound requests. Relate each action back to the user’s original request. The central question is whether the action was needed to fulfil that request.

Signals that a payload landed

• Unneeded tool calls. A call the user’s request did not require, such as an export during a summary, is the clearest signal that a payload landed.
• Arguments that belong to someone else. A permitted tool called with another customer’s id, or with an attacker-supplied address, shows that the injected content affected the action or its parameters.
• Canary values leaving. A planted secret in a reply, argument or URL is a confirmed exfiltration path. EchoLeak shows a zero-click version in a production system.
• Refusals that are not. An agent saying it declined while the trace shows the call should be graded according to the trace and the environment, not the wording of the reply.

A trace-based finding should preserve the triggering input, the entry point through which it arrived and the resulting action. It should also preserve the relevant tool and MCP context. This allows the team to distinguish an actual action from a model statement about an action.

Separate weak evidence from confirmed impact

An odd answer can indicate that the agent encountered confusing or malicious text, but it does not by itself establish that an injection succeeded. The stronger evidence is an effect in the trace: a tool call, an argument or an outbound request the user did not ask for, or a planted secret leaving.

This distinction helps avoid grading the agent on its prose. The agent’s final response may be incomplete, misleading or falsely reassuring. The trace records what the system attempted, and the environment shows whether the attempted action reached a relevant destination.

Keep finding vulnerabilities in production

Tests cover the attacks you had. Production can receive content that was not represented in the test corpus, so monitoring should look for the same effects used to confirm test findings.

Score every incoming message with a classifier and record every session. Add a honeypot tool that no legitimate conversation calls. A new injection that works then appears as a call rather than remaining a guess. The approach shifts detection towards observable behaviour: the message is scored, the session is retained and an unexpected call provides a trace signal.

See AI agent honeypots and the agent security lifecycle for related guidance.

Re-run after changes

Keep the traces from each test run and re-run the cases after every change. Changes to prompts, retrieved content, tool descriptions, MCP servers or available tools can alter the attack path. The same applies when a tool set changes during a task.

Retaining traces makes comparison possible. It allows the team to determine whether a payload still produces the same call, whether an argument changed, and whether a prior exfiltration path remains. The test result should therefore include more than pass or fail: preserve the evidence needed to inspect the action.

Production monitoring and pre-release testing serve different purposes. The corpus exercises known attack patterns. Session recording and the honeypot tool provide a way to identify a new injection through its observed effect.

Turn results into an engineering workflow

A useful workflow links each finding to an entry point, payload variant, execution trace and resulting action. This gives the security and AI engineering teams a shared description of the problem.

Start by listing the agent’s user, retrieval, tool and MCP inputs. Then associate tests with each path. For every case, retain the assembled configuration and run with the real tools. When a case triggers, inspect the trace and classify the result according to the action observed.

A finding should identify:

• The entry point that carried the untrusted text.
• The payload variant used.
• The tool or MCP server involved.
• The unexpected call, argument or outbound request.
• Any canary value that left in a reply, argument or URL.
• The trace showing the action.
• The configuration change or re-run needed to verify the result.

This structure prevents two common mistakes. First, it avoids treating a static condition as proof that an attack lands. Secondly, it avoids treating an odd reply as proof of compromise when no relevant action occurred.

Static inspection remains useful for finding risky conditions, such as a tool description containing instructions or an over-broad tool. Runtime testing is needed to determine whether the attack lands. The two activities answer different questions and should be recorded separately.

Key takeaways

• Map every source of untrusted text, not only the user’s message.
• Treat every attached MCP server as its own entry point.
• Use payload variants for user messages, retrieved content, tool results, tool descriptions and changing tool sets.
• Run tests against the assembled agent with real tools and a real MCP server.
• Confirm findings from tool calls, arguments, outbound requests and canary values in the trace.
• Keep traces, record sessions and use a honeypot tool to identify new injections in production.

Common questions

Can a static scan find prompt injection in an agent?

It can find risky conditions, such as a tool description containing instructions or an over-broad tool, but not whether an attack lands. That requires running payloads against the assembled agent and reading the trace. Static inspection and runtime testing should therefore be treated as separate activities: one identifies conditions, while the other confirms whether they produce an unintended action.

Why test with real tools instead of mocks?

Tool-output injection arrives in what a tool returns. A mock returns what you wrote, so the path the attacker uses does not exist in the test. Running with real tools preserves the relationship between returned content and the agent’s subsequent decision. Without that path, a test cannot establish how the deployed tool interaction handles injected output.

What counts as a prompt injection finding?

A specific effect in the trace counts as a finding: a tool call, argument or outbound request the user did not ask for, or a planted secret leaving. An odd reply alone is weak evidence. The assessment should compare the observed action with the user’s request and retain the trace showing how the injected content affected execution.

How is MCP different?

Every MCP server adds tool results and tool descriptions the model reads, and its tool set can change. Treat each server as a separate entry point and test tool poisoning and look-alike tools explicitly. The test should preserve which server supplied the content and which tool action followed, because the relevant attack path may not appear in the user’s prompt.

Sources

• OWASP LLM01: Prompt Injection
• MCP security best practices
• OWASP AI Testing Guide: Testing for Prompt Injection
• AgentDojo
• EchoLeak