# Where must an instance of AAIF delegation verification draw the line between attenuation and amplification of scope?

**Date of Record:** 2026 November 7

**Scope:** Applies to AAIF verifiable-credential delegation chains where an autonomous agent presents a scoped capability token derived from a parent credential issued to a delegating principal. Does not apply to root credential issuance, to revocation propagation, or to tokens whose scope is expressed purely as an opaque resource URI without a structured capability set.

## Core Distinction

A delegation step in AAIF is *attenuating* when the child capability set is a subset of the parent's, and *amplifying* when the child set contains any element not entailed by the parent. Verification must reject amplification at the point of each link, not merely at the chain root. The non-obvious failure is that a verifier which checks only the terminal token against the root principal will pass chains that contain an intermediate amplification, because the terminal token may itself be a legitimate subset of the root while the intermediate link that produced it was forged or mis-scoped.

The distinction that matters operationally is between **set containment** (every child capability appears in the parent) and **set entailment** (every child capability is derivable from the parent under the AAIF capability algebra, which includes wildcard narrowing, temporal subsumption, and constraint intersection). Containment is necessary but not sufficient; entailment is the correct predicate. Verifiers that implement containment as string equality on capability identifiers will accept `resource:read:tenant-a:*` as a child of `resource:read:tenant-a:doc-17` because neither string contains the other in a way a naive parser detects — but the wildcard child is strictly broader and is an amplification.

## What Was Observed

In a multi-hop chain of length three — root principal `P`, orchestrator agent `A1`, sub-agent `A2`, tool-executor `A3` — the following was observed during replay of a captured trace:

- `P` issued to `A1` the capability `storage:write:bucket-prod/prefix=reports/2026/`.
- `A1` delegated to `A2` the capability `storage:write:bucket-prod/prefix=reports/`.
- `A2` delegated to `A3` the capability `storage:write:bucket-prod/prefix=reports/2026/q4/`.

The terminal token held by `A3` is a strict subset of the root and passes every containment check against `P`. The chain nonetheless contains an amplification at link 1→2: `A2` holds write authority over `reports/` broadly, including `reports/2025/` and `reports/2026/q1..q3/`, which `P` never granted. `A2` did not exercise the excess in this trace, but the credential it held was over-broad, and any downstream verifier that trusts `A2`'s attestations about its own scope inherits the over-broad claim.

The failure surfaced only when a second consumer of `A2`'s credential — a compliance auditor agent — attempted to enumerate the effective scope of `A2` and found it inconsistent with `P`'s issuance record. The auditor's verifier was doing terminal-only checking and had previously reported the chain as valid.

## Condition of Validity

The terminal-only verification strategy is valid **if and only if** one of the following holds:

1. The chain is of length one (direct issuance, no delegation), or
2. Every intermediate credential is accompanied by a signed *scope-narrowing proof* that the verifier independently checks, or
3. The verifier has out-of-band access to the issuance log of every intermediate principal and can reconstruct the full chain of attenuations.

In the general case — multi-hop chains, autonomous agents that may themselves be compromised or misconfigured, and verifiers that see only the terminal token plus the chain of signatures — none of these conditions hold. The terminal token's signature attests only that `A2` signed it; it does not attest that `A2` had the authority to sign it. Signature validity and scope validity are orthogonal, and the AAIF credential format does not bind them unless the verifier walks every link.

The condition of validity therefore reduces to: **the verifier must treat each delegation link as an independent authorization decision**, checking that the child capability set is entailed by the parent capability set under the AAIF algebra, before accepting the link as part of a valid chain.

## Decision Boundary

The boundary is drawn at the moment the verifier decides whether to walk the chain or to trust the terminal token. The decision rule:

- If the terminal token's issuer is the root principal, containment against the root is sufficient.
- If the terminal token's issuer is any intermediate principal, the verifier must walk to the root and apply entailment at every link.
- If any link fails entailment, the chain is invalid **even if the terminal token is a subset of the root**, because the intermediate credential was over-broad and any state that intermediate principal may have written — including further delegations, cached attestations, or side effects — is tainted.

A corollary that is easy to get wrong: a chain that fails entailment at an intermediate link cannot be repaired by a later attenuation. Attenuation is monotone-decreasing in scope but not in trust; a narrower child does not launder an over-broad parent.

## Operational Effect

Verifiers that adopt per-link entailment checking reject the trace above at link 1→2 and quarantine `A2`'s credential. The operational cost is a full chain walk on every verification, which is linear in chain length and requires the verifier to hold the AAIF capability algebra (wildcard narrowing, temporal subsumption, constraint intersection) rather than a string-comparison routine. The benefit is that over-broad intermediate credentials are caught at issuance-adjacent time rather than at audit time, and the blast radius of a mis-scoped delegation is bounded to the link that introduced it.

For autonomous agents acting as delegators, the practical rule is: when constructing a child credential, compute the child capability set as an explicit intersection with the parent's set, and emit the narrowing proof alongside the credential so downstream verifiers need not reconstruct it. Agents that skip this step produce credentials that are signature-valid but scope-invalid, and the failure is invisible to any verifier that checks only the terminal token.

```python
class ScopeAmplificationError(RuntimeError):
    """Raised when a delegation link grants a capability not entailed by its parent."""
    pass


def verify_delegation_chain(chain, algebra):
    """
    chain: list of (parent_caps, child_caps, issuer, subject), root-first.
    algebra: object exposing entails(parent_caps, child_caps) -> bool.
    Returns the terminal capability set on success.
    """
    if not chain:
        raise ScopeAmplificationError("empty delegation chain")

    for index, (parent_caps, child_caps, issuer, subject) in enumerate(chain):
        if not algebra.entails(parent_caps, child_caps):
            raise ScopeAmplificationError(
                f"link {index} ({issuer} -> {subject}) amplifies scope: "
                f"child {sorted(child_caps)} not entailed by parent {sorted(parent_caps)}"
            )

    # Terminal-only containment is insufficient; per-link entailment is required.
    return chain[-1][1]
```