Data Exfiltration via LLM Output Channels in Agentic Workflows

Every output channel an AI agent touches, tool calls, memory writes, API responses, rendered markdown, is a potential data exfiltration path. This piece maps four of those channels in operational detail: indirect prompt injection, tool-call transmission, persistent memory, and MCP tool-description poisoning, then looks at what actually stops them. Detecting prompt injection aimed at system prompt extraction, or adversarial queries probing a vendor LLM API for a way out, starts with understanding which of these channels the attack is using.

Why agentic AI creates fundamentally new data exfiltration risks

A chatbot that gets manipulated produces bad text. An agent that gets manipulated takes action: it reads a file, calls an API, sends data somewhere it shouldn't. That's the architectural break between the two deployment models, and it's not a matter of degree.

Symantec's analysis frames the mechanics well. Today's agents are autonomous actors. Each data flow is a potential exfiltration vector, whether or not anyone designed it to be one.

Large language models cannot reliably distinguish between trusted system instructions and untrusted user or external data, and in an agent, that same ambiguity produces an unauthorized file read, an API call nobody approved, or a data transmission to a server the organization never vetted. Same root cause, far more severe consequence, because the agent has hands.

And the surface is growing fast. Symantec, citing IDC, notes that agent use across the Global 2000 is projected to increase tenfold by 2027, and token and API call loads will rise a thousandfold over that period. Security teams built their detection and governance habits around a world where chatbot queries were occasional. That world is being replaced by one where every agent action, multiplied a thousandfold, is a candidate exfiltration path. The rest of this piece walks through four of those paths one at a time: what goes in, how it moves, where it hides, and what closes it.

Indirect prompt injection and web content as an exfiltration trigger

Web pages, emails, and documents stop being passive inputs the moment an agent starts reading them. An agent that retrieves a page to summarize it cannot reliably separate the retrieved content from whatever instructions someone hid inside that page.

That's the mechanism behind indirect prompt injection. Malicious instructions embedded in retrieved content hijack the agent's behavior without the user ever seeing it happen. Agents face a far wider attack surface than chatbots for a specific reason: they pull from multiple sources autonomously, chain tool calls together, and act on the results with comparatively little human oversight at each step.

The clearest demonstration so far is EchoLeak, tracked as CVE-2025-32711 with a CVSS score of 9.3, found in Microsoft 365 Copilot. The attack chained several bypasses together, evading Microsoft's cross-prompt injection classifier, getting around link redaction using reference-style Markdown, exploiting auto-fetched images, and abusing a Teams proxy to reach full privilege escalation. It stands as the first known case of a prompt injection weaponized into concrete data exfiltration inside a production AI system.

The pattern didn't stop there. In January 2026, researcher Zvika Babo disclosed ZombieAgent, targeting OpenAI's Deep Research agent and its Connectors feature, the integration that links ChatGPT to services like Gmail, Google Drive, and GitHub. The finding shows the injection surface extends to every external service an agent can reach through its connectors, not just the agent's native environment.

Google Cloud wasn't exempt either. Overly permissive default OAuth 2.0 scopes left latent risk of reaching Google Workspace services like Gmail, Drive, and Calendar, though direct access to one restricted GCS bucket was blocked.

These aren't lab exercises. Bloomberg News reported that a hacker used Anthropic's Claude to steal sensitive Mexican government data, and SecurityWeek separately covered reconnaissance against operational technology at a Monterrey water utility. EchoLeak and ZombieAgent show that indirect prompt injection is already an active attack surface across production systems from Microsoft, OpenAI, and Google, so it is not a theoretical concern anyone can afford to defer.

Tool calls and outbound retrieval as exfiltration pipes

Getting an instruction into an agent is one problem. Getting data out is the next, and the agent's own tool infrastructure usually does that job for free. Retrieval and search tools are routinely granted broad outbound access, and they issue HTTP requests to external APIs as part of normal operation. A backdoored agent can blend its exfiltration traffic into that legitimate pattern, and anomaly detection built around "unusual network activity" has nothing unusual to catch.

Research on this channel shows how precisely it can be tuned. Multi-turn interaction makes this worse: crafted responses subtly shape subsequent agent behavior across a conversation, producing cumulative leakage that a single-turn attack couldn't achieve on its own.

Symantec's enterprise framing makes the stakes concrete. Picture a financial services agent that retrieves a customer's portfolio data through an MCP tool call, sends that data as inference context to an LLM for analysis, then passes the synthesized response to an external reporting API. That's two separate leakage points, and under a standard deployment, zero DLP visibility into either one. It is the design pattern agentic frameworks encourage by default, not an edge case someone engineered around a weak configuration: retrieve, reason, report, each step moving data somewhere new.

Persistent memory and long-running exfiltration campaigns

An agent that remembers things across sessions is more useful, and that same statefulness turns a single successful injection into a long-running campaign.

The mechanism is called a Trojan Hippo attack. At that moment, it exfiltrates high-value personal data to the attacker.

Trojan Hippo Bench tested this attack across four different memory architectures: explicit tool memory, agentic memory, retrieval-augmented generation, and sliding-window context. The undefended attack achieved an attack success rate as high as 85 to 100% against frontier models from OpenAI and Google. Planted memories still activated even after 100 benign sessions had passed, so an attacker's payload can sit quietly for months of normal use before it fires.

Two separate research efforts, two separate deployed systems, but the same underlying pattern.

What makes this channel so damaging is what memory systems are built to retain: income details, medical history, legal correspondence, personal disclosures made in the ordinary course of using an assistant. The attacker is getting context the user volunteered, organized and ready to use.

MCP tool-description poisoning as an exfiltration vector

MCP tool descriptions are the natural-language instructions that tell an agent what a tool does and when to reach for it. That makes them a privileged piece of the system: quietly modifying a tool description redirects agent behavior at the configuration layer, before any runtime defense ever gets a chance to observe the manipulation.

Microsoft's security research team disclosed this. You can modify the descriptions attached to MCP tools so they redirect an agent's behavior, and it then collects and exfiltrates sensitive data while every individual action still looks authorized. The instructions describing the tool were.

It's hard to catch because the gap sits between what a tool description says and what the tool actually does once invoked. Symantec's framing of MCP applies directly here: every resources/read operation moves data between systems, and an agent retrieving through one tool while passing data out through another is the exact design pattern these frameworks encourage. Tool-description poisoning weaponizes that pattern from inside the configuration layer, not from outside it.

Four channels now sit on the table: the environment the agent reads, the tool calls it makes, the memory it carries forward, and the configurations that define its tools. No single runtime defense watches all four at once.

Limits of prompt-level defenses

The standard first response to prompt injection is a layer of system-prompt instructions and classifier filters sitting in front of the model. That response is mismatched to the problem it's meant to solve. SQL injection gets mitigated through schema validation because SQL has a fixed structure to validate against. Natural language has no such structure. It's flexible by design, and these attacks are built from natural-language input the model interprets as a high-priority instruction, indistinguishable in form from a legitimate one.

The bypass data backs this up. Back-Reveal's reranker-aware response rewriter achieved payload delivery through LLM Guard and NeMo Guardrails at rates between roughly four-fifths and nearly nine-tenths. These are defenses evaluated directly as targets, and they let most of the payloads through.

The compositional threat analysis underlying this research draws the structural line clearly. Those three operate at different layers of the system. A defense tuned to catch one can be completely blind to the other two.

The research community isn't alone in reaching this conclusion. The OWASP Top 10 for LLM Applications 2026 lists Prompt Injection, Sensitive Information Disclosure, and Excessive Agency as its top three risks, and the accompanying Agent Control Standard moves the compliance baseline away from a checklist of prompt-level risks toward continuous, machine-readable control over what agents are actually permitted to do. That shift is an institutional acknowledgment that prompt-level defenses, on their own, don't hold.

None of this means layered prompt defenses are worthless. The honest position is that they're necessary and insufficient: they work on the model's output, a symptom, rather than on the structural absence of information-flow control between trusted and untrusted data, which is the cause.

What information-flow control and communication-layer enforcement provide

Information-flow control, IFC, is where the research community is converging as the principled alternative to prompt-level filtering. CaMeL is one instance of this approach: it creates a protective system layer around the LLM that explicitly extracts control and data flows from the trusted query, so that untrusted data the LLM retrieves can never influence program flow. A capability model layered on top prevents exfiltration of private data over unauthorized data flows by enforcing security policy at the moment a tool gets called, not after the fact.

Memory-layer defenses built on basic security principles cut Trojan Hippo attack success rates substantially, down to as low as 0 to 5% in Trojan Hippo Bench's testing. That reduction comes at a utility cost that varies widely depending on the task mix an agent handles, so effective deployment isn't a one-size solution. It requires matching the defense to how the agent actually gets used.

Communication-layer enforcement is the complementary piece that operates at the infrastructure level, inspecting flows outside the model's reasoning. That placement allows real-time inspection of every prompt, completion, tool call, and tool response without requiring any change to the applications themselves, and it extends existing EDM, IDM, and content-identifier policies to cover agent data flows the same way they already cover other enterprise data.

None of this comes free. Back-Reveal shows that an attacker-controlled retrieval response can steer subsequent agent behavior and user interactions across turns, so any defense needs to account for multi-hop propagation across exchanges.

The architectural shift from chatbot to agent opens attack surfaces that conventional security and governance frameworks weren't built to see, and that blind spot grows more serious as agent deployments scale across an enterprise. Platforms that combine continuous monitoring of vendor AI deployments with real-time threat detection, Promptarmor's approach to enterprise AI risk intelligence among them, are built to surface these agentic exfiltration vectors in agent workflows before they cross a data or compliance boundary.

Continuous monitoring versus point-in-time controls

A one-time security review, run at deployment and never repeated, misses the exact behavior these attacks are built to exploit. Back-Reveal's multi-turn steering accumulates gradually across a conversation. Both attacks are engineered to stay invisible at the moment of deployment and become dangerous only later, under specific conditions a point-in-time checklist has no way to anticipate.

The compositional threat analysis separates three routes by which an attack reaches a target population: release-time pre-positioning, post-release durable seeding, and peer replication. The second and third happen after deployment, and no amount of pre-deployment review catches either one. The most reliable controls against them, independent capability mediation, protected recovery, durable-state provenance, and propagation isolation, all require enforcement that runs continuously, not a single pass at launch.

MCP tool-description poisoning follows the same logic. An organization that reviewed its MCP configuration carefully at deployment has no way of knowing whether those tool descriptions have since been altered, because nothing about that review repeats itself.

Vendors compound the exposure. Third-party risk management, information security, privacy, and legal teams need assessment and ongoing monitoring across the full vendor ecosystem, not a one-time intake review limited to internal deployments.

The OWASP Agent Control Standard's move toward continuous, machine-readable control over what agents are permitted to do signals where the compliance baseline is headed: away from pre-deployment checklists and toward ongoing enforcement. Organizations that build their monitoring posture around that direction now will be ahead of the regulatory curve as AI governance frameworks mature around them.

If you deploy agent-based vendor AI tools, you need continuous visibility into how an injected instruction could travel through an external integration, and into which vendor LLM deployments remain unmonitored for an emerging vulnerability. A platform combining vendor risk assessment with real-time AI threat detection, surfacing emerging threats before they cross a compliance or business-continuity line, is what closes the gap that generic governance frameworks and conventional security tools leave open across each of the four channels this piece has traced: the environment an agent reads, the tool calls it makes, the memory it carries, and the configurations that define what its tools are allowed to do.