Data Exfiltration Risks in Agentic MCP Pipelines

Data exfiltration in an MCP pipeline doesn't need a hacker, a phishing email, or a stolen password. It happens through the normal, authorized tool calls an agent was built to make, which is exactly why most security teams can't see it coming. Anthropic introduced the Model Context Protocol in late 2024 as a common connector between language models and the outside world: file systems, databases, APIs, Slack, Stripe, GitHub, whatever a business runs on. It caught on fast. Public numbers put the ecosystem at over 10,000 public servers and 97 million monthly SDK downloads, with Anthropic, OpenAI, Google, and Microsoft now backing it.

What security researchers flagged early is a strange inversion. In most client-server systems, the client asks and the server answers inside a boundary someone drew on purpose. MCP often runs the other direction: servers query and act on behalf of clients, which flips the trust flow that firewalls, DLP tools, and access reviews were all built to assume.

Here's what that looks like in practice. A single agent session might connect to a dozen servers at once, a file system, a GitHub connector, a database, a Slack integration, each carrying its own permissions. The agent decides at runtime how to chain those tools together, and nobody reviews that chain before it runs. No approval step, no human in the loop, just execution. The result isn't a bug or an edge case. It's what the protocol does when it's working exactly as intended, and that's the part worth sitting with: the data leaving the building often looks identical to the data that's supposed to be there. Compare that to how security teams have always modeled exfiltration. Insider threat assumes a person went rogue. Perimeter defense assumes an outsider broke through a wall. MCP exfiltration requires neither. It rides through tool calls the agent had every right to make.

How trust gets established, and why that moment is the weakest point

MCP has exactly one moment where a human looks closely at a tool: connect-time, when an agent first registers a server and someone reviews what that tool claims to do. After that, every response the tool sends back goes straight into the model's context window with no equivalent check. That gap between reviewed once and trusted forever is the whole problem in miniature.

Authentication makes it worse. An internet-wide scan in July 2025 found 1,862 MCP servers sitting publicly accessible, answering unauthenticated tool-listing requests from anyone who asked. Research from Zuplo found 40% of MCP servers still require no authentication at all, 79% handle credentials in plaintext, and only 8.5% use OAuth. GitGuardian found 24,008 unique secrets sitting exposed in MCP-related configs on public GitHub, with 2,117 of them still valid when researchers checked.

Put those numbers together and the shape of the risk gets clear. An attacker doesn't need to touch the tool description that passed review. Control what the tool returns, and you control what the agent believes. Nobody has to break in. They just have to poison what comes back.

This isn't a flaw a patch fixes. It's a structural consequence of separating approval from execution inside a session that keeps running long after anyone looked at it. Every attack pattern that follows is a different way of walking through that same door.

Prompt injection as an exfiltration mechanism, how poisoned content rides legitimate tool calls

Prompt injection doesn't hide in the tool. It hides in the content the agent reads: an email, a document, a comment on a GitHub issue, the body of a support ticket. The agent treats that content as trusted context, because that's its job, and it acts on whatever instructions are buried inside.

Simon Willison named the underlying condition in June 2025: the "lethal trifecta." Private data, untrusted content, and an exfiltration channel, all present in the same agent session. Once those three line up, prompt injection stops being a quirky failure mode and becomes a live exfiltration event.

Three incidents from 2025 show the same pattern showing up on different surfaces. In one mid-2025 case, an AI assistant summarized a malicious email with no attachment and no link, no user interaction required, and the payload it ingested pulled data from connected cloud storage, sending it out through a trusted first-party domain where network monitoring had no reason to look. In August 2025, Invariant Labs documented an attack against the GitHub MCP server, a widely used connector with roughly 14,000 stars on GitHub. A malicious GitHub Issue carried the injection. The agent read it, followed the embedded instructions, and pulled data out of private repositories the user had authorized it to access. Nothing about the tool description was dirty. The poison sat in the data returned. Cato Networks documented a third case in June 2025 involving a Jira support ticket: an external attacker files a malicious ticket, an internal employee runs an AI action against it, and the injected instruction fires with that employee's own internal permissions, pulling data back out through the ticket itself. The attacker never touched the MCP server.

What ties these together matters more than any single case. The exfiltration channel is a tool the agent was legitimately allowed to use. No stolen credential, no network intrusion, nothing that looks like malware. That's also exactly why DLP and SIEM tools miss it: the outbound call looks like a normal API request from a trusted process. The anomaly lives in the meaning of the data, not in its behavior on the wire, and tools built to watch behavior don't read meaning.

Tool poisoning, when the attack lives inside the tool definition itself

Tool poisoning works differently. Here the malicious instructions sit inside the tool's own description, visible to the model but never shown to a human in any client interface. Since agents are trained to follow tool metadata closely, the attack just runs, quietly, every time.

Invariant Labs coined the term in April 2025, with a proof of concept that's worth walking through slowly. A tool labeled as a simple "add" function performed addition exactly as advertised, and at the same time exfiltrated an mcp.json config file along with SSH keys. The tool did its job and stole from the user in the same call.

The scale here is bigger than one demo suggests. The MCPTox benchmark built 1,312 malicious test cases across 45 real MCP servers and 353 tools, and found attack success rates as high as 72.8% across 20 different LLM agents. A subtler variant called MCP-ITP, for implicit tool poisoning, manipulates model behavior through metadata alone, without ever invoking an obviously malicious tool call, and hit an 84.2% success rate. That number should give pause: the agent gets redirected without a single suspicious entry showing up in the logs. A related attack class called LOG-TO-LEAK exploits a malicious logging tool that quietly captures user queries and tool responses as they pass through, hitting high success rates across five real MCP servers and four different models (GPT-4o, GPT-5, Claude Sonnet 4, GPT-OSS-120b) without ever degrading the visible quality of the agent's work. The task looks done. It is done. Data just left with it.

Invariant also documented a cross-server case in April 2025 involving a trivia game MCP server that carried hidden instructions aimed at a second, entirely legitimate WhatsApp MCP server running in the same session. The agent pulled WhatsApp history through the trusted server and leaked it out as ordinary traffic. End-to-end encryption didn't matter here, because the exfiltration happened above the encryption layer entirely, inside the agent's own reasoning. Separately, an evaluation of seven widely used MCP clients found some, Cursor among them, showed high susceptibility to cross-tool poisoning, hidden parameter exploitation, and unauthorized tool invocation. Client-side defenses across the ecosystem remain inconsistent at best.

Rug pull attacks and supply chain substitution, exfiltration that arrives after approval

A rug pull follows its own timeline. A server passes review, gets added to a config file, and runs cleanly for days or weeks. Then an update ships that swaps the tool's description for something malicious, and most MCP hosts bind their trust to the tool's name rather than its content, so the change sails through without a re-prompt.

MCP makes this especially easy to pull off because tool descriptions are just text. A one-line addition to a docstring is enough. No compiled binary, no native library, nothing a standard code review would catch. This was formalized as an exploitable vulnerability class with CVE-2025-54136, nicknamed MCPoison, carrying a CVSS score of 8.8, with findings showing that Cursor kept trusting an approved config key even after the command behind it had been swapped out entirely.

The postmark-mcp incident from September 2025 is the clearest real-world case so far: a malicious npm package silently BCC'd every email it processed to an attacker-controlled address. It shipped at around 1,500 downloads a week and reached roughly 300 real organizations before anyone caught it, marking the first publicly documented malicious MCP server in the wild. Then in January 2026, more than 2,000 exposed MCP instances turned up leaking API keys and conversation histories to anyone who bothered to search Shodan for them.

None of this fits inside a one-time approval process. A control designed to check something once cannot stop an attack that's specifically built to wait until after the check is over. Tool content needs watching continuously, not just at the moment it's introduced.

Cross-server shadowing and the multi-tool session as an exfiltration amplifier

Cross-server shadowing is subtler still. A malicious server doesn't replace a legitimate tool outright. It manipulates the ranking and preference signals the agent uses to pick between tools, so calls quietly route through the attacker's server instead of the one the user thinks they're using. The user's available functionality never changes. The call graph underneath it does.

A related trick, a related pattern has an attacker publish a server under a name close enough to a legitimate one to fool a quick glance, or a developer spins up an unreviewed server outside any approval process at all. OWASP tracks these under the label "shadow MCP servers," the MCP-specific face of the shadow AI problem security teams already know from unsanctioned SaaS tools. A study covering 67,057 servers across six public registries found conditions ripe for server hijacking and call manipulation spread across the ecosystem, which is the problem MCPManager, Usercentrics' AI data-access governance layer, was built to address. A separate tool, MCPInspect, flagged 833 vulnerable servers and 18 with outright suspicious descriptions during pre-integration analysis.

The amplification effect is the part worth remembering. Because one agent session touches many servers at once, a single compromised server can ride the permissions of every other trusted server sitting in that same session. The blast radius scales with how many tools the agent has access to, not with what the compromised server itself was ever allowed to do. That's precisely why the "treat every server as untrusted" posture the Cloud Security Alliance recommends is so hard to execute through individual server audits alone. Auditing servers one at a time tells you nothing about what happens when several of them sit in the same room together.

Exfiltration without an adversary, how legitimate pipelines leak data by design

None of this requires an attacker at all. Set an agent loose to migrate records, summarize documents, or enrich CRM entries, and it can legitimately touch, combine, and send data that no single human at the company would ever be cleared to see all at once.

The mechanism here is permission accumulation. Agents inherit the credentials of whoever's running them, plus whatever access every connected MCP server carries, and nothing in that stack stops to ask whether combining those permissions crosses a line that data governance policy actually cares about. An agent working across an HR data server and a Slack server to draft company-wide messages isn't breaking any single rule. The exposure comes from the combination, not any one step in isolation. An agent that writes summarized records into a logging server outside the region a data residency policy requires has the same problem, just on a different axis. And an agent that inherits something like a Supabase service_role key, the kind that bypasses row-level security entirely, doesn't need to be tricked into misusing it. It just needs to have it.

This kind of leak is genuinely harder to catch than the adversarial kind, precisely because nothing about it looks wrong. No injected instruction, no strange tool call, no malicious server anywhere in the chain. Just authorized operations landing on an outcome nobody authorized.

Scale is what turns this from a nuisance into an emergency. IDC projects active enterprise AI agents growing from 28.6 million in 2025 to more than 2.2 billion by 2030. At that volume, quiet pipeline leakage stops being a rare misstep and becomes a systemic governance failure. Cisco's State of AI Security report for 2026 found only 29% of organizations feel prepared to secure their agent deployments, and that gap between how fast agents are shipping and how ready anyone is to watch them is exactly where this kind of leakage piles up, unnoticed, one authorized data pull at a time.

Why conventional security controls cannot see these exfiltration paths

Perimeter defense and DLP were both built on an assumption: data leaves through channels with recognizable signatures. MCP breaks that assumption at the root, because the traffic runs through authorized API calls made by trusted processes. There's no signature to catch, because nothing about the call itself looks wrong.

SIEM correlation depends on behavioral baselines built from how humans use systems, and agents don't fit that mold at all. A single agent session can rack up more tool calls in a few minutes than a human analyst makes API requests in a week, which means there's no meaningful baseline to measure "unusual" against in the first place.

Static code review and one-time server audits miss a fairly specific list of things: content injected into a tool's response at runtime, tool descriptions that get swapped out after approval, interactions between servers that only emerge once a session is running, and data combinations that cross a policy boundary without any single call ever looking anomalous on its own. The NSA has described MCP's inverted trust model, servers acting on behalf of clients, as producing attack paths that are largely not well traced. And even implementations that pass a clean audit come with a logging problem baked in: analysis has found 82% of MCP implementations use file operations prone to path traversal, and 67% use APIs tied to code injection risk. But even where the code itself is clean, the logs it produces record which tool got called, not what data moved through it or how the agent chained several calls together into something that adds up to exfiltration.

Real visibility here means something more specific than a tool-invocation log. It means a live record of what data each call touched, what it got combined with, and which trust boundary it crossed on the way out.

What governance mechanisms actually interrupt agentic exfiltration paths

A centralized MCP gateway is the foundational piece, because it's the only point in the whole architecture where cross-server interactions, runtime content, and data flow are all visible at the same time. Without one, every server sits in its own blind spot, and nobody's watching the space between them, which is exactly where most of these attacks live.

Server registries matter just as much as the gateway itself. Every MCP server an agent touches needs an entry somewhere, because a server with no registry record is an identity nobody can audit, revoke, or hold accountable when something goes wrong. The OX Security disclosure made this concrete: 200,000 vulnerable instances turned up across a supply chain with more than 150 million package downloads, existing largely because nobody had kept an account of what was actually running.

Tool content needs continuous checking, not a single approval that lasts forever. Tool descriptions should get hashed and reverified at the start of each session, not just once at registration, and any change to a description ought to trigger a fresh review rather than sliding through silently. That single design choice, verify content instead of trusting a name, is the difference between catching a rug pull attack like CVE-2025-54136 and missing it entirely.

Access control needs to shift too, scoped to the agent's own identity rather than inherited wholesale from whoever's operating it. An agent that only carries the permissions it actually needs for its task can't accumulate the kind of cross-server reach that turns a single compromised server into an organization-wide breach. That's the whole lesson sitting underneath every case above: the danger was never a single broken tool. It's what happens when tools, sessions, and permissions all add up in a room nobody's watching.