Data Exfiltration Risks from MCP Tool Calls

A tool call is not a passive query. It is an instruction the agent executes against real systems, using real credentials, on behalf of whoever or whatever told it to act. Most MCP threat discussions bury that fact in footnotes, which is exactly where it doesn't belong.

MCP servers aggregate access in ways that would make any seasoned IAM engineer wince. One server routinely holds OAuth tokens for multiple downstream services, database credentials, file read permissions, and sometimes system command access, all simultaneously. That aggregation is why a single compromised tool call can be so destructive. Convenient architecture has a cost.

Tool descriptions are not documentation. They are executable context. When an agent reads a tool's description to decide what to invoke next, that description shapes the action that follows. The exfiltration path is a chain: data gets fetched, staged, transmitted. Each step, in isolation, looks routine. An agent legitimately pulling customer records and an agent exfiltrating those same records through a compromised tool call are, at the per-call level, functionally indistinguishable. The harm lives in the sequence, not in any single call. Keyword filters and per-call inspection cannot see sequences. That is precisely why they miss this class of attack entirely.

How Prompt Injection Turns Tool Calls Into Exfiltration Triggers

Prompt injection, in the MCP context, has nothing to do with tampering with the tool itself. It is malicious content embedded in data the agent reads: a document, a GitHub issue, an email, a database field. The embedded content redirects the agent's next tool call. The tool never changes; only what the agent is told to do with it does.

In May 2025, Invariant Labs documented a GitHub MCP server incident that illustrated this with uncomfortable clarity. An agent read a malicious GitHub Issue. Instructions embedded in that issue caused the agent to exfiltrate private repository contents the user had already authorized it to access. The tool descriptions were clean. The poisoning lived entirely in the data the tool returned. Legitimate read, injected instruction, unauthorized exfiltration, all within normal operational parameters.

EchoLeak, catalogued as CVE-2025-32711 with a CVSS score of 9.3, pushed that pattern further than most people expected. It was the first publicly documented zero-click attack on an AI agent: Microsoft 365 Copilot exfiltrating sensitive data through hidden prompts embedded in content the user never deliberately opened. No user action required. When exfiltration can complete before detection even begins, logging after the fact is not a defense; it's a forensics exercise.

The NSA's AI Security Center, in its May 2025 guidance, specifically flagged serialization vulnerabilities as prime injection targets. How data is structured and passed between agent and host is itself a payload carrier. That observation rules out content scanning as a meaningful defense. The channel carries the attack just as readily as the content does.

Tool Poisoning and Rug Pulls: When the Tool Itself Is the Attacker

Tool poisoning is malicious logic embedded in a tool's description or behavior, the kind that causes an agent to act against user intent while appearing to function normally. The rug pull is the temporal variant: the tool behaves legitimately at installation, earns trust and permissions, and then quietly updates its own definition after authorization has already been granted.

MCP servers can update tool definitions without notifying the client. Most clients do not flag or detect those changes. The consent that was given at installation is now governing something it never evaluated. That is not a theoretical risk; it is how the authorization model was built.

Invariant Labs demonstrated this concretely in 2025 using a WhatsApp MCP server. A malicious server, co-located in the same agent context as a legitimate WhatsApp server, used tool poisoning to silently read and export a user's entire message history. The attack worked because of the co-location itself. Once trusted and untrusted servers share an agent context, the trust boundary collapses. A 2025 analysis by MintMCP found roughly 5.5% of public MCP servers to be tool-poisoning-vulnerable, and that percentage translates to a larger absolute number every week as total server count grows.

What rug pulls expose about the approval model is genuinely uncomfortable. User consent at installation is a point-in-time decision made about a specific tool state. A governance framework that fails to continuously track tool definitions against their approved baselines has no mechanism to detect the attack. The approval process gets weaponized against itself.

Confused Deputy Attacks and How MCP Servers Become Overprivileged Proxies

The confused deputy problem is not a misconfiguration you can patch. It is structural to how MCP servers operate. The server executes actions using its own elevated credentials, not the requesting user's. So a user without database administrator access can ask the agent to run an admin-level query, and the server, which does hold admin credentials, complies, without any interrogation of whether that user should have that capability. The server acts as deputy for everyone simultaneously, which is another way of saying it has no real principal at all.

Credential aggregation multiplies the blast radius. Because MCP servers store OAuth tokens for multiple downstream services, every client that connects inherits the same privileged access profile. One compromised client becomes a problem for every other client on that server.

CVE-2025-13341 confirmed this failure at production scale: indirect prompt injection against the Kong Konnect MCP server caused it to execute unintended API requests on the caller's behalf. The Asana cross-tenant incident in June 2025 showed the organizational dimension. A bug caused project data from approximately 1,000 organizations to bleed across MCP instances, and Asana had to pull the integration offline for two weeks. The failure did not respect user or tenant boundaries. It propagated across everything the server touched.

Microsoft's CVE-2025-21520, disclosed in 2025 for Copilot Studio, addressed a specific data exfiltration path created by indirect prompt injection. Capsule Security noted at the time that assigning a CVE to a prompt injection in an agentic platform was "highly unusual." That shift, from treating prompt injection as operational friction to treating it as a reportable vulnerability, is meaningful. It moves remediation responsibility from user to vendor, which is where it belongs.

Authentication Gaps That Leave Tool Calls Ungoverned

MCP's November 2025 specification mandates OAuth 2.1 with PKCE for remote HTTP connections. Local stdio connections inherit environment credentials. That's the specification. The implementation reality diverges significantly.

Trend Micro found that 38% of MCP servers lack authentication entirely and identified 492 MCP servers exposed to the internet with no authentication at all. CVE-2025-6514, scored at CVSS 9.6 by JFrog Security Research, illustrates what that exposure actually means in practice. The mcp-remote OAuth proxy passed authorization endpoint URLs directly to the OS open() function without sanitization, which meant a malicious server could supply a crafted value that executed arbitrary shell commands on the connecting machine. Connecting was enough. No bypass required. CVE-2025-49596, scored at 9.4, achieved unauthenticated remote code execution through MCP Inspector, the debugging tool itself becoming the entry point.

Token scope is the deeper problem. MCP servers routinely hold tokens with broad permissions covering files, databases, and administrative functions. Long-lived tokens with wide scope mean that a single compromise equals full access across every system the server touches. There's no proportionality, no containment. Without identity tied to individual tool calls, there is no audit trail, no mechanism for reconstructing what was invoked and by whom, and no way to enforce that a given user's request stays within that user's actual permission set. You can't govern what you can't attribute.

Supply Chain Attacks That Distribute the Exfiltration Path to Every User of a Package

In September 2025, the maintainer of the official Postmark MCP server added BCC logic that silently copied every outbound email to an attacker-controlled address. It ran undetected for two weeks. The package was signed. The signature confirmed authorship; it said nothing at all about what the code did.

One month later, a path-traversal vulnerability in the Smithery deployment platform allowed an attacker to read environment files containing API keys, database credentials, and OAuth secrets across more than 3,000 deployed MCP applications. One platform-level vulnerability, instantaneously multiplied across thousands of downstream deployments.

Between September and November 2025, a self-replicating worm hit 796 packages with combined monthly downloads of 132 million, specifically targeting MCP server packages. The mechanism was almost elegant in a grim way: it stole credentials, used those credentials to publish malicious versions of every package the compromised maintainer owned, and propagated through ecosystem trust relationships rather than fighting through any security perimeter. No one had to click anything suspicious. The attack moved through the exact channels people relied on.

The structural logic is consistent across all three incidents. A supply chain attack converts a deployment-level trust problem into a distribution-level one. Downstream users inherit the exfiltration logic without doing anything wrong. They install what every reasonable indicator suggests is a legitimate, signed, official package. The attack reaches them specifically because they followed the right procedures.

Shadow MCP Usage and the Audit Gap It Creates

Shadow MCP usage is what happens when engineering teams and individual contributors connect MCP servers to enterprise systems without security review, without inventory, without any visibility from the people responsible for data governance. Those connections don't appear in any asset register. They have no revocation path. When one is compromised, there is frequently no record that it existed.

This is not a gap trending toward closure. It is a gap actively widening as deployment outpaces oversight. Every untracked MCP server is a blind spot where overprivileged access, supply chain exposure, and active exfiltration can occur without generating any detection signal.

The NSA's AI Security Center framed this as systemic in its May 2025 guidance, stating plainly that established cyber defense strategies do not adequately address dynamic tool invocation and implicit trust relationships. That is a significant admission. The architecture creates implicit trust by default; governance has to be built on top of it explicitly, applied to every server, including every server nobody approved. Without an inventory of what MCP servers are connected to enterprise systems, identity attached to every tool call, and policies enforced at the moment of invocation rather than reviewed after the fact, the audit gap is not a documentation problem. It is a control problem.

What Closing the Exfiltration Path Actually Requires

The attacks covered here, prompt injection, tool poisoning, confused deputy, authentication failure, supply chain compromise, shadow usage, do not reduce to variations on a single root cause. Each exploits a structurally distinct gap. Addressing one leaves the others fully intact, which is why point solutions have been so consistently insufficient.

Per-call identity is the foundation. Every tool call needs the requesting user's identity attached, not just the server's credentials. Without that, there is no meaningful audit trail, and no mechanism for enforcing that a user's request stays within that user's permission boundary. Anything built on top of a permissioning model that lacks per-call identity is, at best, decorative.

Runtime-scoped credentials follow from that. Agent credentials should be issued per-task and expire on the timescale of the task itself. Long-lived API keys with broad scope mean every compromise reaches maximum blast radius by default. Short-lived, scoped credentials force an explicit policy decision at the moment of action and constrain what a compromised token can actually touch.

The sequence problem requires a different kind of enforcement. Governance that can recognize read-then-stage-then-transmit as an exfiltration pattern, even when each individual call looks benign, is categorically different from per-call inspection. Detection logic has to match the shape of the attack, and these attacks are sequential by nature.

Tool poisoning and rug pulls require server inventory with continuous change tracking. Without a baseline capturing what tool definitions looked like at the time of approval, silent changes are invisible. Approval records have to include tool state, and that state has to be monitored for drift. A static approval process is inadequate for a system designed to update itself dynamically.

Prompt injection and intent drift require reasoning about agent behavior, rather than traffic signatures. These attacks don't look like traditional intrusion attempts. The detection layer has to understand what the agent was supposed to do versus what it actually did, and that requires behavioral context most current security tooling fails to capture.

Tamper-proof audit logs with full tool-call context, capturing the identity of the requester, the tool invoked, the parameters passed, and the data returned, are not a nice-to-have. The NSA's May 2025 guidance identified the absence of such logging as a documented gap in current practice. Without them, post-incident reconstruction is guesswork dressed up as forensics.

The path from prompt injection to tool invocation to data exfiltration is well-documented at this point. The controls exist. What hasn't happened is their consistent application across every MCP connection in the enterprise, including every server nobody approved and nobody is watching. That's the actual problem. Everything else is commentary.