MCP prompt injection shows how approved tools can be turned against agents

At a glance

What this is: This is an analysis of MCP prompt injection, where attacker text is embedded in tool descriptions and used to redirect an agent through approved tools.

Why it matters: It matters because allowlists, approval prompts, and server vetting can all miss the real control point: what an agent does after it reads its tool context.

By the numbers:

• MCPTox tested 45 live MCP servers, 353 authentic tools, 1,312 malicious test cases and 20 agent configurations.
• Attack success reached 72.8% across the benchmark.
• The average attack success rate across every configuration was 36.5%.

Context

MCP prompt injection is a governance problem for AI agents that consume external tool metadata. The risk is not limited to malicious prompts typed by a user or embedded in retrieved content, because the payload can arrive as part of a tool description and be treated as trusted configuration by the agent.

That changes the control boundary for agentic workflows. Server approval, allowlists, and gateway inspection still matter, but they are no longer sufficient if the agent can be coerced by text that appears inside an approved tool list. For IAM and NHI programmes, the lesson is that runtime authority and descriptive metadata now need separate governance.

The article focuses on MCP, but the broader pattern is relevant anywhere a model consumes instructions about its own capabilities. The starting position for most teams is still typical: controls watch access to tools, not the semantics of the tool catalog the agent reads.

Key questions

Q: What fails when MCP tool descriptions are used to steer agents through approved tools?

A: The failure is that server approval and tool allowlists validate access, but not the intent embedded in tool metadata. A poisoned description can redirect an agent into a legitimate tool call that still appears authorised. Teams need controls that inspect tool provenance, parameter history, and behavioural context, not just whether the server was approved.

Q: Why does MCP prompt injection create accountability risk for agent governance?

A: Because the agent is acting within a permissioned environment, yet its action is being shaped by untrusted instruction hidden inside trusted configuration. That makes ownership ambiguous unless teams define who governs tool metadata, who approves changes, and who monitors the resulting calls. Without that clarity, a valid tool action can still be an unauthorised outcome.

Q: How do security teams detect MCP tool poisoning in practice?

A: Start with three signals: a stored baseline of approved descriptions, runtime diffing against the live version, and validation rules for imperatives or undeclared endpoints. Then tie those signals to agent sessions so a change can be blocked before the tool is invoked.

Q: How can organisations reduce risk when AI agents use MCP servers?

A: Start by inventorying which MCP servers are in use, which data they can reach, and which credentials they consume. Then tie those servers to policy and revocation workflows so access can be removed when ownership changes or scope exceeds expectations. The key is lifecycle control, not just visibility.

Technical breakdown

Why tool descriptions are treated as ground truth

In MCP, the host connects to servers and receives tool names plus natural-language descriptions that explain what each tool does. That metadata is inserted into the agent context before the user request is handled, so attacker-written text can arrive with the same apparent status as legitimate capability documentation. The model is not being tricked into reading arbitrary content later, it is being handed a description of its own operating environment. That is why the attack works without invoking the poisoned tool itself. The description becomes an instruction source, and the agent follows it as if it were part of the approved control plane.

Practical implication: Treat tool descriptions as governed inputs, not passive documentation, and validate them with the same scrutiny you apply to executable configuration.

Why allowlists and approval prompts miss the coercion step

Allowlists decide whether a server or tool may be used, but they do not model how an approved tool can be steered into making the wrong call. In the benchmark, the malicious action was completed by a legitimate tool already present on the server, which means the permission decision was technically correct and still operationally unsafe. That is the key failure mode: authorization to use a tool is not the same as authorization for every downstream instruction that tool description can induce. For agentic systems, the trust boundary must extend beyond access to include intent and parameter integrity.

Practical implication: Add controls that validate tool selection and parameter history, not just server approval and session authorization.

Why parameter tampering is the hardest case to catch

The highest-scoring attack paradigm changed only one argument on an otherwise valid tool call. That is important because inspection layers usually look for invalid schema, prohibited tools, or obvious prompt patterns. When the tool name is correct, the schema is valid, and only the destination or argument differs, the request still looks legitimate at the protocol layer. The signal then shifts to behavioural context: what that agent usually sends, reads, queries, or targets. This is why per-agent baselines matter more than generic prompt filters for MCP environments.

Practical implication: Baseline normal tool parameters per agent so a valid-looking call with an abnormal target or value becomes detectable.

Threat narrative

Attacker objective: The attacker aims to redirect an approved agent into performing a malicious action through a legitimate tool call that passes ordinary allowlist and approval checks.

1. Entry occurs when a poisoned instruction is embedded in an MCP tool description during server registration, before the user prompt is even processed.
2. Credential or control abuse follows when the agent reads the tool list and accepts the description as a trusted statement about how its tools should be used.
3. Impact occurs when the agent invokes a legitimate approved tool to carry out the malicious action, making the abuse look like normal authorised activity.

Breaches seen in the wild

• ForcedLeak (Salesforce Agentforce) 2025: A critical Agentforce flaw let attackers steer an AI agent through a Web-to-Lead form to leak CRM data via an expired allowlisted domain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Approved toolchains are becoming an attack surface, not a control surface. MCP prompt injection shows that governance built around server approval is not enough when the agent consumes tool metadata as instruction-bearing context. The security problem is no longer only which server is connected, but what that server can persuade the agent to do once its tool list has been loaded. For identity and access programmes, this shifts scrutiny from access grant to action governance.

Tool description coercion is the specific failure mode this benchmark exposes. The poisoned tool is never executed, yet the agent still follows the instruction because the malicious text sits inside a trusted capability declaration. That is a different control gap from classic indirect prompt injection, and it means scanners tuned to user prompts or tool outputs will miss the actual pivot point. Practitioners need to think in terms of instruction provenance inside the tool catalog, not just content moderation.

Reasoning-capable agents can amplify, not reduce, this risk. The benchmark suggests that stronger instruction-following can make an agent more willing to act on a plausible but malicious precondition. That matters for agentic AI governance because higher model capability does not automatically produce higher resilience. The decisive question becomes whether the system can distinguish legitimate task execution from coerced task execution, which is an identity and authorisation problem as much as a model-safety problem.

Per-agent behavioural baselines are the right control shape for this class of abuse. Static inspection can only judge the current call, but the exploit depends on whether that call fits the agent's historical use of a tool, parameter, and target. That pushes detection toward runtime profiling, policy tied to observed behaviour, and continuous comparison against a known-good baseline. Security teams should expect agent governance to move from approval lists to behavioural attestation.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Tool description coercion: the key governance gap is that agents consume capability descriptions as if they were authoritative policy, even though those descriptions can be attacker-controlled. That means the control problem shifts from approving a server to verifying the instruction provenance inside the tool catalog.

Teams should expect MCP-style risk to spread wherever AI systems read configuration as context. The practical response is to separate descriptive metadata from trusted policy, then monitor tool-call behaviour against a per-agent baseline so a valid-looking call with an abnormal target is still visible.

This is also where NHI governance intersects agentic AI security. If an agent can spend approved tool authority on behalf of a poisoned description, the real unit of control is the agent's runtime identity and the scope of its permitted actions, not the server list alone.

For practitioners

• Establish per-agent tool baselines Record the normal tools, parameter values, call order, and downstream process activity for each production agent so a coerced call has a measurable behavioural delta.
• Hash tool definitions at connect time Compare the loaded tool block with the previous connection state and investigate any description changes that do not align to a deliberate version update.
• Separate server approval from tool intent Require an additional control layer that checks whether a tool call is consistent with the agent's historical context, not merely whether the server was approved.

Key takeaways

• MCP prompt injection succeeds because an agent can be coerced by text that arrives as tool metadata, not just by prompts or retrieved content.
• The benchmark shows that approved tools can be turned into the attack path even when the poisoned tool itself is never executed.
• The control gap is behavioural, so teams need per-agent baselines, tool provenance checks, and tighter governance over tool descriptions.

Key terms

• MCP prompt injection: A prompt injection attack delivered through content an AI agent retrieves via the Model Context Protocol. The model reads hostile text as if it were part of the task, which can redirect tool use, data access, or other downstream actions if controls are weak.
• Tool Description Coercion: A failure mode where an agent is steered by the natural-language description of a tool rather than by a direct prompt. The description becomes an instruction carrier, so a legitimate tool can be used to perform an action the operator never intended.
• Behavior Baseline: A record of normal activity for a non-human identity, including typical consumers, resources, and actions over time. Baselines help security teams detect when an identity is being used in an unusual way and provide the context needed to enforce least privilege safely in dynamic environments.
• Tool Catalog Provenance: The governance of where tool metadata comes from, who can change it, and how those changes are validated before an agent consumes them. In MCP environments, provenance matters because static descriptions can influence runtime decisions without ever being executed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management for practitioners who need to govern runtime access rather than static approvals.Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.