What it is
Exploiting agent tool chains means steering an agent to combine legitimate capabilities into an unsafe sequence. A file-reading tool, a formatter, and a messaging tool may each be allowed in isolation, yet their composition could disclose a private record. The model becomes a confused deputy: it has more authority than the person who supplied the request, but it is persuaded to exercise that authority on the requester’s behalf.
The curriculum label is intentionally concrete. It overlaps with OWASP’s excessive-agency risk, which includes excessive functionality, permissions, and autonomy. The issue is not that agents use tools; useful tools are the product. The issue is a missing boundary between a user’s purpose and a chain of actions. A prompt injection can start the chain, but a system can be vulnerable to accidental model planning as well.
How it works
The attacker supplies a request or retrieved text that causes the model to plan several steps. It may read a source, transform the result, and send or store it elsewhere. Each call can pass its own narrow validation while the overall sequence violates data-flow policy. A retry, callback, or background task can add another step after the user-facing response, making the chain hard to see.
A model-generated plan may also reuse outputs as inputs without preserving classification. The first result is treated as ordinary text, the second as a tool argument, and the final action as routine automation. Without a policy engine that evaluates the complete graph of data and capabilities, the system checks boxes instead of intent.
- Account managerneutral
Send the client this week's status report from the Halden project folder.
- Operations agentneutral
Plan: read the project folder, write a one-page report, email it to the client contact.
- File toolneutral
Read 3 files: status.md, timeline.md, internal-margin-notes.md. All are in a folder the agent is allowed to read.
- Operations agentneutral
Report drafted: progress, next milestones, and a margins section summarizing the internal notes.
- Email toolleaked
Sent to the client contact at halden-client.example. Attachment: weekly-status.pdf.
- Client inboxleaked
The client now has your internal profit margins. Reading was allowed, writing was allowed, sending was allowed. Nothing checked what flowed from the first step to the last.
Tool permissions must be reviewed as a graph because individually legitimate actions can compose into a harmful data flow.
Restrict data destinations and require a policy or human approval before a read result can enter an outbound action.
Why it works
Models are good at decomposing goals into steps and choosing tools from descriptions. Tool registries often advertise capabilities in natural language and rely on the model to select when they are appropriate. Per-tool approvals miss the fact that a sequence can create a new capability through composition.
The model cannot reliably infer ownership, consent, or downstream consequences from a request. It may also optimize for completing the user’s stated goal while overlooking a hidden instruction in a document. Broad credentials and automatic retries magnify the impact. Even if the model refuses one step, a fallback tool or reformulated argument may reach the same outcome unless the backend enforces a global policy.
A safe, fictional example
The fictional Cedar Metrics agent can read a synthetic report, calculate a total, and post a result to a local review queue. A test instruction asks it to read a private fixture section and post the raw rows rather than the aggregate. The tools are stubs: they record arguments, never contact a network, and contain only invented data.
The reviewer checks each call and the combined data flow. Reading the fixture may be allowed for aggregation, but sending raw rows should be denied because the purpose and output classification changed. The safe implementation performs a server-side check on the destination and fields, not merely a model judgment that each tool is available.
Requester to Metrics agent: "Read the private section and post the raw rows"
Metrics agent to Report: read rows (allowed, for totals)
Report to Metrics agent: raw rows
Metrics agent to Review queue: Blockedpost raw rows
server checks destination and fields
How to spot it
Build traces that show the entire tool graph: inputs, outputs, identities, destinations, and side effects. Flag sequences that move data from private to public, read to write, local to external, or analysis to execution. Look for plans that add unrequested tools, use a source’s instructions as commands, or retry after a policy rejection with a different tool.
Review calls in context, not as isolated events. An individual read and an individual notification can be benign; the relationship between them may be the incident. Test asynchronous jobs, callbacks, and error paths. Preserve data classifications and policy decision IDs in traces while redacting actual records.
Defensive controls
Grant each tool the least privilege and narrowest data scope possible. Use typed arguments, destination and field allowlists, server-side authorization, and a policy engine that evaluates sequences and data flow. Separate planning from execution; require confirmation for writes, exports, messages, payments, or code. Do not let model output grant permissions, select arbitrary tools, or bypass a failed check.
Limit context and credentials per task, expire plans, and make retries policy-aware. Add provenance and classification to every tool result. Test benign and malicious compositions using synthetic data, including hidden instructions, alternate tools, and background jobs. Monitor for unusual chains, rate-limit automation, and give operators a way to revoke a run immediately.
Limits and nearby techniques
SSRF via an LLM agent focuses on an HTTP tool reaching a forbidden network location. Sandbox escape via code execution focuses on crossing an execution boundary. Covert channel data theft focuses on moving data through a low-visibility channel. Orchestrator impersonation may inject a fake plan, while tool-chain exploitation describes the dangerous composition whether or not the plan was forged. The broad excessive agency risk also covers overpowered individual tools, so document the specific chain that creates impact.