Data Exfiltration Through Agent Tool Use: How Sanctioned Tools Become a Leak Channel

Most agent security work assumes the danger is a bad tool. Someone slips a malicious tool into the environment, the agent calls it, and data walks out. Teams respond by vetting tools, scoping permissions, and monitoring for tools that shouldn't be there. That work matters. It also leaves a second, quieter attack untouched.

The tools can be entirely legitimate and still become the leak. A sanctioned database query, an approved HTTP tool, an authorized file reader — each can move sensitive data to the wrong place when an attacker controls what the agent decides to do with it. Nothing about the tool changed. The agent's behavior did. That is the attack this post is about, and it needs a different set of defenses than tool vetting provides.

Your own tools, used against you

Once a tool passes review and gets scoped permissions, teams tend to treat the tool surface as settled. The tool does what it's allowed to do, and what it's allowed to do was approved, so the reasoning stops there.

The gap is that approval covers the tool, not the sequence of calls the agent makes with it. An agent that can read a customer record and also make an outbound web request holds everything it needs to leak that record, using two calls that are both individually authorized. The permission model sees a legitimate read followed by a legitimate send. The security problem lives in the fact that the agent was manipulated into chaining them.

How exfiltration through tool use actually works

The attack chain is short and every step is authorized.

It starts with an injected instruction. A prompt injection in user input, or poisoned content in a document the agent retrieves, tells the agent to fetch sensitive data and route it outward. The agent, following what it reads as a legitimate instruction, uses tools it is allowed to use: it reads a record, then calls an outbound tool — a web request, an email send, a webhook — with the data embedded in the call.

The data is rarely sent in an obvious form. It gets smuggled into URL parameters, tucked into tool arguments, or folded into a benign-looking summary that happens to contain the sensitive values. To a permission check, the outbound call looks like any other authorized outbound call. No permission was violated. Every tool invocation was inside scope. That is exactly what makes the attack hard to catch with the controls most teams have in place.

Why least privilege is necessary but not sufficient

Least privilege is the right foundation. An agent that cannot reach sensitive data cannot leak it, and an agent with no outbound tool has no channel to leak through. Shrinking what each agent can touch shrinks the blast radius of any manipulation.

The limit shows up as soon as the agent needs to do real work. Plenty of useful agents legitimately require read access to sensitive data and an outbound tool in the same workflow — a support agent that looks up an account and then sends a notification, a reporting agent that queries records and posts a summary. Once both capabilities are in scope, permissions can no longer tell a legitimate workflow apart from an exfiltration one, because both use the same two calls. Access control decides what the agent can touch. Stopping this attack also requires deciding whether a specific action is appropriate given the request, and that is a behavioral judgment layered on top of permissions.

Pre-LLM controls: stop the instruction before it lands

The cheapest place to break the chain is before the malicious instruction ever reaches the model. If the agent never receives the "fetch this and send it there" instruction, it never acts on it.

That means running prompt injection detection on both surfaces where injected instructions enter: the user's input and the content the agent retrieves. Retrieved content is the one teams miss most often, since a poisoned document looks like ordinary context right up until the model treats its embedded instruction as a command. A guardrail that runs in the hot path before every model call can catch injection attempts and strip or block them, and the same pre-LLM stage is where sensitive-data awareness belongs during context assembly, so the model isn't handed more than the task requires.

Post-LLM and action-level controls: validate the tool call, not just the text

Pre-LLM checks catch the instruction. They won't catch every case, so the second checkpoint sits at the tool call itself, not at the model's final message to the user.

Tool and action validation asks a direct question before the call executes: does this outbound call fit what the user actually requested? A support request to look up an order does not justify an outbound web request carrying the customer's full record. Inspecting tool arguments for embedded sensitive data before the call runs catches the smuggling techniques — data hidden in a URL parameter or a call payload — that a text-only output check would miss entirely. When an outbound call carries data it shouldn't, the system can block it or feed the problem back to the agent for correction before anything leaves the environment.

The point worth holding onto: the checkpoint is the tool invocation, the moment data would actually move, not just the model's final wording. An agent can produce a perfectly clean-looking response to the user while quietly making an outbound call that carries the payload.

The trace is where you catch it

Exfiltration through sanctioned tools is close to invisible in permission logs, because nothing was unauthorized. The read was allowed. The send was allowed. A log of permission decisions shows a clean run.

The attack is visible in the trace. Instrumenting every tool invocation with its inputs, outputs, and latency surfaces the exact sequence — a sensitive read immediately followed by an outbound send — along with the argument contents and the destination the data was headed for. That read-then-send pattern, with sensitive values sitting in the outbound call's arguments, is the signature. Without the trace you are reconstructing the incident from logs that all say "authorized." With it, the chain is laid out step by step.

Detecting the pattern across production traffic

Single-run controls catch the obvious attempt. The subtle version — a slow trickle, a technique that stays just under any single-call threshold — shows up only when you look across traffic.

Continuous evaluations running against production interactions turn the trace data into a running signal. A spike in outbound calls carrying data that resembles sensitive records, or a tool-use sequence that deviates from how the workflow normally runs, is worth investigating before anyone files a report. The same read-then-send signature that identifies a single incident becomes a pattern you can monitor: how often does an outbound call follow a sensitive read, and how often does that call's arguments contain data the destination has no reason to receive.

Governance: proving the data can't walk out

Enterprise review asks a plain question before an agent that touches sensitive data goes live: what stops that data from leaving through the agent? "The tools are approved" is not an answer, because this attack uses approved tools.

The answer is the combination — access scoping that limits what the agent can reach, tool-call validation that checks outbound actions against the request, and telemetry on every outbound call so the whole surface is auditable. Being able to show those controls, and the traces that prove they run, is what carries an agent through an agent discovery and governance review. An agent that can read sensitive data and send it outbound, with no behavioral controls on the send, is the exact risk surface a governance team is there to catch.

TLDR

• The tools don't have to be malicious. A legitimate agent can be manipulated into leaking data through its own sanctioned tools, and every call in the chain is authorized.
• The attack is an injected instruction (via prompt injection or poisoned retrieved content) followed by a legitimate read and a legitimate outbound send, with the data smuggled into the call's arguments.
• Least privilege shrinks the blast radius but can't stop it once an agent legitimately needs both sensitive-data access and an outbound tool. Behavioral controls have to sit on top of access controls.
• Pre-LLM: detect injection on user input and retrieved content before it reaches the model.
• Post-LLM: validate the tool call against the user's request and inspect arguments for embedded sensitive data before the call executes.
• Permission logs show nothing because nothing was unauthorized. The trace shows the read-then-send pattern that gives the attack away.
• Patterns across production traffic catch the subtle, low-and-slow version that single-run checks miss.
• Governance review asks what stops data from leaving. Access scoping, tool-call validation, and outbound telemetry are the answer you need to be able to show.

Want to see how Arthur catches exfiltration through sanctioned tool use? Book a demo with an AI expert.

‍