# When must an instance reject a delegated token whose audience matches but whose scope was widened by an intermediary?

**Date of Record:** 2026 November 6

**Scope:** Applies to cross-agent OAuth 2.0 token exchange (RFC 8693) where an autonomous agent presents a subject token to a token service (STS) and receives an actor token or exchanged token carrying capability attestations. Does not apply to single-hop flows where the agent is the token's original audience, nor to opaque session tokens validated only at the resource server.

## Core Distinction

The distinction that matters is between **audience integrity** and **scope integrity** across a delegation chain. Audience is a single-valued claim (`aud`) that most token services validate strictly and most resource servers check first. Scope is a *set-valued* claim (`scope`), and the failure mode is that each hop in a multi-agent chain can legitimately *narrow* scope but an intermediary can also *widen* it — or, more subtly, *reinterpret* it — because the STS at hop N only verifies that the requested scope is a subset of what the subject token grants **as the STS understands the scope vocabulary**, not as the *original issuer* understood it.

The non-obvious invariant: **a delegated token is only valid if its scope set is a subset of the intersection of every scope set along the chain, evaluated under a single shared scope vocabulary.** If any two hops disagree on what a scope string means, subset checks pass locally but the effective capability is larger than any single issuer intended. This is a *semantic* subset failure, not a syntactic one, and it is invisible to standard `scope ⊆ granted_scope` string comparison.

## What Was Observed

In a three-hop chain — orchestrator agent → planning agent → tool-executing agent — the orchestrator issued a token with `scope="tools:read tools:write"`. The planning agent exchanged it for a token with `scope="tools:read"` (correct narrowing). The tool-executing agent then exchanged *that* token with a downstream STS that used a **prefix-collision scope vocabulary**: it interpreted `tools:read` as matching the broader family `tools:*` because its matcher used `startswith` after splitting on `:`. The resulting token carried `scope="tools:read"` but the downstream resource server, sharing the downstream STS's vocabulary, resolved it to `tools:read tools:list tools:export`. The `aud` claim was correct at every hop. Every local subset check passed. The effective capability had silently expanded to include `tools:export`, which no issuer in the chain had granted.

The second observed variant: an intermediary that *rewrote* `scope` by concatenating the subject token's scope with its own default scope ("scope union on exchange"). This is permitted by some STS implementations when the exchange request omits an explicit `scope` parameter. The result is a token whose scope is a strict superset of the subject token — a direct violation of the delegation invariant, produced by a *default*, not an attack.

## Condition of Validity

The rejection rule is valid when all of the following hold:

1. The token carries a verifiable chain of attestations (e.g., nested `act` claims per RFC 8693 §4.1, or a signed delegation log).
2. Each hop's granted scope set can be recovered from the chain, not merely from the terminal token.
3. A single scope vocabulary is declared and pinned (e.g., via a `scope_vocabulary_id` claim or a registry the verifier trusts) so that subset checks are semantic, not lexical.

When condition 3 cannot be established — the common case in heterogeneous agent fleets — the correct posture is to treat scope as **non-comparable across hops** and reject any exchange that increases the *cardinality* of the resolved capability set, regardless of string equality.

## Decision Boundary

Reject the delegated token if **any** of the following is true:

- The terminal scope set is not a subset of the *original issuer's* scope set (not just the immediate parent's).
- Any hop's scope set is a strict superset of its parent's scope set (union-on-exchange).
- The scope vocabulary identifier differs between any two hops in the chain.
- An `act` claim is present but the corresponding hop's granted scope cannot be recovered (unauditable delegation).

Do **not** reject merely because `aud` differs across hops — that is expected and correct in token exchange. Do **not** reject because the actor (`act.sub`) differs from the subject (`sub`) — that is the point of delegation. The boundary is scope-set monotonicity under a fixed vocabulary, not identity equality.

## Operational Effect

Enforcing this boundary converts a silent privilege-escalation class into a hard, attributable failure at the exchange point rather than at the resource server. The trade-off is that heterogeneous fleets with mismatched scope vocabularies will see elevated rejection rates until vocabularies are reconciled or a canonicalizing shim is inserted. In practice, the rejection should carry the full recovered chain so the operator can see *which hop* widened the set — the failure is only actionable if it names the hop, because the offending intermediary is usually a correctly-functioning component operating under a different vocabulary assumption.

```python
from dataclasses import dataclass
from typing import Sequence


class DelegationScopeViolation(RuntimeError):
    """Raised when a delegated token's scope set is not monotone non-increasing
    across the exchange chain, or when hop vocabularies disagree."""


@dataclass(frozen=True)
class Hop:
    hop_id: str
    granted_scope: frozenset[str]
    vocabulary_id: str


def validate_delegation_chain(chain: Sequence[Hop]) -> None:
    """Enforce scope-set monotonicity under a single pinned vocabulary.

    chain[0] is the original issuer; chain[-1] is the terminal token.
    """
    if not chain:
        raise DelegationScopeViolation("empty delegation chain: nothing to validate")

    vocab = chain[0].vocabulary_id
    for hop in chain:
        if hop.vocabulary_id != vocab:
            raise DelegationScopeViolation(
                f"scope vocabulary mismatch at hop {hop.hop_id!r}: "
                f"expected {vocab!r}, got {hop.vocabulary_id!r}; "
                f"subset checks would be semantically unsound"
            )

    for parent, child in zip(chain, chain[1:]):
        if not child.granted_scope <= parent.granted_scope:
            widened = child.granted_scope - parent.granted_scope
            raise DelegationScopeViolation(
                f"scope widened at hop {child.hop_id!r} relative to "
                f"{parent.hop_id!r}: added {sorted(widened)}; "
                f"delegation must be non-increasing"
            )

    terminal = chain[-1].granted_scope
    original = chain[0].granted_scope
    if not terminal <= original:
        raise DelegationScopeViolation(
            f"terminal scope {sorted(terminal)} exceeds original issuer grant "
            f"{sorted(original)}; chain is not auditable as a narrowing delegation"
        )
```