Exfiltration Prevention for Agents with Messaging Tool Access

I've spent the last year watching agents get messaging access nobody fully thought through, and the pattern is always the same. Agents with messaging tool access create an exfiltration surface that no amount of tool-level scrutiny can catch, because the danger lives in the sequence of calls rather than in any single call. An agent that reads an email, retrieves a file, and sends a reply has done three ordinary things, each one boring on its own. Whether that sequence adds up to data theft depends on what moved between step one and step three, and that's the layer most security tooling never bothers to look at.

Agents exist to move data around. They pull context, reason over it, invoke a tool, act through an API, often with no human review anywhere in that chain. Hand that agent a Slack connector, a calendar with write access, or an email summarizer, and you've built a channel that swallows untrusted content on one end and pushes data out the other, in the same breath. A person who wants to leak a file has to decide to download it, forward it, upload it somewhere; that decision is a discrete event, something you can log. An agent has no equivalent moment. Exfiltration just falls out of ordinary task completion, and task completion is the one thing the agent was built to do well.

Cyberhaven's 2025 research puts 39.7% of all AI interactions in contact with sensitive data. Agents wired into messaging pipelines work that same pile of material, just at machine speed, minus the friction that occasionally slows a human down long enough to get caught. This isn't an edge case somebody bolted onto agent design after the fact. It's structural. Messaging pipelines are where the actual organizational context lives, and agents need that context to do anything useful whatsoever.

How attackers reach the messaging pipeline without needing credentials or user clicks

No password required. Indirect prompt injection hides instructions inside content the agent is already going to process, an email body, a shared doc, a page it retrieved, rather than anything that looks like a system prompt. OWASP calls this LLM01:2025, its top risk category for LLM applications, and that ranking says something worth sitting with: this isn't a bug you patch once and move past. It's baked into how these systems are built to treat untrusted text as instruction.

EchoLeak, tracked as CVE-2025-32711 and disclosed in June 2025, is the case that made the abstract concrete. One crafted email did the damage. No attachment, no link, nothing to click. Microsoft 365 Copilot summarized that email as part of its retrieval-augmented context and swallowed the payload sitting inside it whole. From there it reached into OneDrive, SharePoint, Teams messages, connected internal systems it had no business touching, and shipped the contents to a server the attacker controlled. It did all this while sailing past Microsoft's own XPIA prompt-injection filters and link redaction, and the exfiltration route ran through a Microsoft domain already whitelisted under the org's Content Security Policy. Network monitoring had nothing to flag, because the traffic looked exactly like traffic that belonged there. Aim Security, who disclosed the vulnerability, named it an LLM Scope Violation: the model got talked into stepping across a trust boundary it was supposed to respect.

This isn't a one-off, either. HOUYI, a black-box prompt injection technique, compromised 31 of 36 real-world LLM-integrated applications researchers tested it against, Notion among them, an 86.1% hit rate (Liu et al., 2024b). That's a class of attack that transfers across wildly different systems with unsettling consistency, and it shows up wherever an agent has file write access, browser control, or the ability to chain multiple tools together.

Why memory and RAG connectors extend the attack beyond the current session

Retrieval-augmented generation connectors usually run under a service account, and that account tends to see far more of a repository than any single user asking a question is actually entitled to, with no per-user check happening at retrieval time. The agent pulls whatever the service account can see, full stop. EchoLeak rode exactly this gap: Copilot's RAG context let a payload buried in one email reach across systems the user never asked it to touch.

Memory brings a second problem, quieter but arguably worse. Long-term memory exists so a stateless model can carry context from one session into the next, useful right up until a planted instruction rides along for the trip. An attack researchers named Trojan Hippo shows the mechanic plainly: one crafted email drops a dormant payload into an agent's long-term memory, and the thing just sits there, inert, until the user brings up something sensitive later, finances, health, identity, at which point it wakes up and exfiltrates whatever's relevant. Without defenses running, the paper reports an 85 to 100 percent attack success rate against frontier, safety-aligned models from both Google and OpenAI, with the payload surviving past 100 benign sessions before it ever triggers.

Sit with what that does to incident response for a second. One injection event, weeks or months later, produces an exfiltration event with nothing obvious tying the two together. Standard log correlation assumes cause and effect sit close in time. Trojan Hippo breaks that assumption on purpose, by design. Palo Alto Networks' Unit 42 has independently confirmed that indirect prompt injection can plant persistent malicious behavior in long-term agent memory, so this isn't one lab's finding floating alone out there.

What tool-level permission models miss about argument-level behavior

Most agent frameworks running in production today grant permission at the tool level. An admin approves "send email" or "read files" or "web search," and that approval covers the whole capability, forever, not any particular use of it. Once granted, the framework has no built-in way to tell one invocation is riskier than the next.

That's the blind spot, and it's a wide one. Tool-level approval can't tell you which recipient a send-email call is actually targeting. It can't tell you whether the body of that email contains text lifted from an internal knowledge base the recipient has no business seeing. It can't tell you whether a retrieval query's parameters got shaped by untrusted text sitting in the last inbound message. It certainly can't tell you whether a chain of individually approved calls, retrieve this, then send that, adds up to an exfiltration pattern once you step back and look at the sequence.

Protocols like MCP were built with functionality as the priority; access control got left as an implementation detail instead of something the protocol layer actually enforces. Even with logging turned up to verbose, most interfaces show truncated URLs and summarized outputs rather than the raw argument content that would actually reveal what's going on. Research on STAC (Li et al., 2025) puts a name to this blind spot: individually harmless tools chain into dangerous sequences, and the danger is compositional. Per-tool review can't catch it, because per-tool review was never looking at composition in the first place. MCP-SafetyBench testing (Zong et al., 2025) found host-side attacks, intent injection, identity spoofing, succeeding over 80 percent of the time on average across 20 attack types. That number is about as direct a measure as you'll find of how little enforcement exists at the host layer right now.

Why perimeter and IAM controls operate at the wrong layer for agent behavior

IAM and DLP were built for a world where a person requests a resource, a policy engine checks that specific request, and access gets granted or denied on the spot. Agents don't work that way. An agent inherits a broad scope of permission the moment it initializes, then chains actions inside that scope for the rest of the session. No individual step triggers a fresh check. The session is the unit of trust here, not the request.

Cyberhaven's 2025 data shows endpoint-based agent adoption grew 509 percent in a single year. The control surface expanded far faster than any governance model built to watch over it. And EchoLeak shows exactly where network-layer defenses fall short: exfiltration routed through a first-party, CSP-approved domain looks identical to ordinary Copilot traffic at the network layer. Network controls were built to judge the channel, and here the channel checks out clean while the data moving through it doesn't, a distinction those controls were never built to answer. Shadow deployments make things worse still: agents spun up outside sanctioned infrastructure inherit no organizational controls at all, since there's no infrastructure there for them to inherit from.

Perimeter thinking asks whether a destination is allowed. Agent behavior demands a different question: does this specific tool argument carry data that shouldn't flow to this destination, given where the content shaping it actually came from? Answering that means tracing provenance at runtime, not running a static policy lookup, and no amount of IAM sophistication changes which layer that question has to be asked at.

What argument-level runtime enforcement actually looks like in practice

The fix lives at the argument level: inspect what's actually inside each tool call before it fires, not just which tool got invoked, and trace where the data inside that call came from.

CaMeL, published by Google DeepMind in 2025, is the clearest working model of this idea so far. It splits control flow from data flow. A Privileged LLM handles the trusted user query, while a separate Quarantined LLM handles untrusted retrieved content and gets no tool access of its own. Every value moving through the agent's working context carries capability metadata restricting what can be done with it, according to fine-grained policy, so untrusted data physically can't steer program flow. That separation is structural, built into the architecture, achieved through enforced constraints rather than through instructions the model is merely asked to follow. CaMeL essentially solves the AgentDojo security benchmark while still completing 77 percent of tasks, against 84 percent for a version of the same system with no defenses running at all. A seven-point utility cost, in exchange for provable security against the hardest cases on that benchmark? Most security teams would take that trade without blinking.

Enforcement built this way needs a handful of specific capabilities. Recipient validation asks whether the destination on a send-email or post-message call matches an allowlist tied to the user's original intent, rather than wherever the agent has talked itself into sending things by that point. Content provenance checking asks whether the outbound body contains material pulled from an internal source under a service account scope the recipient was never granted access to. Trigger-source tracing asks whether this tool call originated from a trusted instruction or from content the agent ingested through the messaging pipeline itself. Sequence detection asks whether the pattern of calls this session resembles a retrieve-then-exfiltrate shape, even when every call looks clean in isolation.

All four of these have to run before execution happens. Logging after the fact records that exfiltration occurred; it does nothing to stop it. And the intervention has to stay narrow: block the specific argument or flow that crosses the line, not the whole tool, and not the session. Controls heavy-handed enough to break approved work get disabled by the people who depend on that work. A disabled control protects nothing, which is worth remembering the next time someone proposes a blunt fix.

How to verify that enforcement works without breaking the workflows it is supposed to protect

Verification cuts two ways here. A team has to prove the enforcement actually stops the attack, and separately prove it doesn't wreck the legitimate workflows running through the same agent. Skip either half and what you have isn't a verified control. It's a guess wearing a security label.

Testing against live production simply isn't an option. An agent with real messaging access, tested against real infrastructure, sends real emails and touches real files during the test itself. That's an incident, dressed up as a test. The workable move is an isolated twin environment, a setting close enough to production state to mean something, where no tool call ever actually executes against anything live, Armorer Labs, for instance, runs security verification for AI agents exclusively in such isolated twins, and a few other platforms take similar approaches. That's the only place both halves of verification, does it stop the attack, does it preserve the workflow, can happen without creating the exact harm you're trying to prevent in the first place.

Order matters here. First, prove the attack actually lands against the undefended agent, so the exfiltration path gets demonstrated rather than assumed on faith. Then apply the narrowest argument-level control that stops that specific flow, nothing broader. Then re-run every approved workflow the agent normally handles, to confirm none of it broke in the process. And write all of it down, in enough detail that a release approver can read the record and sign off before any of it reaches production. That record has to show the attack scenario itself, the exact argument or flow that got restricted, the enforcement rule applied, and workflow test results from both before and after, detailed enough that an independent reviewer could rebuild the finding from scratch if they had to.

A human signs that record before it merges. Full stop. Silent, automated patching of agent behavior removes the one thing that makes a verified record worth trusting in the first place: somebody accountable actually looked at it. And any enforcement covering only part of the exfiltration surface needs to say so, plainly, in the same document. An undocumented gap is worse than an acknowledged one, because it hands a team false confidence in coverage that was never actually there to begin with.