Data Exfiltration Through LLM Tool Calls

There's a mental model most security professionals carry into every conversation about data loss, and it goes something like this: first, an attacker gets in; then, separately, they take something out. Those are two distinct events, two distinct forensic signals, two distinct opportunities to intervene. That model has held up reasonably well for decades of network security work. It does not hold up for tool-enabled LLM agents, and understanding exactly why it breaks is the necessary starting point for everything else.

When a large language model can send emails, query databases, browse the web, read files, or call external APIs, the outbound action is the feature. It is what the system was built to do. So when a malicious instruction causes the agent to encode sensitive data into a URL parameter and fetch that URL, the fetch is simultaneously the normal operation and the exfiltration. There is no second step. There is no anomalous outbound connection following a compromise. The exfiltration and the intended behavior are a single, authorized event.

This is not a bug in any particular product. It is a structural consequence of what tool use means architecturally. The agent holds credentials, has network access, and is explicitly trusted to route data outward. That trust is the mechanism an attacker exploits, and no vendor can patch their way out of it without removing the capability entirely.

The scale of what's actually flowing through these systems makes this more than academic. Cyberhaven's 2025 AI Adoption and Risk Report analyzed real usage across seven million workers and found that 34.8% of the corporate data employees input into AI tools is classified as sensitive, more than triple the share observed two years prior. The leading categories are source code at 18.7%, R&D materials at 17.1%, and sales and marketing data at 10.7%. That data is now flowing through agents that can act on it. Not just summarize it. Act on it.

The detection paradox follows directly from the architecture. A security tool scanning for anomalous outbound traffic sees an authorized API call. A data loss prevention tool watching for sensitive data leaving the perimeter sees a normal tool invocation. At every layer a traditional security tool can observe, the malicious instruction and the legitimate instruction produce identical behavior. That's the problem. Everything else that follows is a variation on it.

Indirect prompt injection as the delivery mechanism that makes the channel exploitable

If the channel is the feature, the attacker's first problem is getting an instruction into the model in the first place. The naive version of this, a user typing something malicious into a chat interface, is what most people picture when they hear "prompt injection." That's direct injection, and it's largely a solved problem: you can't type into a box you don't have access to.

The more dangerous form is indirect. The attacker doesn't interact with the model at all. Instead, they embed malicious instructions in content the agent will retrieve and process: a document it's asked to summarize, a web page it browses, an email it reads, a calendar invite, a database record, a code comment. The user never sees the injected text. The model executes it anyway, because from the model's perspective, text is text. Retrieved content carries the same instructional weight as the system prompt. There is no native hierarchy.

This is the part that lands differently when you've worked closely with how these systems process information versus when you read about it abstractly. The model doesn't have a "this came from an external source, treat it skeptically" mode baked in. It processes tokens. The source of those tokens doesn't fundamentally alter how they're interpreted.

Attackers have gotten sophisticated about encoding these instructions to survive preprocessing. Base64 strings, hidden Unicode characters, whitespace-based steganography, HTML comments that a browser renders invisibly but a model reads, all of these are techniques in active use. The instruction survives rendering while remaining executable by the model.

The UK's National Cyber Security Centre has assessed this class of attack as one that will never be fully fixed, because it is a property of how language models process text, not a patchable code error. That's a sober statement from an organization that is not given to hyperbole, and it's worth sitting with.

What the injection actually tells the model to do is usually something like this: read a specific file in your context, encode its contents as a Base64 string, and pass that string as a parameter in the next tool call you make. The data doesn't leave through a backdoor. It leaves in the call itself. The following sections describe exactly how.

The specific mechanics of how data encodes into tool calls, URLs, and API arguments

The basic pattern has three steps: the injected instruction tells the agent to read a resource in its context, encode the content, and embed it in the next tool invocation. Everything that follows is a variation on which encoding and which tool invocation.

URL-based exfiltration is probably the cleanest illustration of how unassuming this looks. An agent instructed to render a summary with a "source link" can encode data into the URL itself, either as a query parameter, a path segment, or a subdomain label in a DNS lookup. When the user or the system fetches that URL, the request carries the payload to an attacker-controlled server. The server logs the inbound request. No response is needed. The data has already arrived.

The Slack AI incident in August 2024 demonstrated this in a production environment. Adversarial instructions embedded in a public Slack channel caused Slack AI to encode private-channel content inside URLs it rendered as links. The data left the system inside what looked, to any observer, like normal conversational output. There was no alert, no anomaly, no second event.

API argument stuffing works through a different surface. Sensitive values get passed as ostensibly legitimate query parameters, webhook payloads, or form fields in a call the agent was already authorized to make. The authentication passes because the agent has valid credentials. The destination is often a legitimate-looking domain. The payload is encoded. A SIEM has no signature to match against any of it.

Email and calendar tool abuse is the most immediately legible to non-technical stakeholders, because it maps to something intuitive. An agent instructed to send a summary to an "additional recipient," the attacker's address, with sensitive content in the body or attachment is doing something that looks exactly like a valid email operation. It is a valid email operation. The authorization model cannot distinguish between the two, because both are within the agent's normal operational scope.

What all of these routes share is that they terminate at an attacker-controlled endpoint: a server, an email address, a DNS resolver. No callback to the user environment is required. The exfiltration is complete the moment the outbound call is made.

MCP tool poisoning and the rug-pull: when the tool definition itself is the attack

Model Context Protocol, the open standard that wires tools to agents, has seen rapid adoption across coding assistants, enterprise copilots, and customer-service agents. Microsoft 365 Copilot, GitHub Copilot, Cursor IDE, Slack AI, Supabase: these are production systems at scale. MCP is the plumbing underneath many of them. Which means a structural vulnerability in MCP's design is a structural vulnerability in a significant portion of the enterprise AI stack.

Here's the design detail that matters: MCP tool descriptions are plain text the agent reads to decide which tool to invoke and how. There is no sandbox around that text. There is no signature. There is no integrity check. The agent reads the description the same way it reads everything else, as tokens, as potential instructions.

Tool poisoning exploits this directly. Malicious instructions embedded in a tool's description field get executed by the agent when it reads the description to plan its next action. A proof of concept published in April 2025 hid instructions in a calculator tool's description and caused the Cursor editor to read a user's private SSH key and transmit it to an external endpoint. No user interaction required. The same research demonstrated exfiltration of private repository contents and message histories through the same mechanism.

The rug-pull variant is subtler and, in some ways, more insidious. A malicious MCP server presents clean, useful tools to earn initial approval. The user installs it, grants the necessary permissions, uses it without incident. Then, in subsequent sessions, the server silently modifies its tool definitions or behavior. The MCP specification has no mechanism for tracking definition changes or requiring re-approval when they occur. The gap is structural. CVE-2025-54136, disclosed by Check Point Research in July 2025 with a CVSS base score of 8.8, formalized the rug-pull as a catalogued vulnerability in Cursor IDE.

Tool shadowing adds another layer. When multiple MCP servers run concurrently, a malicious server can register a tool with the same name as a legitimate one. If the attacker's tool description better matches the agent's intent resolution, the agent routes the call to the attacker's version. A tool named "send_email" on a malicious server can be selected over the authentic email tool. The attacker's tool logs parameters, modifies recipients, forwards payloads, and returns plausible results so the user notices nothing. The task appears to complete normally.

The postmark-mcp case, which Koi Security identified in September 2025, is where this moved from theoretical to confirmed. An npm package mirrored a legitimate email tool through fifteen clean releases. Version 1.0.16 added one line that secretly BCC'd every email the agent sent to an attacker-controlled address. This was the first confirmed malicious MCP package found in the wild. The threat ecosystem has moved beyond proof-of-concept, and the supply chain for tool definitions is now an active attack surface.

Persistence, memory injection, and side-channel logging as amplifiers

Single-session attacks have a practical ceiling. The attacker gets one window, one set of data in context at that moment, one exfiltration event. What happens when the attack doesn't need to be bounded by a single session?

Memory injection answers that question in a way that should reframe how people think about AI assistants with long-term memory features. If an attacker can implant instructions in an agent's persistent memory, the compromise doesn't end when the session ends. Every future conversation the user initiates normally will continue to exfiltrate data, because the malicious instruction is sitting in memory, reloaded at the start of each session.

The ZombieAgent research demonstrated this against ChatGPT's connector integrations and long-term memory. A zero-click indirect prompt injection persisted across sessions. The user initiated conversations normally. The agent continued executing the injected instructions faithfully, because from its perspective, those instructions were part of its established context.

Side-channel logging, formalized as the Log-To-Leak framework, takes a different approach. Rather than manipulating what the agent outputs to the user, this method covertly forces the agent to invoke a malicious logging tool, which captures user queries, tool responses, and agent replies without altering the quality of the task. The user sees correct, useful output. The data has already left. There is no behavioral signal to detect.

The empirical results from Log-To-Leak testing are specific enough to be worth citing directly: on PayPal's MCP environment, GPT-5 reached a 100% attack success rate with 94.6% logging accuracy. On GitHub's MCP environment, GPT-4o's attack success rate rose from 38.4% to 62.6% when the framework was applied. These are not marginal improvements on a theoretical technique. They are high-fidelity exfiltration results on production API surfaces.

The reason persistence and side-channel attacks matter so much for detection is precisely that they produce nothing anomalous to detect. Single-session attacks, in theory, are caught by behavioral analysis if the agent does something unusual. Persistent memory-based attacks and quality-preserving side-channels produce no anomaly. The agent is, by every measurable indicator, working correctly.

Production incidents that confirm these are not theoretical risks

People have a tendency, understandable given how fast this field moves, to treat AI security research as a preview of future problems rather than a description of current ones. The incident record from the past eighteen months argues against that comfort.

EchoLeak, catalogued as CVE-2025-32711 with a CVSS base score of 9.3, affected Microsoft 365 Copilot. Disclosed by Aim Security in June 2025, the vulnerability allowed a remote attacker to steal confidential data by sending a single email to a Copilot user, zero clicks required. The attack chain evaded Microsoft's own cross-prompt injection classifier, bypassed link redaction using reference-style Markdown, exploited auto-fetched images, and abused a Teams proxy permitted by the content security policy. Microsoft deployed a server-side fix in May 2025 and stated no customer action was required. The vulnerability had existed in production for months before disclosure. No in-the-wild exploitation was confirmed, but the attack surface was present and functioning in an enterprise deployment at scale.

GitHub Copilot's CVE-2025-53773 carried a CVSS score of 9.6. An injection payload embedded in source code caused the agent to execute arbitrary terminal commands. No elevated permissions were required. The agent's normal code-reading behavior was sufficient to trigger the exploit.

A mid-2025 incident involving Supabase and Cursor saw an agent running with privileged service-role access process support tickets containing attacker-supplied SQL instructions. Sensitive integration tokens leaked into a public support thread. The agent executed the instructions faithfully, because from its perspective, they were instructions.

A Fortune 500 financial services firm disclosed, in March 2025, that its customer service agent had been exploited via prompt injection and had quietly leaked account data for weeks before anyone detected it. The regulatory cost ran into the millions. The detection lag is the part that should concentrate attention: weeks of ongoing exfiltration from a production system, during which the agent was operating exactly as designed.

CVE-2025-6514 in the mcp-remote library, a widely used MCP transport component with close to 500,000 downloads at time of disclosure, carried a CVSS score of 9.6. It passed attacker-controlled authorization endpoint URLs directly to the system shell without sanitization, enabling remote code execution on client machines. This is the supply chain risk materialized at the infrastructure layer.

Across all of these cases, the pattern is consistent: the attack succeeds because the agent's authorized behavior and the attacker's desired behavior are the same action.

Why traditional security tools cannot see this traffic

Let me describe what a security operations analyst actually sees when one of these attacks is in progress. They see an authorized API call originating from a known process, using valid credentials, routing to a domain the enterprise has previously approved, over encrypted transport, at a time of day consistent with normal usage patterns. That is what they see. Nothing in that picture is anomalous. Nothing triggers an alert.

Perimeter and network monitoring were designed for a different threat model. The traffic is encrypted. The origin is legitimate. The protocol is standard. The destination is often a Microsoft, Slack, or GitHub API that the organization actively uses and has explicitly approved. A SIEM looking for known-bad destinations finds a clean domain. A firewall looking for anomalous connections finds an authorized process doing its job.

DLP tools are built to recognize data patterns: Social Security numbers, credit card numbers, formats the organization has taught the tool to flag. Base64 encoding defeats this. Fragmentation across multiple calls defeats this. Embedding data in a URL path defeats this. The patterns the DLP tool knows how to recognize don't survive the encoding step.

Behavioral analytics face a more fundamental problem. The baseline behavior of an LLM agent is calling external APIs. That is its entire function. A tool call carrying exfiltrated data is, at the behavioral layer, indistinguishable from a tool call doing exactly what the agent was built to do. You cannot build a behavioral anomaly detector when the anomalous behavior is identical to the normal behavior.

EchoLeak demonstrated something particularly important about detection: Microsoft's own production cross-prompt injection classifier was bypassed as one step in a multi-stage attack chain. The team building these systems, with full access to their own classifier's architecture, was not able to make it reliable enough to stop a well-constructed attack. Detection is not a solved problem even for the vendors who have invested most heavily in it.

A 2026 enterprise security survey found that 82% of executives believed their existing policies already protected them from unauthorized agent actions, while 88% of organizations reported confirmed or suspected AI agent security incidents in the same period. The perception gap is not a knowledge problem. It is a security control failure in its own right, because confidence in insufficient controls delays the adoption of sufficient ones.

What detection and defense actually require at the tool-call layer

The conclusion that follows from everything above is that defense cannot happen at the network layer, the perimeter, or the behavioral baseline. It has to happen at the instruction layer, which means at the tool call itself, at the moment the agent decides what to do and why.

What that requires, practically, is a runtime layer that sits between the agent and its tools, inspects tool calls before they execute, and evaluates whether the call is consistent with legitimate user intent. Not whether the call is syntactically valid. Not whether the credentials are authorized. Whether the semantic content of this specific call, given the conversation that preceded it, reflects what the user actually asked for.

This is categorically different from signature-based detection or behavioral baseline monitoring. It requires understanding what the agent was asked to do, what data it currently holds in context, and whether the outbound call serves the stated purpose or some other instruction embedded in retrieved content. That's a reasoning problem, not a pattern-matching problem.

Memory and context controls are equally necessary. Agents with long-term memory need mechanisms for auditing and reviewing what's stored, because injected memory is an attack surface that persists across sessions. Tool approval workflows need version tracking, so that a tool definition that changes between sessions triggers re-approval rather than silent acceptance.

Supply chain hygiene for MCP packages requires the same scrutiny organizations now apply to npm or PyPI dependencies: provenance verification, behavioral auditing of new versions, and skepticism toward packages that request permissions beyond their stated function. The postmark-mcp case established that this is not theoretical; malicious packages have appeared, behaved cleanly through multiple releases, and activated later. Treat tool definitions as code, with all the review processes that implies.

Least-privilege scoping for agent credentials is foundational and frequently overlooked in the rush to give agents enough access to be useful. An agent that can read files should not also be able to send emails unless sending email is an explicit, documented requirement of its role. An agent with access to a service-role database key should not be processing untrusted external input. The privilege model that governs human operators should govern agents with equivalent strictness, because the attack surface is the intersection of what the agent can access and what content it processes.

None of this is a complete solution, and I'd be skeptical of anyone who presented it as one. The UK NCSC's assessment that indirect prompt injection will never be fully fixed is an honest statement about the current state of the technology. What defense actually requires is reducing the attack surface at every layer where reduction is possible: constraining what the agent can access, auditing what instructions it executes, inspecting tool calls before they complete, and treating tool definitions and agent memory with the same rigor applied to code and credentials. The channel cannot be closed. It can be made significantly harder to exploit, and significantly more likely to produce a detectable signal when it is.

That's the work. It's not glamorous, and it doesn't fit neatly into a legacy security framework. But it's the actual perimeter now, and organizations deploying agentic AI at scale need to be building toward it before an incident teaches them why.