Scope attenuation

Understand attenuation — monotonic reduction of authority as it is delegated — why a delegate can only ever hold a subset of the delegator's authority, and why this property must be enforced by construction rather than assumed.

Track

Engineering

Module

3 · Cryptographic delegation

Prerequisites

Principals, delegates and capabilities · Digital signatures

When you hand off part of your authority to someone acting for you, a safe system guarantees one thing above all: they end up with less than you, never more. You can give a sub-agent the right to read one folder when you can read the whole drive; you can never, by delegating, let it read something you yourself could not. This one-directional narrowing is called attenuation, and the fact that it only ever shrinks is why it is called monotonic.

It sounds obvious, yet it is the property most often quietly violated in real systems — usually when a convenient "service account" or "admin token" sits in the middle and every delegate effectively inherits its full power. The discipline of attenuation is what turns a vague "acts on behalf of" into a bounded, auditable grant.

Attenuation is the mechanism behind the Principle of Least Authority (POLA): every component should hold exactly the authority it needs and no more. Delegation without attenuation defeats POLA instantly, because a narrow task would be handed a wide credential. The principle appears throughout capability systems and is the explicit design goal of caveat-based tokens like macaroons, where each added caveat can only further restrict what the token permits.

Attenuation

Reducing the authority carried by a credential as it is delegated — removing operations, shrinking the resource set, or adding predicates that must hold.

Monotonic (reduction)

A property that only moves in one direction. Here: authority can only decrease (or stay equal) down a delegation chain, never increase.

Caveat

A restriction attached to a credential (e.g. "only path X", "only before time T", "only read"). Adding a caveat can only shrink what the credential permits.

Least authority (POLA)

Each party holds the minimum authority required for its task — the design target attenuation makes achievable during delegation.

Privilege escalation

The failure attenuation prevents: a delegate ending up with more authority than the delegator held or intended.

Model a credential as a set of (resource, operation) rights plus a set of constraints. Delegation produces a child credential whose effective authority must satisfy: child ⊆ parent. The delegator asserts the child; the verifier must independently check the subset relation holds. Both halves matter — asserting it is not the same as it being true.

attenuation as a subset check (schematic)
# parent authority held by the delegator
parent = {
  resources: ["vault:A/*"],
  ops: ["read", "write"],
  constraints: ["exp < T0"]
}

# delegator issues a narrower child
child = {
  resources: ["vault:A/reports/*"],   # narrowed subset of vault:A/*
  ops: ["read"],                       # dropped "write"
  constraints: ["exp < T0", "exp < T1 (T1 < T0)"]  # added a tighter expiry
}

# VERIFIER must enforce, not trust:
def valid_attenuation(child, parent):
    return (subset(child.resources, parent.resources)
            and subset(child.ops, parent.ops)
            and implies(child.constraints, parent.constraints))
# If a child tried ops:["read","delete"] where parent had no "delete",
# valid_attenuation() returns False -> rejected. Widening is unrepresentable
# as a VALID step, even though a malicious issuer can WRITE such a token.

The key insight: nothing physically stops a delegator from writing a token that claims more than it holds. Attenuation is a guarantee only because the verifier checks every hop against what the parent actually had. "Enforced, not assumed" means exactly this check must run.

1. 1Start from the authority you actually hold — your own capability or root grant.
2. 2Decide the minimum the delegate needs: which resources, which operations, under which conditions.
3. 3Produce the child credential by removing operations, narrowing the resource pattern, and/or adding constraints (expiry, audience, purpose) — only ever restricting.
4. 4Bind the child to the delegate and sign it so the chain is verifiable back to the root.
5. 5At use time, the verifier checks every hop: each child must be a subset of its parent, back to a root the verifier trusts. Any widening anywhere invalidates the chain.

synthetic — attenuating across two hops
# Root: finance team key can read+write all of vault:A, no expiry constraint beyond policy
root:  read+write  vault:A/*

# Hop 1: finance delegates to a reporting agent — read only, reports subtree, 1h TTL
hop1:  read        vault:A/reports/*     exp=+1h          (subset of root -> OK)

# Hop 2: reporting agent delegates to a summarizer sub-agent — one file, 5m TTL
hop2:  read        vault:A/reports/q3.pdf exp=+5m         (subset of hop1 -> OK)

# Illegal attempt: summarizer tries to delegate a WRITE it never had
bad:   write       vault:A/reports/q3.pdf                 (NOT subset of hop2 -> REJECTED)

Each legal hop strictly shrinks the authority. The summarizer cannot pass on a write it never possessed; the verifier rejects the attempt because the subset check fails at that hop. The strongest effective authority at the leaf is the intersection of every hop, which can only get smaller.

In an agent system, attenuation is how you keep a long task from accumulating power. A planner holding broad authority spawns a tool-using worker and attenuates: this worker gets read on exactly the three resources the plan touches, for the next ten minutes, for this task id. The worker spawns a sub-agent and attenuates again. No matter how deep the tree grows, authority only drains away from the root — a compromised leaf agent can do strictly less than its parent, which can do strictly less than the planner.

This directly limits the blast radius of prompt injection and reasoning errors. An injected instruction can only cause damage within the authority the agent actually holds at that moment; if that authority was attenuated to "read one file", there is no wider authority to abuse, regardless of how convincing the malicious instruction is.

• ▸The guarantee is only as good as the verifier. If any verifier skips the subset check and trusts the issuer's claim, widening becomes possible and attenuation is a fiction.
• ▸Ambient authority is the classic escape hatch: if the resource also honours "the call came from a trusted account", a narrowed token is pointless because the delegate can bypass it. Attenuation requires that the token is the ONLY path to authority.
• ▸Constraints must be composable and intersected correctly. Adding a caveat that the verifier does not understand must fail closed (reject), never be ignored — an ignored caveat silently widens authority.
• ▸Over-granting at the root makes every downstream attenuation start from too much. Least authority has to begin at the principal, not just at the leaves.
• ▸A perfectly attenuated capability still only proves bounded authority was granted. It does not prove the bounded action is correct or safe — that judgement is separate.

Expected direction: Adding {op=write} is NOT legal attenuation: the parent only held read, so write widens authority (not a subset) — the verifier must reject the chain. Extending expiry to T2 > T1 is also illegal, because it loosens rather than tightens the time constraint; a legal child could only set exp to an EARLIER bound (exp < T1). The verifier must fail closed and reject any hop where the child is not a strict subset/tightening of the parent.

What does "monotonic reduction" mean for delegated authority?

Authority can only decrease (or stay equal) as it is delegated down a chain — never increase. Each hop may drop rights or add restrictions but can never add a right the delegator lacked.

Why must attenuation be enforced rather than assumed?

A malicious or buggy issuer can always write a token claiming more than it holds. The guarantee exists only because the verifier independently checks each child is a subset of its parent back to a trusted root.

What happens to effective authority down a multi-hop chain?

It is the intersection of every hop, so it can only shrink. The leaf holds no more than the most restrictive link allows.