AI Agent Chain Security: Why Per-Hop Delegated Tokens Are Needed

When multiple AI agents form a collaborative chain to complete complex tasks, the security boundary is often harder to control than with a single agent. The core problem: if the entire chain shares one set of credentials, any single agent that is compromised or manipulated turns the whole chain into an attacker's stepping stone. A recent analysis of inter-agent communication security points out that per-hop delegated tokens are the key design for shrinking the blast radius.

Where Shared Credentials Fall Short

In the traditional approach, agent chains often share API keys or service account credentials, which amounts to replicating the same identity across every node in the chain. This model is simple and direct functionally, but extremely fragile security-wise: once an agent is manipulated through prompt injection, tool misuse, or other means, the attacker gains permissions equivalent to the shared credentials and can move laterally, invoke downstream agents, and access resources it should never touch.

The article sums up this situation as: one manipulated agent is enough to bring down an entire chain. The problem isn't whether a single agent is robust enough—it's that the permission model doesn't provide a minimized trust boundary for a "chain" topology.

Prompt injection is one of the typical attack methods mentioned here: an attacker hides malicious instructions in content the agent will read (web pages, documents, tool return values, etc.), inducing the agent to deviate from its original task and perform operations the attacker intends. For a single agent, this affects at most its own permission scope; but in an agent chain with shared credentials, the injected agent still holds the credentials for the whole chain, so it can legitimately invoke downstream agents and read sensitive resources, multiplying the attack surface. This is why the permission model must match the topology—prompt injection is hard to eliminate entirely, and the only controllable factor is "what can still be done after being manipulated."

Blast radius, borrowed from the fields of fault domains and security incident response, refers to the maximum scope that a single compromise or mistake can affect. In the context of agent chains, it measures not whether an attack occurs, but the depth of lateral movement and the set of reachable resources after an attack occurs. Common means of shrinking the blast radius include least privilege, credential isolation, and short lifetimes—which are also the starting points for the per-hop token design discussed below.

How Per-Hop Delegated Tokens Work

The idea behind per-hop delegated tokens is: every inter-agent call issues a new token bound to an explicit audience, scope, and validity period. When an upstream agent delegates a task to a downstream agent, it doesn't hand over its own credentials—it exchanges them for a narrow token valid only for the current hop.

This yields several benefits. First, the token's audience is restricted to the specific next-hop agent, so even if leaked it can't be used for other services. Second, the permission scope is narrowed to the minimum set required to complete the current task, preventing downstream agents from casually obtaining access beyond their needs. Third, the token lifetime is short, narrowing the attack window. The article emphasizes that these constraints work together to significantly shrink the blast radius in the event of a compromise.

Audience restriction originates from OAuth 2.0's token design: the token carries an audience field, and the resource server must confirm that the field points to itself during validation, otherwise it denies service. This mechanism is specifically designed to prevent tokens from being "misappropriated" for unintended services—even if a token leaks, an attacker can't use it to call other downstream agents or external APIs. Per-hop delegated tokens apply this idea to the agent topology, making each hop's token valid only for the next hop.

The distinction between delegation and impersonation is also worth explaining: impersonation means the downstream acts with the caller's full identity, with permissions equal to or even greater than the caller's; delegation means the caller proactively grants a restricted, auditable subset of permissions and preserves the chain information of "who delegated to whom" in the token. Per-hop tokens fall into the latter category, so they naturally support tracing the delegation chain and make it easy to quickly locate and revoke when an anomaly occurs at a particular hop.

Engineering Trade-offs of Chained Delegation

Introducing per-hop tokens isn't without cost. Each hop involves token issuance, validation, and auditing, and the longer the chain, the more noticeable the overhead; meanwhile, the token's audience and scope must precisely correspond to the agent topology, and configuration errors may instead cause call failures or permission gaps.

However, from a security architecture perspective, the observability and isolation gained in exchange for this cost are worthwhile. Tokens naturally carry the information of "who delegated to whom, what can be done, and when it expires," making audit logs more traceable. For agent chains involving sensitive tools or external system calls, this fine-grained delegation model is closer to mature zero-trust practices.

Zero Trust's core principle is "never trust, always verify": requests aren't let through by default just because they come from an internal network or a trusted component; instead, every access is re-authorized based on identity, context, and least privilege. Per-hop delegated tokens align closely with this principle—each hop is treated as an independent trust boundary that must be passed with a valid token, rather than relying on the implicit trust shared across the entire chain. In practice, Zero Trust also emphasizes continuous verification and short credential lifetimes, which is consistent with the short validity period design of per-hop tokens.

Implications for Agent System Design

The article's argument points to a larger trend: as agents evolve from single agents to multi-agent collaboration, identity and authorization need to shift from "shared credentials" to "per-hop delegation." When designing agent chains, each hop should be treated as an independent trust boundary, constraining permissions with narrow-scope, audience-bound tokens rather than relying on a single global credential to cover everything.

In other words, the security of an agent chain doesn't depend on the strongest link, but on whether the damage can be contained once the weakest link is compromised. Per-hop delegated tokens are precisely the infrastructure serving this goal.

One-line Summary

Agent chains should abandon shared credentials and adopt per-hop delegated tokens to shrink the blast radius after a compromise.

Paragraph Summary

The article points out that if a multi-agent collaborative chain shares one set of API keys or service account credentials, any agent manipulated through prompt injection or tool misuse gives the attacker equivalent permissions across the entire chain and the ability to move laterally. The solution is per-hop delegated tokens: every inter-agent call issues a new token bound to an explicit audience, minimal scope, and short validity period, and the upstream agent doesn't hand over its own credentials but exchanges them for a narrow token valid only for the next hop. This prevents tokens from being misappropriated for other services after a leak, narrows permissions to what the current task requires, and compresses the attack window. The cost is the overhead of issuance, validation, and auditing at each hop, plus the need for token audience and scope to precisely correspond to the topology, where configuration errors may cause call failures or permission gaps; but the observability and isolation gained align with zero-trust practices.