Delegation and Transitive Trust: Trust Propagation, Confused-Deputy at Scale, and Chain-Length Limits

Delegation is the reason agent meshes are useful and the reason they are dangerous. A planning agent that needs a database read hands the task to a data agent; the data agent, lacking direct access, hands it to a connector; the connector calls the database. Useful work flowed across three hops. But so did authority — and unless each hop was disciplined, the authority that arrived at the database may be broader than what the planner was entitled to, may have forgotten who originally asked, and may no longer carry why. This is not a hypothetical: it is the confused-deputy problem, described by Norm Hardy in 1988, replayed at the scale and speed of an autonomous mesh. The remedy is not to forbid delegation but to constrain how trust propagates: authority may only shrink along a chain, the original principal and purpose must survive every hop, and the chain must have a bounded length. This article makes those constraints precise and shows why relaxing any one of them collapses a mesh back into ambient authority.

Delegation as authority propagation

Define terms precisely. Delegation is the act of one principal authorizing another to perform an action on its behalf. A delegation chain is a sequence of principals A -> B -> C where each arrow is a delegation, so that C ultimately acts because A set the task in motion. Transitive trust is the property that if A trusts B and B trusts C, some trust in C is implied for A — the transitivity that makes chains possible and makes them hazardous. The critical distinction, standardized in IETF RFC 8693 (OAuth 2.0 Token Exchange), is between delegation and impersonation. In delegation the downstream token records both the original principal and the acting party — a composite of who asked and who is doing — via the act (actor) claim. In impersonation the downstream party simply becomes the original principal, and the acting identity is erased. A mesh that impersonates loses the audit trail and the ability to reason about who is really acting; a mesh that delegates keeps both.

The token-exchange model gives the vocabulary for safe propagation. RFC 8693 lets a caller present a token and receive a new one that is audience-restricted (usable only by the intended next hop), scope-narrowed (carrying fewer rights than the input), and act-annotated (naming the chain of actors). Each of these is a lever against a specific failure: audience restriction stops a token minted for one callee from being replayed at another; scope narrowing enforces that authority attenuates; the actor claim preserves provenance. The rest of this article is, in effect, the argument for why all three levers must be pulled on every hop, and what breaks when they are not.

Transitive trust and its attenuation

Transitivity is not free. If trust were fully transitive and undiminished — A trusts B completely, B trusts C completely, therefore A trusts C completely — then trust would flow through the mesh like current through a superconductor, and any agent reachable through a chain of trusted agents would inherit full trust. That is precisely the pathology to avoid, because it means a single compromised leaf, reachable through enough hops, can present itself as fully trusted at the far end. The discipline that prevents it is attenuation: trust, and the authority it grants, must strictly decrease along a chain. Model the effective authority at hop k as a product of per-hop retention factors, each strictly less than one, so authority decays geometrically with chain length and no chain can deliver more authority than its origin held.

Attenuation has a clean operational meaning in the token model: the scope of the token at hop k must be a subset of the scope at hop k-1, and ideally a proper subset — each delegator hands down only the rights the next hop actually needs. When this holds, two guarantees follow. First, no chain can amplify authority: the connector at the end of a chain cannot do more than the planner at its start authorized, because every intermediate token was a narrowing. Second, the blast radius of a compromised intermediate is bounded by the scope it was handed, not by the union of everything upstream. Attenuation is the single most important invariant of safe delegation, and most real-world delegation failures are, at root, a place where authority failed to attenuate.

Confused deputy, at mesh scale

The confused-deputy problem, named by Norm Hardy (1988), is the situation where a program with legitimate authority is tricked by a less-privileged party into misusing that authority. The classic example is a compiler service with write access to a system directory that a caller induces into overwriting a protected file. The essence is a conflation: the deputy uses its own ambient authority to service a request whose authority should have come from the caller. In a single program this is a known, bounded bug. In an agent mesh it becomes a structural condition, because every agent is a deputy for every other — each holds tools and credentials, and each services requests phrased in natural language by parties it cannot fully vet.

Two mesh properties sharpen the problem. First, prompt injection makes the tricking trivial: an attacker does not need a crafted binary, only text that redirects a downstream agent's use of its authority, exactly the risk catalogued in the OWASP Top 10 for LLM Applications and the OWASP Agentic threat guidance. Second, chaining multiplies the surface: a confused deputy three hops down is acting under authority that originated far away, so the agent that is confused, the agent whose authority is abused, and the agent that gets harmed can all be different principals, and no single agent has the whole picture. MITRE ATLAS documents adversary techniques that exploit exactly this indirection. The countermeasure is the delegation discipline itself: if the deputy acts strictly under a capability the caller delegated — narrowed, audience-bound, and carrying the caller's identity — then it has no ambient authority to be confused into misusing. The confused deputy is defeated by removing the ambient authority that made confusion consequential.

Why the origin principal and purpose must survive every hop

Attenuation bounds how much authority flows; provenance governs whether the flow is legitimate at all. Two pieces of context must survive every hop intact: the origin principal (who set the task in motion) and the purpose (what the task is for). If the origin principal is lost — as it is under impersonation — then the resource at the end of the chain cannot apply policies that depend on who is ultimately responsible, cannot produce a meaningful audit trail, and cannot revoke a specific originator's in-flight delegations. RFC 8693's actor claim exists precisely to carry a chain of acting parties so this is never lost; a mesh should treat any hop that drops it as a policy violation.

Purpose is subtler and just as important. A capability that says may read customer records is silent on why, and an agent that holds it can be redirected to read records for a purpose the originator never intended — a valid capability, an invalid use. Binding a purpose or intent to the delegated authority lets the callee check not only that the caller may do this but that this is what the chain was authorized for. This is the deep reason a mesh trust decision cannot be reduced to access control: access control checks entitlement, but safe delegation must also check that the propagated authority is being used for its delegated purpose. Losing purpose along a chain is how a legitimately-authorized read becomes an exfiltration, with every individual permission check passing.

Chain-length limits: why unbounded transitivity becomes ambient authority

There is a structural argument for bounding chain length that goes beyond convenience. Consider what an unbounded delegation chain converges to. If any agent may delegate to any other, and chains may be arbitrarily long, then the set of agents reachable from a given origin through some chain grows to encompass the whole mesh. Trust that can traverse the entire mesh through enough hops is, functionally, trust that every agent has in every other — which is exactly ambient authority, the property a capability system exists to abolish. Unbounded transitive trust does not merely risk long chains; it asymptotically recreates the ambient-authority model that delegation was meant to replace. Bounding chain length is therefore not a performance tweak but a correctness requirement.

The limit interacts with attenuation to give a clean design rule. Because authority decays geometrically with each hop, a well-attenuated chain becomes useless after a few hops — the leaf's authority shrinks toward nothing — so a small maximum depth is rarely a functional constraint on legitimate work. Set a maximum chain depth, enforce it with a hop counter that every token carries and every hop increments, and reject any request whose depth exceeds the bound. The bound should be small (single digits for most meshes) and justified by the actual delegation topology, not chosen for headroom. A request that legitimately needs a deeper chain is a signal to redesign the task decomposition, not to raise the limit. Combined with attenuation and provenance, a bounded depth turns delegation from an uncontrolled trust-propagation network into a small, auditable, monotonically-narrowing tree.

Putting the constraints together

Safe delegation is the conjunction of three invariants, checked at every hop, none sufficient alone. Attenuation: the scope handed to the next hop is a subset of the current scope, so authority only ever shrinks. Provenance: the origin principal and the purpose survive the hop, carried in the token's actor and purpose bindings, so the resource can reason about who is responsible and what the authority is for. Bounded depth: a hop counter enforces a small maximum chain length, so transitive trust cannot expand to mesh-wide reachability. A hop that violates any one of the three is rejected. Each invariant closes a distinct failure — amplification, confused-deputy and lost audit, and ambient-authority creep — and only together do they make a delegation chain safe to extend.

Notice how economically this composes with a per-interaction trust decision. The zero-trust discipline of re-evaluating every call is exactly where these three checks are applied: each hop is itself an inter-agent interaction, so the same policy engine that verifies capability and reputation also verifies attenuation, provenance, and depth. Delegation, in this framing, is not a separate subsystem but the recursive application of the mesh's single trust decision, one hop at a time, with three additional invariants that only chains require. That is the whole discipline: authority may flow, but only downhill, only with its papers, and only so far.

function accept_delegation(req, incoming_token):
    caller_scope = incoming_token.scope
    # 1. attenuation: requested scope must be a subset of caller's
    if not req.scope.is_subset_of(caller_scope):
        return REJECT("authority amplification")
    # 2. provenance: origin principal + purpose must be present
    if incoming_token.actor_chain is empty or incoming_token.purpose is None:
        return REJECT("missing provenance")
    if req.purpose != incoming_token.purpose:
        return REJECT("purpose mismatch")
    # 3. bounded depth: hop counter under the mesh maximum
    if incoming_token.depth >= MAX_CHAIN_DEPTH:
        return REJECT("chain too deep")
    # mint a strictly-narrower, provenance-preserving, depth+1 token
    return token_exchange(
        scope   = req.scope,                      # subset, per check 1
        actor   = incoming_token.actor_chain + [self],
        purpose = incoming_token.purpose,
        depth   = incoming_token.depth + 1,
        audience = req.next_hop)

Limits and honest caveats

These invariants constrain the propagation of authority; they do not certify the behavior of any single agent, and stating that boundary honestly matters. A perfectly attenuated, provenance-carrying, depth-bounded chain can still deliver a request that a compromised leaf executes maliciously within its narrow scope — the discipline bounds the damage, it does not prevent every misuse. Attenuation also assumes scopes are expressible as sets that support a meaningful subset relation; real permission systems have coarse, overlapping, or hierarchical scopes where subset is ambiguous, and a mesh must invest in a scope algebra precise enough that attenuation is actually checkable rather than nominal. Where subset cannot be decided, the safe default is to reject.

Purpose binding is the least mature of the three in practice. Expressing and checking intent is genuinely hard: purposes are often informal, and an agent can satisfy the letter of a purpose while violating its spirit. Treat purpose binding as risk reduction, not a guarantee, and pair it with the verifiable-claims and containment mechanisms that assume some checks will be evaded. Finally, the depth bound trades flexibility for safety by design; some legitimate workflows will bump against it, and the right response is to revisit the task decomposition rather than to quietly raise the ceiling, because every increment of the bound is an increment toward the ambient authority the whole discipline exists to prevent.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

delegation:
  mode: delegation          # RFC 8693 delegation, NOT impersonation
  max_chain_depth: 4        # small; justified by delegation topology
  require:
    scope_subset: true      # child scope must be subset of parent
    actor_chain: present    # origin + acting parties preserved
    purpose_binding: present
  on_violation: reject      # amplification / missing provenance / too deep
  audience_restrict: true   # token usable only by the named next hop

root = token(scope={"read:orders","read:customers"}, actor=["A"], purpose="report", depth=0)

h1 = accept_delegation(req(scope={"read:orders"}, purpose="report"), root)
assert h1.scope.is_subset_of(root.scope)          # attenuation
assert h1.depth == 1 and h1.actor == ["A","B"]     # provenance + depth

# amplification must be rejected
assert accept_delegation(req(scope={"write:orders"}, purpose="report"), root) == REJECT
# purpose mismatch must be rejected
assert accept_delegation(req(scope={"read:orders"}, purpose="export"), root) == REJECT
# depth overflow must be rejected
deep = token(scope={"read:orders"}, actor=["A"], purpose="report", depth=MAX_CHAIN_DEPTH)
assert accept_delegation(req(scope={"read:orders"}, purpose="report"), deep) == REJECT

Glossary

Delegation

One principal authorizing another to perform an action on its behalf, ideally recording both the origin and the acting party.

Delegation chain

A sequence of principals A -> B -> C in which each arrow is a delegation, so the last acts because the first set the task in motion.

Transitive trust

The implication that if A trusts B and B trusts C, some trust in C is inherited by A — the property that makes chains possible and hazardous.

Attenuation

The invariant that authority strictly decreases along a delegation chain, so scope at each hop is a subset of the previous hop's.

Confused deputy

A component with legitimate authority tricked by a less-privileged party into misusing that authority.

Ambient authority

Standing authority a principal can apply to any request without it being explicitly conferred per action — what capabilities abolish.

Impersonation vs delegation

In impersonation the downstream party becomes the origin and the actor is erased; in delegation both origin and actor are retained.

Actor (act) claim

The RFC 8693 token claim that records the chain of acting parties so provenance survives each hop.

References

1. IETF RFC 8693, OAuth 2.0 Token Exchange (2020)
2. NIST SP 800-207, Zero Trust Architecture (2020)
3. OWASP Top 10 for LLM Applications (2025)
4. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
5. MITRE ATLAS (Adversarial Threat Landscape for AI Systems)
6. SPIFFE — Secure Production Identity Framework For Everyone (CNCF)
7. NIST AI 100-1, Artificial Intelligence Risk Management Framework (AI RMF 1.0)