Agent tool-output leakage is what happens when an agent calls a tool, receives real data such as a database row or an API response, and folds that result into its next reasoning step, sending confidential values to the model that no person ever typed into a prompt.
Enterprises are betting on autonomy, and the bet is fragile. OWASP’s AI Agent Security guidance names data exfiltration through tool calls, API requests, and agent outputs as a first-class risk, and it is the one agents feed quietly, because these systems touch data no one budgeted for governing. Microsoft’s AI Red Team maps the same failure in agents: untrusted content that flows into an agent’s memory can become a pivot point to exfiltrate data. An agent does not wait for a human to paste in the sensitive material. It reads the material itself, at runtime, from whatever tool the task requires, then carries it forward. That is the specific failure this article is about.
What agent tool-output leakage looks like in practice
Picture an agent handed a routine task: reconcile this week’s failed payments and draft the customer emails. It calls a tool to query the billing database. Back come rows of real customer names, card fragments, amounts, and failure codes. The agent passes that result straight into its next reasoning step, which means straight into the model’s context window. Nobody wrote a line of code that says “send customer records to the LLM.” The agent did it on its own, because reasoning over tool results is exactly how agents work.
Most of the attention in agentic systems goes to what the agent is allowed to do: which tools it can call, which actions it can take, which permissions it holds. The quieter risk is what the agent reads back and then carries into its own context. The action is visible in an audit log. The data riding along inside the reasoning trace usually is not.
Why the tool-to-model hand-off is the leak point
A single-shot prompt has one boundary crossing you can reason about: the text goes out, an answer comes back. An agentic AI workflow has many crossings, and they are dynamic. Every tool call can return real data, and the whole design of the agent is to take that return value and reason over it in the following step. Query a database, read a file, hit an internal API: each result becomes context for the model.
The leak is not the tool call itself, and it is not the final answer. It is the moment the tool’s output is folded back into the model’s working memory. That is the crossing teams forget to govern, because it looks like an internal step rather than an egress.
What makes this slippery is that the path is decided at runtime. You cannot enumerate in advance every record an agent will pull, because the agent chooses based on the task in front of it. The usual reflex, locking the agent out of the sensitive tools, produces the same dead end it produces everywhere: the billing database was the point of the task. An agent that cannot read it cannot reconcile the payments, so you have traded a leak for a system that no longer does the work.
How this differs from a normal prompt leak
The reason agent tool-output leakage slips past controls that catch ordinary prompt exposure is that the sequence is different at several points. A prompt-based check assumes a human author, a single moment, and a readable input. Agentic AI breaks all of those assumptions at once.
Because no person types the data in, the leak never appears as a written prompt for a reviewer to flag. It appears as an internal reasoning step, which most monitoring treats as trusted. That is why a team can pass a prompt-hygiene review and still be exposed. The exposure is not theoretical: the AI Incident Database has cataloged more than 1,500 real-world AI failures.
Closing the tool-to-model hand-off
The durable approach treats each tool result as a boundary crossing on the way back into the model, the same way a careful team treats data going out. When a tool returns rows of customer records, those records are substituted before they reach the model’s context: names, card fragments, and identifiers become consistent stand-ins, while the shape of the data stays intact. Which row owes what, which payment failed and why, all of that structure survives. The agent reasons over a faithful structure and never holds the raw values.
When the agent produces its output, the draft emails or the reconciliation report, the result is reconstructed against the real records inside your environment, so the final artifact is complete and correct. The agent keeps its tools and its autonomy. The values simply stop riding along through every step. In this model the middleware does three things in order: it substitutes the tool output before the model sees it, it lets the agent execute over the faithful stand-ins, and it reconstructs the real values into the finished artifact locally.
The component that sits on that hand-off is a Context-Preserving Data Layer for AI, in CUBIG’s case LLM Capsule. It intercepts each tool result, applies the substitution, and rebuilds the output at the end. Because the stand-ins are consistent across steps, an agent can reference in step two the same entity it saw in step one and still reason correctly, without the underlying values ever entering the model.
A quick self-diagnostic for your agents
Run this check against any agentic AI workflow you already have in production or in a pilot. If you answer no to more than one, the tool-to-model hand-off is likely an open leak path.
- Can you name every tool your agent can call that returns confidential or regulated data?
- When a tool returns real records, do those values enter the model’s context unaltered?
- Could you reconstruct, after the fact, which sensitive records passed through a given run?
- Does your current control depend on blocking a tool the task actually needs?
- If a reviewer read only the prompts, would they see the sensitive data the agent handled?
Where it fits in CUBIG’s operating layer
Agent tool-output leakage is the agentic cousin of retrieved-context leakage in RAG workflows, where the carrier is a retrieved chunk rather than a tool result. Both are instances of LLM data egress, the broader point that sending data to a model is a perimeter crossing whether a human or an agent initiates it. Closing the hand-off is what lets multi-step agents run under sensitive AI workflow enablement, which runs on Syntitan, CUBIG’s AI-Ready Data Platform.
LLM Capsule holds the boundary at the tool call, not just the prompt. A tool result is substituted before it flows back to the model, so the agent finishes the task without raw values re-entering the context.
