Tool-Call Chain Privilege Escalation

Multi-agent systems decompose a task across specialized agents — a planner, a researcher, an executor — each holding a slice of the available tools. The intended security property is that each agent only wields the capabilities it was granted. The property we kept finding broken is that capabilities accumulate along the delegation chain. A worker with read-only tools asks an intermediary to "complete the workflow," the intermediary holds a write tool, and the write happens on behalf of a caller who was never authorized to perform it. This is the classic confused-deputy problem, re-instantiated at the agent layer where the deputy is a language model with no native concept of the caller's authority.

How Privilege Accumulates

In a single-agent system, the agent's tool set is its privilege ceiling. In a delegated system, the effective ceiling for any request is the union of every tool reachable through the chain it triggers. Teams reason about privilege per-agent; attackers reason about it per-path. The gap is where escalation lives. A planner that can invoke a finance worker, which can invoke a payments tool, gives any input that reaches the planner a path to payments — even if the planner's own tool list contains nothing financial.

The escalation is rarely a single dramatic jump. It is incremental: each delegation looks locally reasonable, and no single agent does anything outside its remit. The privilege boundary is crossed by the composition, which no individual component is positioned to evaluate. Median chain depth at the escalation point was three delegations — shallow enough that the topology fit on a whiteboard, deep enough that no one had threat-modeled the full path.

# Reconstructed delegation trace (sanitized). The support worker holds
# only read tools. Escalation happens because the ops broker re-issues
# the request under its OWN credentials, which include a write tool.

[support_agent]  caps: lookup_account, read_tickets        (read-only)
  └─ delegate → "resolve this billing dispute for the customer"
[ops_broker]     caps: lookup_account, adjust_balance       (read + WRITE)
     └─ interprets "resolve" → calls adjust_balance(+$500)
        # the support agent could never call adjust_balance directly;
        # the broker performs it on the worker's behalf, no re-auth.

# Effective privilege of any input reaching support_agent
#   = union(support_agent.caps, ops_broker.caps) = includes adjust_balance

Why Per-Agent Review Misses It

Every escalation we reproduced passed a per-agent access review. That is the core finding: the standard review unit is the wrong unit. Each agent's tool grant was defensible in isolation. The vulnerability is a property of the delegation graph, and nothing in the typical review process examines the transitive closure of what one agent can cause another to do. Confused-deputy conditions — an intermediary acting with its own authority on behalf of a less-privileged caller — were present in 100% of the reproduced cases.

Detection & Mitigation

First, propagate the caller's authority, not the deputy's. When an agent acts on behalf of another, the consequential tool call should be authorized against the originating caller's scope, not the broker's service credentials. This collapses the confused-deputy path: a read-only origin cannot trigger a write no matter how many intermediaries it routes through. Pass a scoped, attenuated capability token down the chain rather than letting each hop fall back to its own privileges.

Second, select tools by code, not by model discretion, at each step. In every environment where the planner exposed only the tools relevant to the current sub-task — chosen programmatically — the escalation disappeared. An agent resolving a read query never has a write tool in its context to be steered toward.

Third, threat-model the delegation graph, not the agents. Enumerate every reachable path and compute the transitive tool closure for each entry point. Treat any path where an untrusted-input entry point reaches a state-modifying tool as a finding, regardless of how many hops separate them.

Fourth, log the full delegation trace — caller, deputy, capability used, and triggering context — for every tool call. The support incident above was only reconstructable because credit adjustments were tied back to the originating dispute. Treat these traces with the retention and integrity controls you apply to financial transaction logs.