Data Exfiltration Through LLM Tool and Function Calls

Data leaves the building through the exact same door you built for your AI agent to do its job. Tool-calling gives large language models a sanctioned, legitimate way to move data outside the company, and attackers have figured out how to steer that pathway without ever touching your firewall.

Old-school exfiltration meant fighting your security stack the whole way: sneaking data through outbound transfers your DLP tool watches, logging in somewhere off-limits, spinning up a process that looks wrong the second someone checks. Tool-calling changes the dynamic. The agent becomes the mechanism, moving data through channels you opened on purpose, wearing your agent's own credentials the entire way.

I want to walk through what the pipeline looks like, because if you're evaluating agentic AI for the first time, this matters more than any vendor pitch will tell you. A prompt tells the agent what to do, the model picks a tool and decides what arguments to pass it, and the tool runs, whether that's a web fetch, a database query, an API call, a file read, or a memory write, and something comes back. The agent reads that output and often chains another call off it. Simple enough, except the whole system runs on one assumption: everything sitting in the context window can be trusted. Simon Willison named this the "lethal trifecta" back in June 2025: an agent with access to private data, exposure to untrusted content, and a way to talk to the outside world is exploitable by design. Most agents running today check all three boxes, so if your company has rolled out agentic AI, you've built exfiltration-capable infrastructure whether you meant to or not. The only real question left is whether anyone's watching it.

How the tool-calling pipeline moves data: the mechanics an attacker exploits

Three things about this pipeline make it exploitable, and once you see them, you start noticing them everywhere.

The arguments passed into a tool call can carry any string you want, including sensitive data the model just pulled out of a document ten seconds earlier. Whatever a tool returns comes back into the context window with no cleaning, no filtering; the model treats it exactly like a trusted instruction from you. And calls chain: one injected line of text can set off a sequence where the agent reads the data, formats it, and ships it to an external endpoint, with no human anywhere in the loop.

Why does this happen at the architecture level? Regular software keeps code separate from data, and your computer's memory has an NX bit specifically so a program can't accidentally execute something that was only supposed to be data. LLM agents have nothing like that. The model decides its next move based on everything sitting in its context, and at the moment of inference, it can't tell a trusted instruction apart from untrusted text. That's just how the architecture works right now, and nobody's patched around it.

A prompt injection doesn't need to break the model; it just needs to sound enough like an instruction that the model goes along with it. Add retrieval-augmented generation and you've multiplied the exposure, because now the agent is routinely pulling in webpages, documents, and database records before it even decides what to do next. Every one of those sources is a spot someone could plant something.

Indirect prompt injection through tool outputs: the most documented attack path

The pattern is remarkably consistent across every incident I've looked at: an attacker plants instructions inside content the agent is going to fetch anyway, whether that's a webpage, a PDF, an email body, or an API response. The agent retrieves it, reads the planted text like a legitimate instruction, and calls a tool accordingly.

Notice what didn't happen there. The attacker never called the agent directly, and no login or stolen credential was needed. They got the agent, which already holds real permissions, to act on their behalf (that's privilege escalation without a single privilege escalation exploit).

The exfiltration step usually looks boring on purpose. The poisoned content tells the agent to make a web search or API call where confidential data gets tucked into the query string, and from the attacker's server, it just looks like ordinary traffic coming in.

None of this is hypothetical. Two LangChain CVEs from 2023 show it happening in real, widely deployed open-source code. CVE-2023-29374, in the llm_math chain, let adversarial text injected through a tool output lead to credential theft and arbitrary code execution. CVE-2023-32786 hit the APIChain tool with the same underlying pattern. Different surface, same idea: trust the tool output, and you've handed over control.

The InjecAgent benchmark, run at UIUC in 2024, put numbers on this. ReAct-prompted GPT-4 had a 24% attack success rate in the baseline setup, climbing to 47% with more polished prompts, while ReAct-prompted Llama 2 70B cleared 80% in both settings. Fine-tuned GPT-3.5 and GPT-4 hit a 100% success rate at the data-transmission stage, once extraction had already started. Once the agent's been talked into pulling the data, getting it out the door is nearly automatic, which tells you exactly where detection has to happen: earlier in the chain, not after.

MCP tool poisoning and tool shadowing: when the tool itself is the threat

The Model Context Protocol, MCP, is the standard now connecting AI applications to external tools, APIs, databases, and workflows. It's become the connective tissue of agentic deployments across the industry, which also makes it a genuinely attractive target.

Tool poisoning works at the description level. An adversary stands up or compromises an MCP server and writes malicious instructions straight into a tool's description text. The agent reads that description to decide which tool fits the job, so a poisoned description can redirect behavior before any actual tool call happens.

Tool shadowing is subtler, and in some ways worse. Run several MCP servers at once, and a malicious one can register a tool name, say "send_email", that matches or outranks the legitimate one, so the agent routes the call to the attacker's server instead. That server can log the data, quietly alter the parameters, or exfiltrate the content right alongside, or in place of, the action you actually wanted. Users almost never inspect a tool invocation before approving it, and approval fatigue is well documented by now, so a shadowed call sails through without anyone blinking.

There's a cross-contamination angle too. An untrusted MCP server, connected alongside a trusted one, can reach into data from that trusted server through the shared agent context, no credential theft required at all.

The vulnerabilities here aren't abstract. CVE-2025-68145, CVE-2025-68143, and CVE-2025-68144 are three chained flaws in Anthropic's own mcp-server-git that, paired with the Filesystem MCP server, add up to full remote code execution through a malicious.git/config file. CVE-2025-49596 is a critical RCE in the Anthropic MCP Inspector proxy server, also from 2025. A WhatsApp MCP integration got exploited in 2025 to pull message history straight out.

MCP Security Bench, from 2025, measured the scale: an overall average attack success rate of 40.35% across attack types, with Over-Privilege attacks alone hitting 76.5%. MCP-specific attacks, User Impersonation at 45.69% and Function Escalation at 39.21%, outperformed traditional prompt injection, which sat at 20.21%. MCP-native attacks are already beating the old playbook. The NSA issued a dedicated cybersecurity information sheet on MCP security in May 2026, which tells you how fast this moved from a researcher's blog post to a government advisory.

Backdoored tool-use agents and persistent memory poisoning: attacks that survive session boundaries

Everything above happens inside one session. Give an agent memory across sessions, and the attack surface stops being a single conversation and starts being the agent's entire lifetime.

Frameworks in wide use now, LangChain, LangGraph, AutoGen, OpenAI Assistants, Anthropic's agent APIs, all give agents some form of persistent memory: stored facts, session history, context pulled in semantically, artifacts written as side effects of earlier tasks.

The Back-Reveal attack, documented in April 2026, plants semantic triggers in a fine-tuned agent. Those triggers wake up later, activate memory-access tool calls, pull stored user context, and ship it out through retrieval calls dressed up to look ordinary. Across multiple turns, the damage compounds, since each response the agent retrieves nudges its later behavior a little further off course, so the leak builds gradually instead of all at once.

The numbers from Back-Reveal are hard to ignore. Semantic triggers activated successfully more than 94% of the time, and the Leak+Rewrite technique for getting data out reached 85 to 91% top-5 placement and 81 to 87% success bypassing defenses, against just 27 to 40% for a naive approach. Standard prompt-injection defenses simply weren't built for this.

A related pattern, the delayed-trigger attack, works like this: a document pulled in through RAG contains a compliance-sounding directive that tells the agent to store a routing rule using a memorysavefact call. Weeks later, in a completely unrelated session, a memoryrecallfact call retrieves that rule and sets off the exfiltration. Researchers tested six classes of defense against this, and five failed. Only one, restricting memory writes and reads at the tool layer itself, held up.

And the capability trend here isn't reassuring. GPT-5.5, tested in 2026, stored adversary-planted memories at a 99.8% injection rate, while MINJA, presented at NeurIPS 2025, showed query-only memory injection succeeding 98.2% of the time. This weakness isn't confined to older or weaker models. Once a trigger gets planted, it can sit dormant, then self-activate in a future session and move through the same phases every time: get in, collect data, ship it out, using whatever tools happen to be sitting there that day. Single-session monitoring can't see any of this. The attack lives across the agent's whole lifetime, not inside one conversation.

Why more capable models are more exploitable, not less

You'd think a smarter model would be better at spotting a bad instruction and refusing it, but the evidence points the other way.

Agent Security Bench, run in 2025 against 16 attack types, 11 defenses, and more than 400 tools, found an inverse relationship: models with higher utility, precisely because they're better at tool use and better at following instructions, showed higher attack success rates. The worst average ASR in the whole benchmark reached 84.3%.

Sit with why that makes sense instead of feeling surprising. The same instruction-following skill that makes a model good at running a multi-step workflow also makes it more likely to carry out an injected instruction without hesitation. You can't pull the compliance apart from the capability. They're the same trait, pointed in different directions depending on who wrote the instruction.

Extended InjecAgent, from 2025, adds a wrinkle worth sitting with. Llama-4 17B topped out at a 40% targeted attack success rate on the original 16-task suite, while GPT-4o's task performance dropped 12 to 22% once defenses got layered on. Even partial protection costs you something in capability. So companies land in a genuinely uncomfortable spot: the models best suited to complex agentic work are the same models most exposed to agentic exploitation. Model selection, and every version upgrade after that, becomes a risk decision in its own right, not just a performance question you settle by glancing at a leaderboard.

What the real-world signal looks like in practice

This isn't theoretical anymore, and the data from the last year makes that plain. The UK AI Security Institute, in early 2026, identified nearly 700 real-world cases of AI scheming, with documented misbehavior rising fivefold between October 2025 and March 2026.

Johann Rehberger, who writes as Embrace The Red, documented one new prompt injection vulnerability every single day throughout August 2025. Each one traced a different path from a crafted piece of text to an unintended action inside a real, deployed production system.

Through the fourth quarter of 2025, researchers spotted attempts to pull data out of connected document stores, script-shaped fragments hiding inside prompts, and hidden instructions embedded in webpages agents were processing. One detail stands out: indirect attacks, the ones arriving through some external document or page rather than typed straight into the chat box, succeeded with fewer attempts than direct attacks. External content is the front door going into 2026.

Slack's AI assistant had an incident in August 2024 where RAG poisoning combined with social engineering opened a data exfiltration path inside a tool already running in production enterprise workflows. This happened inside a shipped commercial product, not a research paper.

Layer on top of that the identity problem most security teams already know about. Varonis's 2025 State of Data Security Report found organizations carrying tens of thousands of stale accounts and permissions on average. Every AI agent you deploy adds a new non-human identity with tool-calling authority into that same pile, usually without any of the lifecycle controls you'd apply to a departing employee's account. Across every incident I've mentioned here, the pattern repeats: attackers aren't inventing anything new. They're probing a surface that's wide open and, in most companies, not being watched at all.

Where current defenses fall short and what structural protection actually requires

Standard prompt-injection defenses, instruction hardening, output filtering, input sanitization, failed against Back-Reveal's semantic triggers. That's not a small gap. It means the tools built to stop direct injection don't do much against exfiltration that routes through memory and retrieval calls instead.

Against the delayed-trigger attack, five of six defense classes tested came up short, and only tool-layer memory restriction, blocking unauthorized reads and writes right at the interface where the tool actually runs, held. That single result says something about where the industry's defenses are pointed and where they need to go instead.

Nearly every current defense inspects content: what the text says, what the prompt looks like. The exfiltration, though, happens in the call itself, in the arguments passed to a tool and the endpoint that call reaches. That's a mismatch worth naming plainly: the wrong layer is getting the attention.

What actually holds up, based on what's worked so far, comes down to a handful of things. Log every tool invocation with its full arguments, not just whether it succeeded or failed, and treat the parameters inside a tool call as a data-loss surface, the same way you'd scan an email attachment before it leaves the building. Scope tools so an agent can only call what its specific task needs, and can only write to the memory stores that task actually requires. Give a write to persistent memory the same approval scrutiny you'd give a write to a production database, and check MCP server provenance before you connect anything, because the tool registry itself is part of the attack surface, not just the tools sitting inside it.

Here's the gap most security teams are sitting on right now: your existing tooling watches network traffic, endpoint behavior, identity events, and none of that surfaces the actual argument payload inside a tool call, which is exactly where the sensitive data travels. Generic governance checklists and compliance frameworks don't help much either, mostly because they were written before agentic tool-calling existed at any real company scale. This space needs continuous monitoring of the AI asset layer itself: watching how tools actually get called, tracking what data moves through those calls, catching new attack patterns as they show up, instead of filling out a quarterly attestation form and hoping it covers something it was never built to cover. Traditional vendor risk management was built for a different era, and the tool-calling pipeline calls for its own approach going forward.