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 malicious instructions arrive in tool descriptions and redirect agents into approved tools with valid permissions.

Why it matters: It matters because MCP turns tool approval into a control boundary that can be bypassed by poisoned metadata, which leaves IAM, NHI, and agent governance teams needing behavioural rather than purely declarative controls.

By the numbers:

• Attack success reached 72.8% across 45 live MCP servers, 353 authentic tools, 1,312 malicious test cases, and 20 agent configurations.
• 36.5%.
• 3%.

👉 Read ARMO's analysis of MCP prompt injection and compromised NHIs

Context

Model Context Protocol gives agents a standard way to discover tools and connect to data sources, but that same discovery step becomes a control boundary when tool metadata is untrusted. The primary risk is not prompt content alone, but poisoned tool descriptions that enter the agent’s context as if they were authoritative capability definitions.

For IAM and NHI teams, the governance gap is straightforward: approval workflows validate which servers and tools are allowed, yet they do not reliably validate what those tools say about themselves once registered. That makes tool descriptions, parameter values, and cross-server trust relationships part of the identity problem, not just an application-layer prompt problem.

The article’s findings are consistent with a broader shift in agent security. As AI agents take on more tool use, the question moves from whether a tool is approved to whether the agent can be manipulated into using an approved tool in an unintended way.

Key questions

Q: What breaks when MCP tool descriptions can be modified by an attacker?

A: The trust boundary breaks. Approved servers can still deliver malicious guidance if the agent treats tool descriptions as authoritative capability statements. That means allowlists and approval prompts may succeed while the agent is quietly redirected into a legitimate tool call with harmful intent. The control failure is not approval alone, but approval without verification of metadata integrity.

Q: Why do approved tools create risk in MCP environments?

A: Approved tools are risky because the malicious instruction does not need to invoke an untrusted tool. It can steer the agent into a legitimate tool that already has the permissions needed to finish the job. In other words, the tool is trusted, but the use is not. That is why behavioural baselines matter more than simple tool registration.

Q: How should security teams protect MCP tools from hidden prompt injection?

A: Treat MCP tool metadata as untrusted input. Normalize text, remove invisible or control characters, validate the source of each tool, and restrict the agent to approved functions only. Add logging for tool selection and execution so hidden instructions cannot move unnoticed from description into action.

Q: What should organisations do when agent tool calls stay valid but look unusual?

A: Treat them as potential compromise, not as benign variance. Start by validating whether the call matches the agent’s historical pattern for that task, then review the source server, the tool description history, and any cross-server influence. If the request is valid but contextually abnormal, contain the agent before it completes additional delegated actions.

Technical breakdown

Why MCP tool descriptions become a control channel

MCP servers publish tool names and natural-language descriptions that the host agent ingests before the user prompt arrives. In practice, that means the description is treated as ground truth about capability and preconditions, even when it is attacker-authored. The important failure mode is not that the poisoned tool is invoked directly. It is that the description alters planning so the agent calls a separate legitimate tool with valid permissions. That is why server allowlists, approval prompts, and schema validation can all pass while the malicious outcome still occurs.

Practical implication: Treat tool metadata as security-sensitive input and validate it separately from the tool execution path.

Why parameter tampering is the hardest-to-see MCP attack

The highest-scoring paradigm in the benchmark changed only one argument value on a call the agent was already making. That is a subtle but important distinction. The tool name stays correct, the schema still validates, and the session remains authorised, so protocol-level inspection sees an ordinary request. The attack succeeds because the agent’s reasoning layer has been redirected to substitute a malicious value into a legitimate action. This is less about payload syntax than about behavioural coercion inside the decision path.

Practical implication: Baseline normal parameter ranges for each agent so a valid tool call with abnormal values can still be flagged.

Why static filters and gateways miss the relationship between calls

Static scanners can hash descriptions and look for suspicious wording, and gateways can inspect runtime traffic for policy violations. Both matter, but neither solves the core problem. The attack lives in the sequence of tool calls, not just in the text or the single request. A malicious description becomes dangerous only when it changes how the agent uses later tools, including tools on another server. That makes per-agent history, call order, and runtime context the security signal that best maps to actual abuse.

Practical implication: Add behavioural baselines that track tool-call history, not just allowlists or text signatures.

Threat narrative

Attacker objective: The attacker wants to coerce an approved AI agent into carrying out a malicious action through a legitimate tool call that looks authorised at the protocol layer.

1. Entry occurs when the attacker injects malicious instructions into an MCP tool description during server registration or a later metadata update.
2. Escalation happens when the agent accepts the description as capability truth and uses it to plan a legitimate tool invocation with malicious parameters.
3. Impact follows when the approved tool performs the harmful action under valid permissions, letting the attacker bypass the intended trust boundary.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tool metadata is now part of the identity attack surface: MCP turns registration-time descriptions into an input that can override planning, which means the trust boundary sits earlier than most teams model it. The governance lesson is that allowlisting a server does not mean trusting every capability statement it publishes. IAM and NHI teams should treat descriptions as policy-bearing material, not harmless documentation.

Agent security needs behavioural identity, not only approval identity: The article shows that a tool can be approved, schema-valid, and still be abused because the agent’s behaviour changed. That is a classic identity governance gap in a new form. The right control question is whether the agent’s actual call pattern still matches its expected identity under load, not just whether the tool exists in a registry.

Approved tools can become secondary execution channels: The poisoned description rarely needs to run itself. Instead, it steers the agent into a different approved tool that completes the malicious action with its own permissions. That is the same structural problem identity teams see when delegated access exceeds intent. Practitioners should focus on delegated action boundaries, not only token issuance.

Context poisoning creates a named governance gap: tool-description trust debt: Tool-description trust debt is the accumulation of unverified metadata that an agent treats as authoritative because it arrived through a trusted connection. Once that debt builds up, normal approval workflows stop being sufficient because the agent is reading policy-shaped instructions as facts. The practical conclusion is clear: inventory who can modify descriptions, how changes are detected, and which agents consume them.

Per-agent baselines are the missing control plane for MCP: The article’s strongest signal is not the existence of a bad tool, but the absence of a normal behavioural baseline for the specific agent. That baseline has to include tools, parameters, call order, and downstream process or network effects. Without it, detection remains generic and attackers can stay inside the range of approved operations.

From our research:

• Attack success reached 72.8% across 45 live MCP servers, 353 authentic tools, 1,312 malicious test cases, and 20 agent configurations, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Another finding from the same research showed that when AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, with some attempts arriving in as little as 9 minutes.
• That same pattern points forward to AI agent governance, where per-agent baselines and metadata integrity checks matter more than simple approval workflows.

What this signals

MCP security is moving the control conversation from server approval to agent behaviour. For identity teams, that means the next gap is not whether a tool is allowed, but whether the agent can be steered into using it outside intended context. The most useful control boundary is the one that joins metadata integrity, call history, and runtime telemetry.

Tool-description trust debt: this is the accumulation of unverified metadata that an agent treats as policy because it arrived through a trusted channel. Once that debt grows, static allowlists and signature checks lose explanatory power. Teams should expect behavioural detections, not content filters, to become the more reliable signal for agent compromise.

The same lesson applies to broader AI governance. As tool use expands, identity for AI systems increasingly depends on who can change context, who can approve execution, and how deviation is measured. The organisations that define those boundaries early will have a far easier time governing autonomous tool use later.

For practitioners

• Separate metadata trust from tool execution trust Validate MCP tool descriptions at registration and on change, then compare them against an approved baseline before the agent loads them into context.
• Baseline agent-specific tool behaviour Record the normal tools, parameter values, call order, and downstream file or network effects for each production agent so deviations stand out immediately.
• Flag cross-server tool influence Review cases where a description from one server changes how the agent uses a tool from another server, because that is the pattern the approval layer will not see.
• Detect abnormal parameter substitution Alert on legitimate tool calls where only a single argument changes into a value the agent has never used before, especially for send, read, and query actions.
• Harden credential exposure around agents Keep real credentials out of agent-readable paths where possible and use short-lived or scoped access so a coerced tool call cannot complete high-risk actions.

Key takeaways

• MCP prompt injection works because malicious instructions can arrive as trusted tool metadata rather than as obvious prompt content.
• The strongest attacks keep the tool name and schema valid, which makes parameter-level behavioural detection more important than text filtering.
• Per-agent behavioural baselines and metadata integrity checks are now core controls for AI agent governance, not optional hardening.

Key terms

• MCP tool poisoning: MCP tool poisoning is the practice of hiding malicious instructions in a tool name, description, or metadata exposed by an MCP server. Because those fields are often treated as trusted configuration, the agent may adopt the attacker’s instructions during tool selection or invocation.
• Tool-call trust debt: The accumulated risk created when teams connect models to tools faster than they can enforce identity, scope, logging, and revocation. In MCP environments, this debt grows with every additional server because integration is easy and governance is optional.
• Per-Agent Baseline: A runtime profile of normal tool use, destinations, and state changes for one specific agent deployment. It allows security teams to distinguish expected behaviour from coercion or drift, and it becomes the basis for moving from audit mode to enforced controls.
• Cross-server tool influence: A condition where a description from one connected server changes how the agent uses a tool belonging to another trusted server. This matters because the malicious instruction can originate in one place and be executed through a different, approved capability that appears legitimate in isolation.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• Benchmark methodology across 45 live MCP servers and 20 agent configurations, including how the attack success rate was measured.
• Examples of poisoned tool-description payloads and how they were structured to trigger legitimate downstream tool calls.
• Discussion of agent behaviour under reasoning mode, including why more capable models were more susceptible in this test.
• Practical detection ideas for runtime teams that want to compare tool-call history against a per-agent baseline.

👉 ARMO's full blog covers the benchmark design, payload patterns, and behavioural detection ideas in more depth.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a way that maps directly to AI agent control challenges. It helps practitioners connect identity governance to the runtime decisions that modern agents make.