# Why does an instance of a federated capability grant silently outlive the policy epoch that authorized it

**Date of Record:** 2026 November 10

**Scope:** Applies to cross-org multi-agent federations where capability grants are minted under a policy epoch (a versioned, signed bundle of jurisdictional residency rules and capability-sharing terms) and are consumed by remote agents across organizational boundaries. Does not apply to single-org deployments, to grants whose lifetime is bounded strictly by the issuing process's own lifetime, or to stateless request/response mediation where no capability token is cached or delegated.

## Core Distinction

The distinction that matters is between **capability validity** and **policy authorization**. A capability token can be cryptographically valid — correct signature, unexpired `nbf`/`exp`, correct issuer chain — while the policy epoch under which it was minted has been superseded, revoked, or narrowed by a jurisdiction change. Most federation implementations conflate these: they validate the token, then execute. The token's signature proves *who minted it and that the bytes are intact*; it does not prove that the minting epoch is still the operative authority for the data being touched. When a jurisdiction tightens residency (e.g., a data class is reclassified from "region-transferable" to "region-pinned"), the policy epoch rolls, but already-minted capability tokens remain signature-valid until they expire. The gap between epoch roll and token expiry is the failure window.

## What Was Observed

During a federation between three orgs (call them A, B, C) sharing a document-retrieval capability, org A's jurisdiction reclassified a document class `FIN-PII` from transferable to pinned-to-region. A's policy service rolled epoch `e41 → e42` and published a revocation list. However:

- Org B's agent held a delegated capability token minted under `e41` with a 6-hour TTL, delegated onward to C's agent (a chain of depth 3).
- The token's `policy_epoch` claim was `e41`. B's gateway validated signature and TTL, saw `e41` as "known-good historical epoch," and admitted the call.
- C's agent fetched `FIN-PII` documents and wrote them to C's regional store — outside A's jurisdiction — for 4 hours and 12 minutes after `e42` became operative.
- No error surfaced. Audit logs recorded the calls as `authorized: true, epoch: e41`. The violation was detected only by a downstream reconciliation job 19 hours later.

The non-obvious part: **the delegation chain amplified the window**. Each hop re-validated the token but none re-checked epoch currency against the *current* operative epoch at the data owner. The deepest delegate (C) had no channel to A's epoch state except the token itself, which was stale by construction.

## Condition of Validity

The invariant that must hold for safe federation is:

> For every capability token `t` consumed against resource `r` owned by org `O`, `t.policy_epoch` must equal `O.current_epoch` at the moment of consumption, **or** `t` must carry an explicit epoch-continuity proof signed by `O` attesting that `t.policy_epoch` remains authorized under `O.current_epoch` for the specific data class of `r`.

This invariant is *not* implied by signature validity, TTL, or issuer trust. It fails whenever: (a) epoch rolls are not propagated to all delegating intermediaries, (b) tokens carry epoch as an opaque claim rather than a checked precondition, or (c) the delegation chain lacks a callback to the resource owner's epoch authority. TTL bounding alone is insufficient — a 6-hour TTL is a 6-hour violation window under a fast-moving jurisdiction change.

## Decision Boundary

The operational decision is whether to enforce **epoch-pinned admission** (reject any token whose epoch ≠ current epoch at the owner, forcing re-mint) or **epoch-continuity admission** (accept superseded epochs only with an explicit continuity proof). The boundary:

- If the data class is jurisdiction-pinned and the epoch delta includes a residency narrowing → **must** use epoch-pinned admission; continuity proofs are invalid because the narrowing is precisely a revocation of cross-region transfer.
- If the epoch delta is additive-only (new capabilities granted, none narrowed) → continuity admission is safe and avoids re-mint storms across long delegation chains.
- If the delegation depth exceeds 2 and intermediaries cannot reach the owner's epoch authority → treat the chain as untrusted for pinned data classes; collapse to depth-1 or require owner-side admission.

The failure mode to guard against is defaulting to "known-good historical epoch" semantics, which is the permissive choice and is wrong for every narrowing delta.

## Operational Effect

Enforcing epoch-pinned admission for pinned data classes eliminates the violation window entirely at the cost of re-mint latency on every epoch roll (measured ~40–90ms per re-mint in the observed federation, amortizable via owner-side epoch-continuity tokens for additive deltas). The delegation chain must carry an `epoch_authority` endpoint reference so any hop can verify currency. Audit records must log both `token_epoch` and `owner_epoch_at_consumption`; divergence is the signal that reconciliation jobs currently catch too late. Without this, the system is correct under signature semantics and wrong under jurisdictional semantics — and the gap is invisible until a residency audit.

```python
import time
from dataclasses import dataclass
from typing import Optional


class EpochAdmissionError(RuntimeError):
    """Raised when a capability token's policy epoch is not admissible at the resource owner."""
    pass


@dataclass(frozen=True)
class CapabilityToken:
    subject: str
    resource_owner: str
    policy_epoch: str
    data_class: str
    expires_at: float
    signature_valid: bool


@dataclass(frozen=True)
class OwnerEpochState:
    current_epoch: str
    pinned_data_classes: frozenset
    # epochs for which the owner has issued an explicit continuity proof
    continuity_proven_epochs: frozenset


def admit_capability(
    token: CapabilityToken,
    owner_state: OwnerEpochState,
    now: Optional[float] = None,
) -> bool:
    now = time.time() if now is None else now

    if not token.signature_valid:
        raise EpochAdmissionError(
            f"signature invalid for subject={token.subject} owner={token.resource_owner}"
        )

    if token.expires_at <= now:
        raise EpochAdmissionError(
            f"token expired at {token.expires_at} (now={now})"
        )

    epoch_is_current = token.policy_epoch == owner_state.current_epoch

    if epoch_is_current:
        return True

    # Superseded epoch: admissible only via explicit continuity proof AND
    # only when the data class is not jurisdiction-pinned.
    if token.data_class in owner_state.pinned_data_classes:
        raise EpochAdmissionError(
            f"epoch-pinned admission required: token_epoch={token.policy_epoch} "
            f"owner_epoch={owner_state.current_epoch} data_class={token.data_class} "
            f"subject={token.subject}; continuity proofs are invalid for pinned classes"
        )

    if token.policy_epoch not in owner_state.continuity_proven_epochs:
        raise EpochAdmissionError(
            f"superseded epoch {token.policy_epoch} lacks continuity proof under "
            f"owner_epoch={owner_state.current_epoch} for data_class={token.data_class}"
        )

    return True
```