Preventing data exfiltration through MCP means making sure a tool call can't become the path that moves sensitive data somewhere it shouldn't go, whether that's an external API, a message sent to the wrong recipient, or a file written somewhere outside its intended boundary. The risk isn't hypothetical: an agent with read access to sensitive records and write access to an outbound channel, an email tool, a webhook, a file upload, has everything it needs to leak that data in one chained sequence of tool calls, and it doesn't need malicious intent on anyone's part for that to happen. A misleading instruction, a manipulated document in its context, or a poorly scoped tool combination is enough.
Map which tool combinations can actually move data outward
Start by identifying every tool an agent can call that reads sensitive data and every tool that can send data somewhere external, then look specifically at whether the same agent, in the same session, can reach both. That combination is where exfiltration risk actually lives. A read-only reporting tool paired with an email-sending tool on the same agent is a pairing worth deliberately reviewing, not something to notice for the first time after an incident.
Constrain outbound destinations, not just outbound actions
A tool that can send an email or make an HTTP request to an arbitrary destination gives far more reach than one restricted to a known, allowed set of recipients or endpoints. Wherever the underlying task allows it, constrain outbound tools to a defined allow list of destinations rather than letting the model supply an arbitrary address or URL as a parameter.
Don't rely on the model to recognize when data is sensitive
A model can be asked to "be careful with sensitive data" in its instructions, and that instruction can simply get overridden by a later prompt, a misleading document, or an ambiguous request. Enforcement against exfiltration needs to happen at the tool or gateway level, checking what's actually being sent and where, rather than trusting the model's own judgment as the only safeguard.
Watch for unusual data volume and unusual call sequences
A tool call that reads far more records than a typical request, or a session that chains a broad read followed immediately by an external send, is worth flagging even if each individual call looks legitimate in isolation. Volume and sequence patterns catch exfiltration attempts that a single-call review would miss entirely.
Apply data classification before data reaches a model's context at all
The most reliable prevention happens before the tool call: if genuinely sensitive fields are tokenized, redacted, or simply never loaded into a model's context in the first place, there's nothing left for an exfiltration path to move even if every other control fails. Treat context minimization as a first line of defense, not a nice-to-have layered on top of everything else.
Have a response plan ready before you suspect exfiltration, not after
Decide in advance what happens when monitoring flags a suspicious data movement pattern: which credentials get revoked first, which tool access gets suspended, who gets notified, and how quickly. An exfiltration attempt that's caught in progress but met with an improvised response can still finish successfully while a team figures out who's authorized to pull the plug. A rehearsed response plan turns detection into containment instead of just documentation of what already happened.
Consider what a legitimate-looking session could still do
Even a fully authenticated, properly authorized session can be steered by manipulated context toward legitimate-looking calls that add up to exfiltration, since none of the individual permissions were violated. This is why exfiltration prevention has to sit partly outside the authorization model entirely, in monitoring and data minimization, rather than assuming that correct permissions on every single call are sufficient protection against the sequence those calls form together.
Where TELEON fits
TELEON enforces policy at the tool-call boundary and can apply privacy vault tokenization so sensitive values are replaced with tokens before they ever reach a model's context, which directly reduces what's available to exfiltrate even if a later tool call attempts it. The audit trail also supports detecting unusual call sequences and volume across tool calls that pass through the gateway.
Mapping which specific tool combinations create exfiltration risk in a given application, and deciding which outbound destinations should be allowed, is still application-specific work that depends on what each agent is actually built to do.
A short checklist
- Map every combination of read and outbound tools a given agent can reach in one session.
- Constrain outbound tools to a defined allow list of destinations where possible.
- Enforce data handling rules at the tool or gateway level, not through model instructions alone.
- Monitor for unusual data volume in tool call results.
- Watch for sequences that chain a broad read with an external send.
- Tokenize or redact sensitive fields before they enter a model's context.
- Review agent tool access specifically for exfiltration paths, not just individual tool risk.
Data exfiltration through MCP rarely looks like a dramatic breach in the moment. It looks like an agent doing exactly what it was asked, using tools it was explicitly granted, in a sequence nobody thought to prohibit because each step seemed reasonable on its own. Preventing it means thinking about tool combinations and data flow as a whole, not just reviewing each tool in isolation.