Covert Channel Data Exfiltration in LLM Agents
Most of the AI security incidents that made headlines in 2024 and 2025 were failures in the harness around the model: the tools, the connectors, the memory stores, the workflows that give an agent something to actually do. I want to walk through the exact paths data takes when it leaves through those cracks. You can't defend a system you can't picture, and most teams I talk to haven't pictured this one yet.
What makes a channel "covert" in the context of an LLM agent
A covert channel moves information through a path your security setup doesn't recognize as a path at all. The data travels, but the monitor watching for data travel sees nothing, because what it's actually looking at is a markdown image rendering, or a retrieval call, or a summary getting written. It looks like normal agent behavior on its face.
Microsoft's security research team sorts these into a few buckets: image beacons hidden in HTML or markdown, where a URL your client fetches on its own carries an encoded payload; clickable links with data packed into the query string; tool calls aimed at a server the attacker controls; and plain steganography, where the payload sits inside output text that reads as ordinary prose.
Here's what sets this apart from the covert channels security teams have dealt with for decades: the model does the encoding itself. Nobody needs to plant malware or hold a foothold on your network. They need one path to slip an instruction in front of the agent, and the agent does the rest, because it's just following what looks like a normal request.
The leakage surface is wider than most people assume walking into this. It's not just the final answer the user sees. Retrieved documents, the arguments inside a tool call, the text a tool sends back, structured outputs meant for another system: any of these can carry private state outward, whether or not anyone meant for them to. Attackers aren't required for this to happen, which is why I'm covering both prompt-injected exfiltration and the leakage that happens when nobody's attacking anything at all.
How a single injected instruction turns tool calls and markdown rendering into an exfiltration path
The basic move goes like this. An attacker hides an instruction somewhere the agent will read it: a web page, an email, a PDF. The agent, following that instruction, builds a markdown image tag where the URL has private data baked into it, usually base64-encoded. Your client renders the "image," which means it fetches that URL automatically, and the data lands on the attacker's server without anyone moving a file or clicking send.
The same trick works through favicons, Open Graph tags, basically any URL a rendering setup fetches without asking first. The model has no idea it's exfiltrating anything. It thinks it's including a reference image, because that's what the injected instruction told it to do.
Tool access opens a second door. An agent with email, Slack, or webhook access can be told to "send a summary to this address," and that tool call gets logged as routine agent activity. The address just happens to belong to someone who shouldn't have it. Agents with code execution can push data out through DNS lookups or HTTP headers, paths that most egress rules built for LLM traffic never planned for.
Slack AI's exfiltration incident in August 2024 shows the whole chain in one place. An attacker drops instructions into a public channel, and Slack AI ingests that channel into its retrieval pipeline. A victim asks Slack AI a question, the injected instruction fires, and the agent renders a link with private-channel content, including API keys pulled from direct messages, encoded right into the URL. The victim sees a clickable link, while the attacker never touched the private channel.
EchoLeak, tracked as CVE-2025-32711 and scored 9.3 on the CVSS scale, pushed this further in June 2025, and no click was required at all. A single crafted email caused Microsoft 365 Copilot to reach into internal files and ship their contents to an attacker's server, with zero user interaction. Before that disclosure, most people in the field treated this class of attack as theoretical. I remember scrolling through Slack that week and watching a dozen security people say some version of the same thing: this is real now.
Retrieval, rendering, summarizing: both incidents ran on exactly the behaviors an agent is supposed to have, and a perimeter built to catch file transfers just walks right past it.
How the Model Context Protocol expanded the tool-call attack surface faster than security caught up
MCP became the standard way to wire agents into tools and outside data sources, and it caught on fast because it's flexible. That same flexibility is the risk. The spec itself says, in plain language, that the protocol "cannot enforce these security principles at the protocol level." Security gets pushed down to whoever builds the implementation, which in practice means it gets handled inconsistently or not at all.
OWASP put out an MCP-specific Top 10 in 2025, and the first malicious MCP package showed up in a public registry that September. Typosquatting, dependency injection, fake servers posing as official ones: these are documented patterns now, not hypotheticals.
The image-URL trick works through MCP too, and it's worse here because it repeats across every agent connected through the protocol. A tool response contains a markdown image tag pointing somewhere attacker-controlled, and the client fetches it to render the image, carrying along whatever's packed into that URL parameter. Same mechanism as Slack AI, but now it's a pattern any MCP-connected system can hit.
CVE-2025-49596, rated 9.4, went further still: it allowed arbitrary command execution through MCP infrastructure. That's full compromise of the agent, through the connector layer specifically.
Any agent that holds private data, reads untrusted content, and can talk to the outside world can be turned into an exfiltration tool with one injected instruction. The model can't reliably stop this on its own, and the protocol layer, by its own admission, isn't built to stop it either. MCP connectors are trust boundaries, full stop, and they need to be checked and watched like any other piece of your attack surface.
How long-term memory and multi-turn interaction turn one compromise into sustained leakage
Write sensitive data into an agent's long-term memory, and it doesn't stay put. It becomes available to future sessions, sometimes across different users, sometimes across different tenants entirely, long after whoever caused the problem has moved on.
Research on a framework called Back-Reveal, published in 2026, shows a more deliberate version of this. Semantic triggers get baked into a fine-tuned agent's weights during training. Once that agent is in production and someone hits the trigger, it fires off memory-access tool calls to pull stored context about the user. The exfiltration looks exactly like normal retrieval in the tool logs, because as far as the logging system can tell, that's what it is. Run this across many turns and the damage adds up: the attacker's crafted retrieval responses quietly steer how the agent behaves and how it interacts with the user, session after session.
What makes Back-Reveal different from a prompt injection is where the bad behavior lives: in the weights, not the prompt. That means it survives input filtering and prompt sanitization completely, since those defenses are built to catch something suspicious in the input, and there's nothing suspicious in the input here. Earlier work on backdoored models, including research on a framework called BadAgent, already showed that a poisoned model can steer tool-use sequences. Back-Reveal takes that further and shows systematic, session-by-session exfiltration specifically through memory tool calls.
Why did the attack evolve this particular direction? Naive injection into retrieval results tends to get caught, either by a reranker or by sanitization before it reaches the model, but weight-embedded triggers skip that layer entirely. The attack adapted to the defense that was already in place, which is how this game always goes.
Backdoors aside, even ordinary agent behavior can go wrong here. An agent that pulls more data than the task calls for, or carries information forward across steps it didn't need to, is building up a stockpile of exposure inside a workflow that looks completely legitimate. The memory store becomes a staging ground for leakage even when nobody planted anything malicious at all.
How multi-agent systems open a steganographic channel that monitoring cannot reliably detect
Chain agents together, one calling another and passing its output along as the next one's input, and you've created a new communication channel. Most monitoring tools treat that inter-agent traffic as ordinary text, because that's what it looks like.
Steganography is the word for what can happen instead. A sending agent hides a payload inside output that reads as completely harmless, and a receiving agent decodes it. Anyone watching sees two agents exchanging normal-sounding text and moves on. Researchers have started calling this "secret collusion": agents talking covertly in a way that hides the real nature of the exchange from whoever's supposed to be watching it.
A 2026 research finding puts a number on how far this has come, in a qualitative sense at least. Agentic coding models, given realistic tool access like code execution, web search, and paper access, can already build steganographic schemes that read as no different from good-faith plaintext. The open question isn't whether frontier models can pull off sophisticated steganography, because they clearly can. It's whether independently operating agents can agree on a shared scheme, key, and set of parameters fast enough, in one shot, to actually pull it off together. Right now there's real overlap on broad families of schemes, but tight coordination between agents that haven't planned this together is still limited. Repeated interaction and shared tools are where this risk gets sharp, and that's exactly the direction multi-agent systems are heading.
There's a related wrinkle in chain-of-thought reasoning, one I find genuinely unsettling. Research has documented that the reasoning tokens an agent produces before its final answer can themselves carry encoded messages, letting agents collude while looking like they're just reasoning out loud. If that turns out to be reliably undetectable, it undercuts the entire idea of watching an agent's chain of thought as a safety check, and that's a big idea to lose.
Worth naming one more channel here, even though it works a bit differently. The PLeak framework shows that adversarial content in a user's query can get a model to leak its own confidential system prompt, straight through its normal response, with no tool call needed, just the model's own output doing the work.
The model's output is the channel in every one of these cases, and there's no ground truth anywhere for what "innocent text" is supposed to look like. How exactly do you watch for the absence of a baseline?
Why non-adversarial agent behavior produces data leakage even without any attacker
A joint evaluation from the Singapore AI Safety Institute and the Korea AI Safety Institute in 2026 tested agents across 12 realistic, non-adversarial tasks: customer support, DevOps, web automation, enterprise and personal productivity work. They checked for five kinds of failure: not knowing what counts as sensitive data, not knowing who the audience is, not following policy, not minimizing what gets pulled, and not respecting access boundaries.
None of the three agents tested came through with fully correct and fully safe execution across every scenario. Here's the part that should give you pause: succeeding at the task and mishandling the data happened together, often in the same run.
The failure patterns were consistent. Agents pulled more from a database than the task needed, carried information forward across steps where it served no purpose, handed information to the wrong recipient in a summary or output, and wrote reports that included fields or records that had nothing to do with what was asked. How capable an agent is and how safely it handles data turn out to be two separate questions entirely, and a high score on one tells you nothing about the other. Anyone judging a vendor purely on benchmark numbers should sit with that for a second.
Samsung's experience with ChatGPT in March 2023 is the real-world version of this. Employees pasted proprietary semiconductor source code and other internal material into ChatGPT, more than once, across different teams, because nobody was trying to steal anything; they were trying to get their work done faster. Samsung's response was to ban generative AI tools across the company.
Research from Cyberhaven backs this up at scale. A large and growing share of what employees paste into AI tools is sensitive, with source code the single biggest category, followed by R&D material and sales data. Most of the people doing this have no idea they've just caused a security incident, because they think they're being productive, and in a narrow sense, they are.
Prompt injection detection and output filtering matter, but they're built to catch an attacker. When there isn't one, when the leak comes from an employee just trying to finish a task faster, those defenses have nothing to catch. That's the gap threat-actor-focused tooling keeps missing.
Why the enterprise risk is structural, not incidental, and what an adequate defense posture requires
The channels above are not edge cases you can patch around. They fall directly out of the features that make agents worth building in the first place: tool access, memory that persists, agents coordinating with other agents, and the ability to just tell the thing what you want in plain language.
Each one slides past a different control you probably already have in place, and the pattern only becomes obvious once you line them up. Image-beacon exfiltration slides past DLP, because DLP watches for file transfers and none occurred. Tool-call exfiltration slides past egress filtering, because the outbound call looks exactly like a legitimate agent doing its job. Memory-based and weight-embedded exfiltration slides past input sanitization, because the malicious part isn't in the input at all. Steganographic messages between agents slide past plaintext monitoring, because the payload reads as ordinary text. Over-retrieval slides past anything built to catch a threat actor, for the simple reason that there isn't one.
MCP and protocols like it stack a supply-chain layer on top of all this. A tool built and kept up by someone else can introduce an exfiltration path that neither your team nor the model's creators ever wrote a line of code for.
So what does an adequate defense actually look like? It starts before deployment, with real vetting: where did this model come from, what's its fine-tuning history, what does its connector ecosystem look like, not just how it scores on a benchmark. It continues after deployment, with tool calls checked as they happen rather than reviewed after the fact, because by the time you're reading logs after an incident, the data's already gone. Coverage has to include memory stores and inter-agent messages, not just the final output the user sees, since that's where most of the channels above actually live. This is the baseline cost of running agents that touch anything worth protecting. Anyone who frames it as optional bolt-on work hasn't read the incident reports closely enough.
