This page is part of our MCP Security Center, within The MCP Guide. Want a second opinion on your setup? Request a free MCP readiness review.
Data exfiltration through MCP is when an AI app is steered into sending private data somewhere it should not go, using its own tools. The data might leave in a tool argument, an email, a pull request or a chat message. To the systems involved, it often looks like normal activity.
Exfiltration is usually the final step of another attack. Prompt injection, tool poisoning and tool shadowing all aim to make the AI move data out. Understanding the exit routes lets you block them, whatever the entry point.
This page covers the main exit routes, documented research, warning signs and controls. Sources were checked on 28 October 2026.
Key Takeaways
- Most MCP exfiltration uses legitimate tools, so the data leaves through channels you already trust.
- Research has shown data leaving through tool arguments, emails, WhatsApp messages and public pull requests.
- Conversation history is a prime target, because it collects secrets and private details over time.
- Risk is highest when one agent has private data, untrusted content and an outbound channel together.
- The MCP spec says clients should show tool inputs before calling a server, specifically to avoid data exfiltration.
- Logging every outbound tool call with its inputs is what makes leaks visible after the fact.
The main exit routes
| Exit route | How data leaves | Documented example |
|---|---|---|
| Tool arguments | The AI adds private data to an extra parameter sent to a malicious server | Invariant Labs' poisoned add tool |
| Outbound messaging tools | The AI sends data through email or chat to an attacker | Invariant Labs' WhatsApp and email demos |
| Public write actions | The AI posts private data where the attacker can read it | Invariant Labs' GitHub pull request case |
| Conversation history | A tool description asks the AI to send the whole chat | Trail of Bits' history-theft demo |
| Shared context | Data from one task or user reaches another | OWASP MCP10 scenarios |
Documented research
Tool arguments. In Invariant Labs' tool poisoning notice (1 April 2025), a fake add tool told the AI to put an SSH key in a "sidenote" argument. The argument went to the malicious server.
Messaging tools. Invariant's WhatsApp MCP write-up (7 April 2025) showed chat history leaving through WhatsApp itself. In a second variant, the attacker only needed to send the victim a crafted message. The authors noted that sandboxing the server "is not a relevant mitigation" here, because the attack runs through the agent's instructions.
Public write actions. In Invariant's GitHub MCP case (26 May 2025), a malicious public issue led an agent to copy private repository data into a public pull request.
Conversation history. Trail of Bits' post on stealing conversation history (23 April 2025) used a fake "spellchecker" tool. Its description told the AI to send all prior messages whenever the user typed "thank you." The authors write that "conversation histories are a gold mine of sensitive information."
An illustrative scenario
This example is illustrative. It is not a real incident.
An HR coordinator uses an AI app connected to the HR system and a web-browsing tool. She asks it to summarize a public article about benefits trends. The article contains hidden text telling the AI to look up salary data and include it in a search query to an outside site.
The browsing tool sends the query, with salary figures in the URL. The HR system logs a normal read. The browsing tool logs a normal search. No single system sees a problem.
Who is at risk
Developer Simon Willison's "lethal trifecta" describes the danger zone. It is any agent with access to private data, exposure to untrusted content, and "the ability to externally communicate in a way that could be used to steal your data."
That covers many everyday setups: an inbox plus email sending, a code repo plus pull requests, or a CRM plus web browsing. Teams that give one assistant many tools are most exposed.
OWASP's MCP10 entry, Context Injection and Over-Sharing, adds another group. Shared context buffers and memory across users or agents can leak one person's data to another.
How to detect it
- Log outbound calls with inputs. Record every tool call that sends, posts, uploads or fetches a URL, including arguments.
- Flag new destinations. Alert on email addresses, phone numbers, repos or domains the user has not used before.
- Check argument size and content. Long strings, encoded blobs or text that looks like keys in arguments are red flags.
- Compare request to action. A summary request followed by a send action is worth reviewing.
Trail of Bits recommends reviewing proposed actions, "especially for sensitive data." Our page on MCP audit logging lists the fields worth recording.
How to reduce the risk
On the client side
- Show full tool inputs. The tools spec ties this directly to exfiltration, as shown below.
- Require approval for outbound actions like sending, posting and fetching new URLs.
- Avoid "Always Allow" on tools that can send data out.
On the server side
- Restrict where outbound tools can send. An email tool for invoices can be limited to known customer domains.
- Return only the data a task needs. Smaller results mean less to leak.
- Do not log full payloads that contain secrets. Leaks through logs are covered in secrets and credential leakage.
At the organization level
- Break the trifecta. Willison advises that for users combining tools, the only safe route is to avoid the full trifecta combination.
- Separate profiles. Keep tools that read untrusted content apart from tools with private data and outbound access.
- Isolate context. OWASP's MCP10 recommends ephemeral contexts, context isolation and expiry policies.
What the MCP spec says
The MCP tools specification says clients SHOULD "show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration." It also says clients SHOULD log tool usage for audit purposes and validate tool results before passing them to the model.
The Security Best Practices page adds that a server passing tokens without validation lets an attacker with a stolen token use it "as a proxy for data exfiltration." That is one more reason to avoid token passthrough. See the MCP Security Center for related threats.
Next step
Map which of your AI setups can both read private data and send data out. Our MCP readiness audit finds those combinations and recommends where to add approvals or split tools.
Frequently asked questions
Can data leave even if every server is trusted?
Yes. In the GitHub case, the server was official and the data left through a normal pull request. The trigger was hostile text the agent read. Trusted tools can still be used to move data out.
Does a firewall stop MCP data exfiltration?
Not by itself. Data often leaves through allowed services, like email, WhatsApp or GitHub. Network controls help for unknown destinations, but you also need approvals and logging at the tool level.
Which data is most at risk?
Anything in the AI's context: files it read, tool results and the conversation itself. Trail of Bits notes that chat histories can hold credentials, product plans and regulated records.
Will sandboxing my local servers prevent exfiltration?
Only partly. Sandboxing limits what server code can access. It does not stop the AI from using a trusted tool to send data out. Invariant made this point about its WhatsApp demo.
What is the fastest fix?
Turn off auto-approval for any tool that sends, posts or uploads. Then make sure confirmation dialogs show the full inputs, so a person can see what is leaving.
