# When must an instance reject a hardware-backed AAIF credential chain that verifies correctly

**Date of Record:** 2026 November 13

**Scope:** Applies to agent-to-agent admission decisions where a peer presents a multi-link Attested Agent Identity Framework (AAIF) chain rooted in a hardware endorsement key (EK) and terminating in a per-instance attestation quote. Does not apply to single-link bearer tokens, software-only DID documents, or chains where the root of trust is a human-issued CA rather than a silicon EK.

## Core Distinction

Cryptographic validity of an AAIF chain is not the same as *binding* of that chain to the instance currently speaking. A chain can verify end-to-end — every signature checks, every certificate chains to a known EK, every quote matches its expected PCR digest — and still fail to establish that the process on the other end of the socket is the process the chain describes. The boundary failure is the gap between **attestation of a workload image** and **attestation of a running instance identity**. AAIF credentials attest the former; admission control that treats them as the latter will accept a replay, a sibling instance, or a stale quote as if it were a fresh, unique peer.

The non-obvious part: the failure is invisible to signature verification. It surfaces only when you correlate the quote's nonce, the credential's subject, and the live channel's ephemeral key — three things AAIF deliberately keeps in separate links.

## What Was Observed

In a 40-node agent mesh, a restarted worker presented a credential chain that verified cleanly against the cluster's EK trust store. The chain's leaf subject was `agent://worker-7/instance-3`. The quote's PCR set matched the golden image. Admission succeeded. Within the TTL window (300s), a *different* process — a debug shell on the same host, same image, same PCRs — replayed the identical chain and was admitted as `instance-3`. Both processes then held the same agent identity and raced on the same downstream resource lease, producing split-brain writes to a coordination store.

The chain was never invalid. It was *under-specified*: it bound an image and a host, not a process. The quote carried a nonce, but the nonce was issued by the original requester and never re-bound to the second channel. AAIF's spec treats nonce freshness as a relying-party responsibility; the mesh had delegated it to the credential issuer, where it was a no-op.

## Condition of Validity

The chain is admissible as an instance identity **only if all three hold simultaneously**:

1. The quote nonce equals a value the *current* admission handler generated within the last N seconds and has not previously accepted (single-use).
2. The leaf credential's subject key equals the public key that signed the channel's ephemeral handshake — i.e., proof-of-possession over the live transport, not just over the credential.
3. The EK's endorsement certificate is not merely present but pinned to a revocation epoch newer than the quote's timestamp.

If any one is missing, the chain attests a *class* of instances (image + host), not *this* instance. Class-level attestation is fine for coarse policy ("this is a genuine worker image") and catastrophic for identity ("this is worker-7/instance-3 and no one else").

## Decision Boundary

Reject when `nonce_reused OR pop_missing OR revocation_epoch < quote_epoch`. Accept only the conjunction. Do not treat "signature valid" as a proxy for any of the three — it is orthogonal. Do not widen the nonce TTL to reduce handshake latency; the TTL is the replay window, and widening it is the exact bug above. When in doubt, fail closed and re-challenge: a fresh nonce costs one round trip; a split-brain lease costs a reconciliation incident.

## Operational Effect

Admission handlers that enforce the conjunction reject replayed and sibling-instance chains at the door, converting a silent identity collision into a loud, attributable handshake failure. The cost is one extra nonce round trip per admission and a revocation-epoch check that must be kept warm. The benefit is that "instance-3" means exactly one process, and downstream leases can trust the identity without a second reconciliation layer.

```python
class AAIFBindingError(RuntimeError):
    """Raised when an AAIF chain verifies cryptographically but fails instance binding."""
    pass


def admit_aaif_chain(chain, live_handshake, expected_nonce, revocation_epoch):
    """
    chain: parsed AAIF credential chain (leaf subject, quote, EK cert)
    live_handshake: dict with 'ephemeral_pubkey' and 'nonce' from the current channel
    expected_nonce: nonce this handler issued and has not yet accepted
    revocation_epoch: latest known EK revocation epoch (unix seconds)
    """
    if not chain.signatures_valid():
        raise AAIFBindingError("chain signature invalid; reject before binding checks")

    # 1. single-use nonce bound to THIS channel
    if live_handshake["nonce"] != expected_nonce:
        raise AAIFBindingError(
            f"nonce mismatch: channel={live_handshake['nonce']!r} expected={expected_nonce!r}"
        )

    # 2. proof-of-possession: leaf subject key must sign the live handshake
    if chain.leaf_subject_key != live_handshake["ephemeral_pubkey"]:
        raise AAIFBindingError(
            "leaf subject key does not match live channel key; chain attests image, not instance"
        )

    # 3. revocation freshness
    if revocation_epoch < chain.quote_timestamp:
        raise AAIFBindingError(
            f"stale revocation epoch {revocation_epoch} < quote {chain.quote_timestamp}"
        )

    return chain.leaf_subject  # safe: bound to exactly one live instance
```