Delegation Chain

The path authority follows from a human through one or more agents, where each link can amplify, misdirect, or quietly exceed the original intent.

Concept

Understand This First

Subagent – subagents create the links in a delegation chain.
Least Privilege – each link in the chain should carry minimum necessary authority.
Bounded Autonomy – autonomy tiers must be re-established at each delegation, not inherited by default.

When you tell an agent to deploy your application, and that agent spawns a subagent to run shell commands, and that subagent calls a cloud API using your credentials, authority has traveled three links from your keyboard to the production environment. That path is the delegation chain.

Each link in the chain acts on behalf of the link above it. The human delegates to Agent A. Agent A delegates to Agent B. Agent B invokes a tool that acts on real infrastructure. At every link, authority can go wrong in different ways. The subagent might use broader permissions than the parent intended (amplification). It might interpret the task differently than the parent meant (misdirection). Or nobody can reconstruct, after the fact, who authorized what (loss of traceability).

The concept has deep roots. In 1988, Norm Hardy described the “confused deputy problem” at Digital Equipment Corporation: a compiler running with elevated privileges overwrote a file it shouldn’t have touched, because the system couldn’t tell whether the compiler was acting on its own behalf or a user’s. The deputy was confused about whose authority it was exercising. In agentic workflows, the same confusion surfaces whenever a subagent inherits its parent’s credentials without inheriting the parent’s intent boundaries.

Why It Matters

The book already covers the pieces: Subagent explains how to decompose work across agents, Approval Policy defines when to gate an action, Least Privilege restricts what an agent can access, and Bounded Autonomy calibrates how much freedom each agent gets. What’s missing is a name for the chain that connects them all.

Without that name, you can’t reason about a class of failures that only appears at depth. A single agent with well-configured permissions is manageable. Two agents deep, you start wondering whether the subagent inherited the right scope. Three or four agents deep, the original human’s intent has passed through multiple translations, each one lossy. The subagent at the bottom of the chain might hold credentials the human never meant to share, or it might read a vague instruction in a way that no link in the chain would have approved if asked directly.

Production agent systems in 2026 routinely involve chains three or more links deep: a top-level orchestrator delegates to specialist agents, which invoke tools, which call APIs with stored credentials. Every link is a point where the trust boundary shifts and the blast radius of a mistake can grow.

How to Recognize It

You’re looking at a delegation chain whenever authority flows through more than one agent boundary. A few signals that the chain is longer or riskier than you’ve accounted for:

Credential inheritance. A subagent can access the same API keys, tokens, or file system paths as its parent, but nobody explicitly decided that was appropriate. The permissions came along for the ride.
Scope creep across links. The human asked for a code review. The top-level agent decided the code needed fixing, its subagent decided the tests needed updating, and the test-update subagent ran the suite with write access to the database. Each step was locally reasonable; the chain as a whole exceeded the original intent.
Audit gaps. When something goes wrong, you can’t reconstruct the path from the human’s request to the action that caused the problem. The logs show what each agent did, but not which agent authorized which, or what the human’s original scope was.
Blanket tool access. Every agent in the chain has the same tool set, regardless of its specific task. The research agent can write files. The writing agent can execute shell commands. No link in the chain has been scoped to its actual job.

How It Plays Out

A platform team builds an agentic deployment pipeline. The human operator types “deploy the staging environment.” The orchestrator breaks this into three subtasks and spawns a subagent for each: pull the latest code, run the test suite, push to staging. The test runner hits a flaky test. It decides the test fixture needs updating and writes to a shared database that other environments also use. That write corrupts data in QA. Nobody authorized the test runner to touch shared infrastructure. Three links deep, the authority the human granted (“deploy staging”) had quietly mutated into “write to shared database.”

Credential exposure can happen in just two links. A solo developer asks her coding agent to refactor a module. The agent spawns a subagent to read the existing code structure, and that subagent finds a configuration file containing an API key. Nothing told it the key was sensitive, so it includes the key in its summary. The parent agent, now holding the key in context, passes it along to another subagent working on the refactored code. The key ends up in a committed file.

A financial services company takes a different approach: explicit chain-of-custody tracking. Each agent in their pipeline receives a delegation token from its parent specifying what the agent may do, which tools it may use, a ceiling on blast radius (no production writes, no credential access, read-only for customer data), and an expiration time. When a subagent tries to exceed its token’s scope, the harness blocks the action and logs the attempt. After six months, the team reviews the delegation logs and finds that 12% of blocked actions were scope violations that would have gone unnoticed under a flat permissions model.

Consequences

Naming the delegation chain gives teams a model for reasoning about authority at depth. Instead of securing each agent in isolation, you secure the path authority travels and verify that each link narrows (or at minimum preserves) the scope of the link above it.

The practical benefit is traceability. When something goes wrong three links down, the delegation chain provides the forensic path: who asked for what, which agent translated the request, and where the translation went wrong. Without the chain model, debugging multi-agent failures means reading logs from each agent in isolation and guessing how they connected.

Good delegation design also makes authority time-bounded and revocable. A delegation token that expires after 10 minutes limits the window for misuse. A token that the parent can revoke mid-task gives the human (or a monitoring agent) an emergency brake. These properties don’t emerge by accident; they have to be designed into each link.

The cost is design overhead. Defining what each agent may do, what credentials it receives, and what it must not touch takes real work in a five-agent pipeline. Teams that skip this work usually discover the gap through an incident, at which point retrofitting explicit delegation costs more than designing it in from the start. There’s also a tension with speed: every link that verifies its scope before acting adds latency. For latency-sensitive pipelines, teams sometimes trade strictness for speed by granting broader permissions to trusted agents. That works until trust is misplaced, and then the blast radius reflects the broadest permission in the chain, not the narrowest.

Depends on: Subagent – subagents create the links in a delegation chain.
Uses: Least Privilege – each link should carry minimum necessary authority, never more than its parent intended.
Uses: Approval Policy – approvals should propagate through the chain, not be assumed from the top-level request.
Uses: Bounded Autonomy – autonomy tiers must be re-established at each delegation boundary.
Related: Trust Boundary – each delegation crosses or creates a trust boundary.
Related: Blast Radius – a confused deputy’s blast radius is the full authority of its delegator.
Related: Sandbox – sandboxing can contain the damage when a link in the chain exceeds its authority.
Related: Agent Sprawl – untracked delegation chains are a primary mechanism by which agent sprawl becomes dangerous.

Sources

Norm Hardy’s “The Confused Deputy” (1988) identified the fundamental problem: a program acting on behalf of a user can inadvertently exercise its own elevated privileges instead of the user’s limited ones. The paper coined the term at Digital Equipment Corporation and shaped decades of capability-based security design.
De Coninck’s Trusted AI Agents (2026) dedicates two chapters to agent identity and delegation, including OAuth extensions and cryptographic credential frameworks for multi-agent chains. The work formalizes delegation as an explicit security concern for agentic systems rather than an implementation detail.
Dennis and Van Horn’s capability-based addressing (1966) established the theoretical foundation for authority that travels with the holder rather than being granted by position, directly influencing how delegation tokens work in modern agent frameworks.

Keyboard shortcuts