Data Exfiltration Risks from MCP Tool Calls

MCP exfiltration risk originates in a design decision rather than a developer mistake. The Model Context Protocol, introduced by Anthropic in November 2024, connects AI hosts to external tools, APIs, databases, files, and workflows through standardized servers, and academic threat modeling describes the LLM in this setup as an intermediary decision-maker rather than a passive text generator. That distinction matters because the protocol mixes tool instructions and data in the same channel: anything that can alter a tool's metadata can redirect an agent's behavior just as effectively as rewriting its system prompt.

This breaks assumptions that security teams have relied on: firewalls, web application firewalls, and static role-based access control all work by inspecting network traffic and API calls, checking whether a request is allowed to happen. None of them can inspect the semantic intent sitting behind a tool call that looks completely legitimate on the wire. A malicious instruction riding inside a tool description produces the exact same HTTPS traffic as a benign one, because the channel carrying the instruction is the same channel carrying the data.

The scale of this is now documented, not speculative. CoSAI's January 2026 whitepaper catalogues roughly 40 distinct threats spread across 12 core threat categories tied directly to MCP's architecture. It is a map of the pathways the protocol's design opens up by default, not a list of configuration errors enterprises can patch one by one.

MCP's own security guidance pushes back on this framing, treating the problem as implementation-level: sanitization and scoping, in this view, are the developer's job, and Anthropic held to that position when it declined to modify the protocol after OX Security's April 2026 disclosure. Calling it a developer responsibility just moves accountability onto whoever deployed the server, without closing a single pathway through which data can leave. The incidents detailed in the sections that follow show what happens when that gap goes unaddressed. Understanding how the architecture creates these pathways is the first step toward controlling any of them.

Tool Poisoning, Prompt Injection, and Exfiltration

Tool poisoning is the most common and most damaging client-side weakness in MCP deployments, and the reason is simple: the model treats tool descriptions as trusted instructions, while the person using the agent never sees those descriptions at all. A tool can carry hidden text instructing the model to forward data somewhere, and the user approving that tool's use has no way to read what they're approving.

This isn't theoretical: when seven major MCP clients were threat-modeled, five of the seven did not implement static validation of server-provided metadata, largely because the MCP specification itself does not require that validation. Two separate injection paths follow from that gap. Tool metadata poisoning hides malicious instructions inside tool descriptions, parameters, or schema definitions, so the model processes those instructions before you ever interact with the tool. Indirect prompt injection works through retrieved content instead, planting instructions inside tickets, files, notes, logs, or documentation that the model then treats as a higher-priority command than the user's actual request. A related variant, full schema poisoning, goes a step further by compromising entire tool schema definitions so that hidden parameters and altered return types affect every future call to that tool while still looking legitimate to anything monitoring the traffic.

Existing security controls miss all of this for one reason: the exfiltration happens through a completely valid HTTPS call invoking a tool that looks exactly like it's supposed to. Web application firewalls and data loss prevention tools inspect the shape of a request, not the intent driving it, so they have no way to flag the call as malicious. The call succeeds, the data moves, and the systems built to catch this kind of event don't flag anything.

Rug pull attacks and the gap between one-time approval and ongoing tool behavior

A rug pull attack works because MCP has no built-in way to detect when a tool's definition changes after a user has already approved it. A server can expose a set of harmless tools, earn a one-time approval from a user, and then quietly alter its tool definitions, descriptions, or behavior afterward. Nothing on the client side stores a version number, a content hash, or a snapshot of what was approved at the time of approval, so there's no baseline to compare against later.

The postmark-mcp incident from September 2025 shows what this class of failure looks like in practice. A single malicious npm package silently added an attacker-controlled address to the BCC line of every outbound email it handled, and it ran for roughly a week before anyone caught it. So supply-chain compromise at install time left you with the same invisible exfiltration you'd get from a post-approval definition change.

The postmark-mcp case was a package compromised at first install, not a confirmed instance of a server changing its definition after approval. As of April 2026, the rug pull attack is well documented as a live proof-of-concept, named in academic work and in vendor threat matrices, but no confirmed in-the-wild incident against a production MCP deployment with named victims had been publicly disclosed. That distinction shapes how enterprises should weigh the cost of defenses like versioning, mandatory re-approval workflows, and definition hashing: the risk is real enough to document and name, even without a headline production breach yet attached to it.

Shadow MCP servers make the whole problem harder to see coming. The CoSAI whitepaper flags unauthorized, unmonitored server instances as a distinct risk, because they create blind spots where definition drift can't be detected in the first place, let alone responded to. A server nobody knows is running is a server nobody is watching for changes.

The authentication gap and exfiltrated data's permanent exit route

Once data has been redirected through a poisoned tool or a drifted definition, what happens next depends on the credential behind the call. Static API keys with no expiry and no scope enforcement mean that once a tool call is made, the credential it uses can persist and be reused long after the original access was intended to end.

Only a small fraction of MCP servers actually use OAuth. The large majority store static API keys in.env files, mcp.json configuration files, and plain environment variables. These keys don't expire on their own. When a developer leaves a company, the credentials tied to their MCP setup keep working indefinitely, turning what looks like a one-time deployment decision into a standing liability for as long as the key exists.

The protocol's own authorization specification defines an OAuth 2.1 framework, but implementations don't have to use it. In practice, a large number of deployed servers accept connections and hand over full tool listings without checking any credential at all. Two confirmed vulnerabilities put numbers on how serious this gets. CVE-2026-32211, carrying a CVSS score of 9.1 and disclosed in April 2026, let attackers bypass authentication on Azure MCP Server and pull API keys and tokens without presenting any credentials. CVE-2026-33032, with a CVSS score of 9.8 and disclosed in March 2026, found that nginx-ui's MCP integration failed to authenticate command execution requests at its message endpoint entirely. Trend Micro scanned the open internet in February 2026 and found hundreds of MCP servers running with no authentication at all.

The protocol did take a step forward. The MCP revision dated 2026-07-28 made per-request authorization checks cheaper to run, and now agent identity is explicit on every request. So now you can tell which piece of software made a given call. It does nothing for knowing which person was behind it: the revision left the human-attribution gap untouched, and the protocol still has no field for the person who caused the action. That gap carries forward into everything the next two sections describe.

Over-permissioned connectors, multi-agent workflows, and lateral access from one tool call

Permissions on MCP tools rarely get scoped down to what the tool actually needs. A tool built to read one table in a database often ends up holding write access to the entire database, because nobody revisited the credential after the initial build. Any agent that calls that tool inherits the full, unintended permission set that comes with it, not just the narrow slice of access the tool was supposed to use.

That problem compounds as soon as agents start talking to each other. As enterprises connect multiple MCP servers across a single workflow, each tool's excess permissions become available to every downstream agent in that chain. If you built an over-permissioned connector months ago for one narrow purpose, it can end up reachable from an entirely different agent doing an entirely different job. Cascading prompt injection makes the exposure worse still: one agent's output becomes the next agent's input, so malicious content planted at one point in the chain can propagate forward, producing unauthorized behavior, data exfiltration, or control-flow hijacking somewhere downstream from where the injection actually happened.

The ClawHavoc campaign, active in February 2026 alongside nine separate OpenClaw CVEs, shows this at ecosystem scale. Malicious packages entered through the ClawHub marketplace and, at the campaign's peak, one in five packages across the entire ecosystem was malicious. The Sentry MCP agentjacking case shows a tighter, more targeted version of the same dynamic: event injection through Sentry's MCP integration exposed thousands of organizations with injectable DSNs, and controlled testing confirmed agent execution at a significant share of them, exploiting the implicit trust between Sentry's event data and the AI coding agents reading it.

Checkmarx's 2026 analysis names this the full chain of delegation: who the user is, which MCP client is acting on their behalf, which server is being called, what token is authorizing the call, what resource gets touched, and whether that specific tool action is actually authorized for that specific context. Every link in that chain is a separate point where data can leave the building. Chaining agents together doesn't just add convenience. It multiplies the number of places an attacker only needs to compromise once.

Why existing detection and logging tools cannot see MCP-driven exfiltration

Most MCP-driven exfiltration leaves no trace in the tools enterprises already run, because it travels over legitimate HTTPS connections, invokes valid tools, and in most deployments produces no structured record at all. Web application firewalls, data loss prevention software, SIEMs, and API gateways all share the same blind spot: none of them can tell whether the intent behind an agent's tool call is malicious, because the traffic is indistinguishable from any other authorized use of that same tool.

In most deployments, there's simply no log tying a specific agent to a specific tool call, no record of what parameters it sent, what data came back, or whether the server's behavior matched what it was supposed to do. The gap runs deeper than that, down to the level of who is responsible. The MCP revision from 2026-07-28 made agent identity explicit on every request, and the OAuth token attached to a call already carries the account it belongs to. But the person who caused the action has no field in the record at all. An audit log, at best, can name the software that made the call and the account it ran under. It cannot name the human who decided to make it.

That absence has a direct consequence. When an MCP server reads a large volume of customer records and sends them to an external endpoint, in most deployments nobody logs the event, so no record survives for forensic review or compliance purposes. Without that record, there's no way to reconstruct what happened after the fact, no way to prove to an auditor or a regulator what data moved, when, and under whose authority.

The EU AI Act, audit-trail requirements, and enterprises running MCP-connected agents today

That missing record stops being just an operational blind spot once regulation enters the picture. Article 12 of the EU AI Act requires that high-risk AI systems be able to automatically record events and logs over the system's lifetime, and it requires those logs to be retained for at least six months. The categories the Act treats as high-risk, employment, lending, healthcare, and essential services, are precisely the domains where enterprises are already deploying AI agents wired into MCP-connected tools. Penalties for falling short of these requirements reach up to three percent of a company's global annual turnover.

The EU AI Act isn't the only framework asking for this. SOC 2, HIPAA, and GDPR all require audit trails covering system access, and MCP deployments at most organizations currently have nothing in place that meets those standards. A majority of organizations report fragmented logs scattered across separate systems, and 33 percent say they have no audit trails of evidence quality for their AI operations at all. So the compliance gap already exists at scale, and no enforcement action has even begun yet.

The practical risk this creates is direct. If an agent queried customer data and the organization cannot produce an attributable record of that query, the absence of that record can itself count as a compliance failure under the Act. If you have no proof, you're treated as if you did something wrong.

Gartner analyst Aaron Lord's projection points to where this is headed. A growing share of enterprise GenAI applications, up from a small baseline in 2025, is projected to have at least one major security incident per year by 2029, and roughly a quarter are projected to face at least five minor security incidents per year by 2028. That's a planning signal, not a guarantee, and it points toward a future where regulators and auditors ask for proof of working controls, not a description of good intentions.

A Control Architecture for the Pathways

Every pathway traced through this piece shares the same shape: a point where instructions and data mix, a point where approval doesn't carry forward in time, a point where a credential outlives its purpose, a point where permission exceeds the task, and a point where nothing gets written down.

You need to validate tool metadata and schema definitions before the model ever processes them, not after a user reports something odd. You need to treat every approval as time-bound, with a stored hash or version the client checks on every subsequent call, so a server can't quietly change its own behavior after winning trust. You need to replace static, non-expiring API keys with authorization that actually gets enforced, scoped tightly to what each tool needs rather than what's convenient to grant. It means tracking the full chain of delegation Checkmarx describes, who the user is, which client is acting, which server is called, what token is used, what resource is accessed, and whether the action is authorized for that context, as one continuous record instead of five disconnected ones. And it means closing the human-attribution gap directly, logging not just which agent and which account made a call, but which person set that chain of events in motion.

None of that is a workaround bolted onto MCP from the outside. It's a response built to match the actual shape of the protocol, tool-call depth, identity at every request, and a record that survives the transaction long enough to answer for it later.