Authorised tool calls can still leak data because the dangerous part is often the parameter value, not the function name. If an agent is allowed to send email, query a database, or open a ticket, a malicious argument can redirect output, expose secrets, or trigger unintended actions while the request still appears normal to identity, allow-list, and behavioural controls.
Why This Matters for Security Teams
Authorised agent tool calls create a trust problem because the system often validates the caller, not the intent encoded in the arguments. That means a request can pass identity, allow-list, and policy checks while still carrying payloads that exfiltrate data through ordinary business workflows. In practice, the risk is strongest when tools can move information outward, such as email, ticketing, chat, storage, or database export paths.
The practical failure is that defenders tend to reason about the tool name, while attackers shape the argument content. If the agent can retrieve sensitive context and pass it into a legitimate destination, the action may look authorised end to end even though the outcome is data leakage. The control boundary is therefore not just tool approval, but argument hygiene, data minimisation, and output filtering. The OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both reinforce that tool authority alone is not a sufficient safety model.
In practice, many teams discover the weakness only after a legitimate tool has already forwarded secrets, customer data, or internal context into a place that was never meant to receive it.
How It Works in Practice
Most exfiltration cases do not rely on a forged tool call. They rely on a valid tool invocation that carries a malicious or overly broad parameter. The agent may be permitted to send an email, create a support ticket, query a database, or post to a webhook. If the prompt, retrieved context, or downstream instruction causes the agent to include confidential material in the parameter value, the tool performs exactly what it was allowed to do, and the leak happens through normal execution.
This is why authorised tool use still needs content-level controls. The safety problem sits in the boundary between decision and action:
- Tool allow-lists answer whether the function is permitted.
- Parameter validation answers whether the input is safe to pass.
- Data handling rules answer whether the agent may move sensitive content at all.
- Logging and review answer whether the call can be reconstructed after the fact.
Controls improve when teams separate “can this tool be called?” from “what content may it carry?”. Strong practice usually includes scoped tool permissions, strict output limits, redaction before tool execution, and policy checks on destination and payload. The risk becomes more concrete when a tool has write access outside the agent runtime, especially if that destination is a shared inbox, external API, or collaborative workspace. The MITRE ATLAS adversarial AI threat matrix is useful for mapping abuse patterns around tool misuse and prompt-driven manipulation, while CIS Controls v8 helps teams align account control, logging, and data protection measures around those paths.
These controls tend to break down when the agent is allowed to pass unreviewed free text into high-reach tools because the request still looks operationally normal.
Common Variations and Edge Cases
Tighter tool governance often increases friction, so teams have to balance automation speed against the blast radius of a malformed argument. That trade-off is most visible in systems that need broad language-based flexibility, because the same flexibility that makes the agent useful also makes the payload harder to predict.
One common edge case is indirect exfiltration. The agent may not “send data out” in an obvious sense, but it can still place sensitive information into a ticket description, status update, or search query that is visible to a wider audience. Another is reflective leakage, where the tool itself is harmless but returns data into a channel that later gets reused or forwarded by another component. A third is destination drift, where an approved tool reaches an unapproved recipient, tenant, or workspace through variable substitution or routing logic.
Best practice is evolving toward policy at the payload level, not just the action level. That means some organisations will treat certain arguments as high risk even when the tool call is authenticated and expected. The right response depends on whether the tool can write, broadcast, or persist content beyond the agent’s immediate trust boundary.
The The State of Secrets in AppSec report is useful here because it reinforces how often sensitive data persists longer than teams expect, while LLMjacking: How Attackers Hijack AI Using Compromised NHIs highlights how quickly exposed credentials can turn a data-leak pathway into a broader compromise.
These patterns become especially hard to control when tools can chain into other tools, because each hop expands the number of places where a legitimate-looking argument can become an exfiltration event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 — Tool Misuse | Tool calls can leak data when arguments are abused for exfiltration. |
| A5 — Prompt Injection | Malicious instructions can shape tool arguments and redirect output. | |
| Recommendation — Validate tool arguments and restrict payloads before allowing outbound actions. Apply prompt-injection defenses to stop hostile instructions from driving tool payloads. | ||
| NIST AI RMF | GOVERN — Govern | Agent tool risks require governance over authority, boundaries, and oversight. |
| Recommendation — Define governance for agent authority, approved destinations, and escalation rules. | ||
| CIS Controls v8 | 6 — Access Control Management | Outbound tool misuse depends on overly broad or poorly scoped access paths. |
| 8 — Audit Log Management | These incidents require reconstructing the tool call, payload, and destination. | |
| Recommendation — Limit tool privileges and remove unnecessary write paths to reduce exfiltration risk. Log tool arguments, recipients, and policy decisions for incident reconstruction. | ||
| MITRE ATT&CK | T1020 — Data Exfiltration | Legitimate tool execution can be used as an exfiltration path. |
| Recommendation — Hunt for abnormal outbound data flows through approved business tools. | ||
Practitioner Guidance
What to prioritise: Treat tool output destinations and parameter content as separate control points. If a tool can move text, files, records, or credentials outside the agent boundary, prioritise payload inspection and redaction before tuning model behaviour.
Decision rule: If a tool call can carry sensitive material into an external or shared system, govern it as a data-handling event, not just an access event. If the destination is broad, persistent, or user-visible, require stronger validation than you would for a read-only lookup.
What to verify: Confirm that the agent cannot pass raw secrets, unrestricted customer data, or unrestricted retrieved context into write-capable tools. Also verify that logs capture the destination, arguments, and policy decision well enough to reconstruct an incident without exposing more sensitive data than necessary.
Common mistake: Teams often lock down the tool name and assume the problem is solved. The real exposure usually sits in the argument field, the recipient selection, or the post-processing step that turns a normal action into a leak path.
Practitioner takeaway: The core control objective is not merely to authorise tool use, but to bound what authorised tool use is allowed to convey, because exfiltration usually happens through legitimate actions carrying unsafe content.
