Prompt Injection Attacks Targeting MCP Tool Calls

MCP tool calls give an AI agent the ability to read files, run SQL, hit APIs, and touch production systems, all based on text it reads in a context window. That text can come from a user, a tool description, or a GitHub issue the agent was never told to trust, and the agent has no way to tell the difference. This piece walks through exactly how that blind spot gets exploited, stage by stage, and what actually stops it.

Model Context Protocol launched in November 2024 as a standard way to plug large language models into outside tools: files, databases, APIs, IDEs, originally released by Anthropic. By 2025, tens of thousands of public MCP servers were running, with client support across major platforms including ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and VS Code. Enterprise AI agent deployments are projected to grow dramatically through the end of the decade. The tool-call pipeline isn't a side feature anymore. It's becoming core infrastructure, the same way REST APIs did a decade ago.

Here's the request lifecycle in short: a user gives the agent a task, the LLM plans out what to do, the client picks a tool and builds the parameters, the tool runs, and the results come back to the model. A normal API call has a human deciding which endpoint to hit. MCP hands that decision to the LLM, which chooses tools and fills in arguments based purely on text it has read, no clicks, no confirmation dialogs, just inference.

Underneath all of it sits one assumption MCP never really questions: the server offering a tool is trustworthy. There's no cryptographic check on tool descriptions, no signature verifying that what a server advertised last week is what it's advertising now. That single unexamined assumption is the crack everything else in this piece pours through.

The structural reason LLMs cannot tell instructions from data inside a tool call

Every piece of text an LLM sees, whether it's the system prompt, the user's message, a document pulled from a search, or the output of a tool, lands in the same context window. Nothing marks one as more authoritative than another. The model has no separate channel for "instructions from the developer" versus "text a stranger wrote in a GitHub comment." It's all just tokens.

An instruction embedded in a tool description carries the exact same weight, as far as the model's concerned, as one written by the system's own designers. There's no concept of where a piece of text came from once it's inside the context. MCP makes this worse, not better, because it adds two brand-new entry points for adversarial text: tool descriptions (the metadata the model reads before deciding what to call) and tool outputs (the data that comes back after execution).

The OWASP Top 10 for LLM Applications lists prompt injection among the highest-priority risks for LLM deployments. That's not because it's flashy, but because it's the root cause behind guardrail bypasses, sensitive data leaks, and tools getting invoked without authorization. Worth sitting with: this isn't a bug you patch. The attack works by using the model's instruction-following skill exactly as intended, just against text the model shouldn't have trusted. The better the model gets at following instructions, the more reliably it follows the ones an attacker planted. That single fact explains a benchmark result covered further down: capability and vulnerability rise together.

How direct prompt injection enters the tool-call pipeline

Direct injection is the simplest version: an attacker writes text, feeds it straight to the user input layer, and that text contains instructions meant to override whatever the system was told to do. In an MCP setup, that crafted input flows right into the LLM's planning step, and it can steer which tool gets picked or what arguments get passed to it.

A simple case: a user message that looks like a normal request but buries an instruction telling the agent to read a file it shouldn't touch, say, a config file holding credentials, instead of doing the task it was actually asked to do.

Here's why this is harder to catch than it sounds. The planning step is a black box. There's no checkpoint where a person looks at "here's the tool the model picked, and here's why" before execution happens. MCP doesn't require any runtime check confirming that the tool call actually matches what the user meant. Execution just happens, and only after the fact is there anything to review, if anyone thinks to look.

Direct injection needs the attacker to get their text into the input stream somehow. Indirect injection skips that requirement entirely, and that's what makes it the more dangerous cousin.

How indirect injection hides malicious instructions inside content the agent is meant to read

The mechanism here is simple and a little unsettling: an attacker plants instructions inside something the agent is going to read anyway, a web page, a PDF, a code comment, a README, a database record, a support ticket, a GitHub issue. The agent isn't tricked into fetching hostile content; it fetches the content because that's the job, and the hostile instructions just happen to be riding inside it.

Once the agent reads that document, the embedded instruction sits in the same context window as everything else, so the model treats it as valid direction. Nothing about it looks foreign to the model. That's the whole trick.

A documented 2025 case involving the GitHub MCP server showed a malicious GitHub issue hijacking an agent connected to a private repository. The tools themselves were never touched, never poisoned, completely trustworthy. The injected instructions rode in on the issue body, plain text the agent was supposed to read as part of its normal job. OWASP now cites it as a textbook case of agentic supply-chain vulnerability.

A similar case surfaced in April 2026: instructions hidden in pull-request titles got Claude Code, Gemini CLI, and GitHub Copilot to pull GitHub Actions secrets and post them right into a PR comment. No outside servers, no extra infrastructure, just a title field.

Then there's the Supabase and Cursor incident from June 2025. An agent running with privileged service-role access processed support tickets that had SQL instructions buried in them, and access tokens ended up leaking into a public thread. That one's a good illustration of how the damage compounds: privileged access, plus untrusted input, plus an outbound channel, equals a leak that didn't require any exotic exploit at all.

What ties these three together matters more than any single detail: the agents worked exactly as they were built to. Nothing broke. The attack rode the pipeline's normal, intended operation the whole way through.

Tool poisoning: injecting instructions at the metadata layer before execution begins

Researchers gave this one a name: Tool Poisoning Attack, or TPA. Instead of hiding instructions in content the agent reads mid-task, the attacker plants them directly in a tool's description, at registration, before the agent ever calls it.

Mechanically, it works like this: when the agent pulls tool metadata to figure out its plan, it reads the whole description as ground truth, including any instructions buried in there. The agent isn't being fooled in some cartoonish sense. It's reading what looks, from the inside, like a legitimate spec for what a tool does and what it needs to run.

The proof-of-concept that made this real: a proof-of-concept demonstrated a calculator tool, of all things, with hidden instructions in its description that got Cursor to read the user's SSH private key and MCP config file, then smuggle both out through what looked like an ordinary tool parameter. A calculator. That's the part worth sitting with.

MCP gives clients no way to check whether a server's current tool definitions match what was reviewed when the tool was first onboarded, and no runtime scan for adversarial text hiding in a description. A 2025 academic study looking at 1,899 servers found roughly 5.5% showing markers of tool poisoning. Separately, an AgentSeal scan of 1,808 servers turned up security findings in 66% of them, though that gap reflects how broadly "security finding" gets defined more than it reflects poisoning being common or rare.

The rug pull: how a tool that passes approval today can be weaponized tomorrow

MCP tools can change their own definitions after they've already been installed, and nothing in the protocol forces a re-approval when that schema changes. An audit passed once means, functionally, nothing about what runs six months later.

The attack pattern writes itself: register something harmless, let it pass whatever review process is in place, then mid-session swap the description for a poisoned one. The model picks up the new version on its next refresh and treats it as gospel, same as it always has.

The attack pattern has appeared in the wild: a malicious server changes its tool description partway through a session, well after the integration has already been approved and trusted, so what gets reviewed isn't what actually runs.

CVE-2025-54136, rated 8.8 on CVSS by NIST, put an official stamp on the whole pattern: approval workflows built around a tool's original schema don't stop poisoning that happens after approval.

Every audit is a snapshot. Accurate the moment it's taken, and irrelevant the moment the tool refreshes its definition. For anyone running security review on MCP tools, that means static, one-time approval buys a false sense of safety. The real attack surface isn't the tool at registration. It's the tool at every single execution afterward.

Tool shadowing and cross-server hijacking across multi-agent environments

Connect an agent to more than one MCP server, and a malicious one can intercept or override calls meant for a server the agent actually trusts. The mechanism: the bad server advertises a tool with a matching name, or a description written specifically to make the model prefer it over the legitimate option sitting right next to it.

Tool names aren't namespaced. They aren't signed. The agent has no real way to confirm which server it's actually talking to when it makes a call, and that's not a minor gap, it's structural.

This gets sharper in enterprise setups where agents chain together, one agent's tool output feeding straight into another agent's input. A single compromised server, sitting anywhere in that chain, can push injected instructions downstream long before any person lays eyes on the results.

Most teams running these pipelines have no real-time log of which tool an agent actually invoked in a given session. The exploit finishes running well before anyone thinks to go check.

Supply-chain attacks through MCP package ecosystems

MCP servers mostly ship as packages, installed through npm or pip, with no signature verification standing between the package and production. That's a familiar supply-chain risk from other ecosystems, just wearing new clothes.

The attack vector is straightforward: a maintainer sells their account, or has a token stolen, or just decides to ship something backdoored, and malicious code goes out to every agent installation that pulls the update overnight.

This played out in 2025 with a package called Postmark-MCP. It mirrored a legitimate email tool through a string of clean releases, then it quietly exfiltrated message contents sent by any agent using it.

Astrix looked at 5,200 open-source MCP implementations and found 53% relying on insecure, long-lived static secrets, API keys and personal access tokens that don't expire and don't rotate. Those credentials become the payload the moment a package gets compromised. A separate 2026 audit found only 8.5% of public MCP servers use OAuth, meaning the overwhelming majority have no revocable, scoped credential to limit the damage once something like Postmark-MCP happens again.

The injection here isn't sitting in a prompt at all; it's sitting in code that handles execution. The outcome lines up exactly with everything above: the agent does things its operators never signed off on.

What empirical testing reveals about how often these attacks actually succeed

MCPTox, a benchmark published by researchers at the University of Science and Technology of China and Beihang University, is the first systematic attempt to measure how well agents hold up against tool poisoning under realistic conditions. It's built on 45 live MCP servers and 353 real tools, with over a thousand malicious test cases spread across 10 risk categories.

The headline number: a 36.5% average attack success rate across every model setting tested. That's better than a third of attempts landing.

Broken down by model, the pattern gets uncomfortable. o1-mini hit a 72.8% success rate. Phi-4 came in at 70.2%. GPT-4o-mini landed at 61.8%. Qwen3-32b, running in reasoning mode, hit 58.5%.

The counterintuitive part is the one worth remembering: stronger models were often easier to exploit, not harder. That tracks with the earlier point about instruction-following. The attack rides on the model's competence, not its ignorance. Claude-3.7-Sonnet posted the best refusal rate of anything tested, and even that came in under 3%. Safety alignment, as it currently exists, doesn't defend against a tool that's legitimate on paper being used for something it was never meant to do.

Bottom line: swapping in a more capable model doesn't shrink this risk. It can make it worse.

The infrastructure weaknesses that make exploitation easier once an injection lands

A 2026 audit found 79% of MCP servers handle credentials in plaintext. Once an injected instruction manages to reach a credential store, there's usually nothing encrypted standing in the way.

Equixly ran a scan of popular MCP servers in March 2025 and the numbers are rough: 43% had command-injection flaws, 22% allowed path traversal or let files get read that shouldn't be reachable, 30% were exploitable through SSRF, and a meaningful share had no authentication at all by default. When Equixly notified vendors, 45% dismissed the risks as theoretical or acceptable. Not fixed, not queued for a patch, just waved off.

Endor Labs scanned 2,614 implementations in 2025 and found 82% using file operations prone to path traversal. A separate 2026 audit found 40% of MCP servers still require no authentication whatsoever, meaning an injected instruction that reaches a file or database tool doesn't hit a credential wall on the way in.

CVE-2025-6514, rated 9.6 on CVSS, hit the widely used mcp-remote proxy package across more than 437,000 installed environments. It's the highest-severity MCP CVE on record so far. It wasn't alone, either: between January and February 2026, researchers filed more than 30 CVEs targeting MCP servers, clients, and infrastructure components.

The compounding logic is worth stating plainly. Prompt injection is what gets the agent to call the tool in the first place. These infrastructure gaps decide how much damage that one call is able to do once it's made.

Where in the MCP request lifecycle defenses actually have leverage

Go back to the lifecycle from the opening: input, planning, tool selection, execution, output. Each stage needs its own defense, because a fix at one stage doesn't cover the others.

At the input stage, validate and sanitize whatever the user supplies before it enters the model's context. Treat any external document the agent is about to read, a webpage, a ticket, an issue, a PDF, as potentially hostile until proven otherwise. That's not paranoia; it's the only posture that matches how indirect injection actually works.

At planning and tool selection, least-privilege scoping does real work: an agent should only see tool descriptions relevant to the task in front of it, which shrinks the surface available for a shadowing attack. Tool descriptions need cryptographic or hash-based integrity checks, not just at onboarding but at every subsequent refresh, since the rug-pull pattern lives entirely in that gap between initial approval and later execution. A registry of known-good schemas makes drift detectable: any deviation between what was registered and what's live in production should trigger a re-review automatically, not get waved through as business as usual.

At execution, role-based access control for agents needs to be a deliberate organizational decision, not a default inherited from whatever scopes were easiest to configure. What an agent can touch, which files, which databases, which external calls, should map to what its job actually requires, not to what's convenient to grant up front.

This is also the trust gap that centralized governance is built to close. Organizations running agents across multiple MCP servers need real-time visibility into which tools get called, by whom, and what data moves through each call, not a postmortem log discovered after something's already gone wrong. MCPManager's monitoring layer works at that governance checkpoint, auditing tool calls as they happen rather than reconstructing them weeks later from scattered logs. Given how often these incidents trace back to a gap between what was approved and what actually ran, that kind of checkpoint isn't a nice-to-have. It's the piece of the lifecycle every other defense on this list depends on actually being watched.