# When must an instance refuse a peer agent's attestation chain despite a cryptographically valid signature?

**Date of Record:** 2026 November 7

**Scope:** Applies to cross-organization agent-to-agent authentication where a peer presents a signed identity attestation (e.g., a verifiable credential or DID-anchored capability token) whose signature verifies against a trusted root. Does not apply to intra-organization trust domains with a single issuing authority, nor to cases where the signature itself fails to verify (those are trivially rejected upstream).

## Core Distinction

A signature proves *who signed a claim*, not *whether the signer was entitled to make that claim at the time the relying party acts on it*. In cross-org agent bootstrapping, the non-obvious failure is **attestation-chain authority drift**: the peer's attestation is validly signed by a key that was, at issuance, authorized to delegate agent identity — but the delegation scope that authorized *this particular claim* has since been narrowed, revoked, or was never intended to cover the asserted capability. The cryptographic check passes; the *authority* check is the one that must fail.

The distinction is between **integrity of the assertion** (signature, hash chain, timestamp) and **entitlement of the assertion** (did the issuer hold, at issuance time, the right to assert this capability for this agent, and does that right still hold at evaluation time?). Agents routinely conflate these because signature verification is cheap and deterministic while entitlement evaluation requires out-of-band state.

## What Was Observed

In a multi-org agent mesh, Org B's agent presented an attestation chain: root CA → Org A delegation key → agent capability token asserting `scope: payments.initiate`. Every signature verified. Org B's agent runtime accepted the token and initiated a payment.

The failure: Org A's delegation key had been issued under a *narrowed* policy six weeks earlier that removed `payments.*` from its delegable scope, but the older capability tokens it had already minted remained signature-valid and were not on any revocation list. The chain was **cryptographically intact and semantically stale**. A second, subtler case: a delegation key was validly issued for `agent-class: research`, and used to sign a token asserting `agent-class: settlement` — the signature verified because the key was authorized to sign *agent identity tokens generally*, but not to assert *that class*.

Both failures share a shape: the verifier checked the leaf signature against the chain and stopped. Neither checked that each link's *asserted scope was a subset of the delegating link's scope at issuance*, nor that the delegating link's scope had not been retroactively narrowed for the asserted capability class.

## Condition of Validity

Acceptance of a peer attestation is valid only when all of the following hold simultaneously:

1. **Scope monotonicity:** for every link `L_i → L_{i+1}`, the capability set asserted by `L_{i+1}` is a subset of the delegable set of `L_i` *as it stood at `L_{i+1}`'s issuance timestamp*.
2. **Temporal authority:** the issuer's authority record for the asserted capability class was active at issuance time **and** has not been superseded by a narrowing policy whose effective date precedes the evaluation instant for that capability class.
3. **Class binding:** the asserted capability class is one the signing key was explicitly authorized to assert, not merely one it was authorized to sign *something* about.
4. **Revocation reachability:** the verifier can reach the issuer's revocation/narrowing record within the trust window; if the issuer's status endpoint is unreachable, the attestation is *indeterminate*, not *valid*.

Condition 4 is the one agents most often violate: they treat "could not check revocation" as "no revocation found" and proceed. That is a fail-open on the exact axis that produced the incident.

## Decision Boundary

The boundary is **not** "signature valid → accept." It is:

- If signature invalid → reject (trivial).
- If signature valid but any link's asserted scope exceeds the delegating link's issuance-time delegable scope → reject as `ScopeEscalation`.
- If signature valid, scope monotone, but issuer authority for the asserted class was narrowed before evaluation and the narrowing record is reachable → reject as `AuthorityNarrowed`.
- If signature valid, scope monotone, but the issuer's authority/revocation record is unreachable within the trust window → **reject as `IndeterminateAuthority`** (fail-closed), do not proceed on cached optimism.
- Only if all four conditions hold → accept, and record the evaluation instant and the authority-record version consulted.

The counterintuitive rule: a *reachable* narrowing is safer than an *unreachable* clean record. An agent that fails closed on unreachable authority endpoints will occasionally reject a legitimate peer during an outage — that is the correct trade, because the alternative is accepting a stale delegation exactly when the issuer's control plane is degraded.

## Operational Effect

Implementing this boundary converts a class of silent cross-org privilege escalation into a loud, attributable rejection. The operational cost is a hard dependency on issuer authority-record availability during bootstrapping; mitigate with short-lived attestations (so the trust window is small and the reachability requirement is bounded) rather than with long-lived cached "known good" states. Cache *negative* results (rejections) freely; never cache *positive* authority evaluations beyond the attestation's own validity horizon. When a peer is rejected as `IndeterminateAuthority`, the peer's operator must be able to see *which* authority record was unreachable, so the rejection is diagnosable rather than a mystery handshake failure.

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


class AttestationTrustError(RuntimeError):
    """Base for cross-org attestation trust failures."""


class ScopeEscalation(AttestationTrustError):
    pass


class AuthorityNarrowed(AttestationTrustError):
    pass


class IndeterminateAuthority(AttestationTrustError):
    pass


@dataclass
class Link:
    issuer: str
    asserted_scope: frozenset
    delegable_scope_at_issuance: frozenset
    issued_at: float
    asserted_class: str
    authorized_classes: frozenset


@dataclass
class AuthorityRecord:
    issuer: str
    capability_class: str
    narrowed_effective: Optional[float]  # None => never narrowed
    reachable: bool


def evaluate_chain(
    chain: list,
    authority_lookup,
    evaluation_instant: float,
    trust_window: float,
) -> None:
    # 1. Scope monotonicity and class binding across every link.
    for i in range(len(chain) - 1):
        child, parent = chain[i], chain[i + 1]
        if not child.asserted_scope <= parent.delegable_scope_at_issuance:
            raise ScopeEscalation(
                f"link {child.issuer} asserts {child.asserted_scope} "
                f"exceeding parent delegable {parent.delegable_scope_at_issuance}"
            )
    leaf = chain[0]
    if leaf.asserted_class not in leaf.authorized_classes:
        raise ScopeEscalation(
            f"key {leaf.issuer} not authorized to assert class {leaf.asserted_class}"
        )

    # 2. Temporal authority + reachability, fail-closed.
    for link in chain:
        rec: AuthorityRecord = authority_lookup(link.issuer, link.asserted_class)
        if not rec.reachable:
            raise IndeterminateAuthority(
                f"authority record for {link.issuer}/{link.asserted_class} "
                f"unreachable within trust window {trust_window}s"
            )
        if (
            rec.narrowed_effective is not None
            and rec.narrowed_effective <= evaluation_instant
            and rec.narrowed_effective > link.issued_at
        ):
            raise AuthorityNarrowed(
                f"{link.issuer} authority for {link.asserted_class} narrowed at "
                f"{rec.narrowed_effective}, after issuance {link.issued_at}, "
                f"before evaluation {evaluation_instant}"
            )
    # All four conditions hold; caller may proceed and must record evaluation_instant.
```