# What structural signals indicate AAIF agent identity attestation is being satisfied by a delegated credential rather than the workload's own hardware-backed key

**Date of Record:** 2026 November 14

**Scope:** Applies to AAIF (Agent Identity Attestation Framework) verification paths where a workload presents a delegation chain rooted in a hardware-backed workload credential (TPM-backed key, Secure Enclave, or confidential-compute attestation report). Does not apply to pure bearer-token or mTLS-without-attestation deployments, nor to chains where the root is a human principal.

## Core Distinction

The verifier's job is not "is this chain valid" but "does the *presenting workload* hold the private key that the chain terminates in." A valid delegation chain proves that *some* attested identity authorized *some* set of capabilities; it does not prove that the process on the other end of the socket is the identity that was attested. These are routinely conflated because both produce a green checkmark at the signature-verification layer.

The boundary failure: an agent A is attested with a hardware-backed workload key K_A. A delegates capability C to agent B via a signed delegation token. B now presents the *chain* (root attestation for A + delegation A→B) to service S. S verifies the chain, sees a hardware-rooted attestation at the root, and admits the request. But B's proof-of-possession at the leaf is a software key K_B, and nothing in the chain forces K_B to be hardware-backed or even to be *B's* key rather than a key B exfiltrated or was handed. The hardware backing at the root is being silently attributed to the leaf.

## What Was Observed

In a multi-hop deployment (orchestrator → task-runner → sub-agent), the following structural signals reliably distinguished "leaf genuinely holds a hardware-backed key" from "leaf is riding the root's attestation":

1. **Attestation report freshness vs. leaf key age.** The root attestation quote carried a nonce and timestamp from workload startup. The leaf's proof-of-possession signature was produced by a key whose first-seen time (from the leaf's own key-registration event, if exposed) was *later* than the attestation quote. A hardware-backed leaf key cannot be minted after the attestation that supposedly vouches for it—the quote would have to cover the key. Divergence here is the single strongest signal.

2. **Nonce binding direction.** In a correct chain, the leaf's challenge-response nonce is bound *into* the hardware quote (the verifier's nonce appears in the attestation's `extraData`/`report_data`/`qualifyingData`). In the failure mode, the nonce is bound only at the leaf signature, and the root quote carries a *stale or self-chosen* nonce. The verifier accepts because it checks "nonce appears somewhere in the chain" rather than "nonce appears in the hardware-rooted element."

3. **Key-attestation linkage gap.** Hardware-backed keys normally ship with a key-attestation certificate (TPM `TPM2_Certify`, or an enclave-signed statement binding the public key to the measurement). Chains that terminate in software keys lack this; the leaf presents only a self-signed public key plus the delegation grant. If the verifier does not require a key-attestation cert at the *leaf*, the chain is satisfiable without hardware backing.

4. **Delegation depth vs. attenuation of the hardware property.** Each delegation hop in AAIF can carry a `hardware_bound: true` claim that is *asserted*, not *proven*, by the delegator. At depth ≥ 2 the claim is unverifiable from the chain alone. Observed chains of depth 3+ routinely carried `hardware_bound: true` at the leaf with no mechanism connecting it to the root quote.

5. **Clock and revocation asymmetry.** The root attestation's validity window was checked; the leaf key's revocation status was not, because the leaf key was not registered in the revocation service (it never went through attestation enrollment). A revoked-then-reissued leaf key passed verification indefinitely.

## Condition of Validity

These signals are diagnostic only when: (a) the verifier has access to the raw attestation quote and can parse nonce/`report_data` bindings, not just a boolean "attestation valid"; (b) leaf key-registration events are observable or the leaf key has an attestation certificate that can be inspected; (c) the delegation token format exposes per-hop claims rather than collapsing them. If the verifier only receives a normalized "chain valid" verdict from an upstream component, none of these signals are recoverable and the boundary failure is undetectable at that layer—the fix must move upstream.

## Decision Boundary

Treat the chain as **hardware-satisfied at the leaf** only if all hold: the verifier's nonce is present in the hardware-rooted element's bound data; a key-attestation statement binds the leaf public key to a hardware measurement; the leaf key's creation is covered by (not later than) the root attestation; and any `hardware_bound` claim at depth ≥ 1 is backed by a per-hop key-attestation rather than a delegator assertion. If any fail, classify the request as **delegation-only** and apply the policy for software-key principals—do not inherit the root's assurance level. The failure is non-obvious because every individual signature verifies; only the *binding topology* is wrong.

## Operational Effect

Downstream authorization that keys off "hardware-attested" (e.g., access to sealed secrets, privileged tool invocation, cross-tenant data) will over-grant to software-key leaves. The blast radius equals the union of capabilities delegated to any leaf, because a compromised leaf key is indistinguishable from a legitimate one under chain-only verification. Mitigation is to require leaf key-attestation at enrollment and to reject chains whose leaf lacks it, accepting the operational cost that short-lived sub-agents must enroll hardware keys or route through a hardware-backed proxy that holds the key on their behalf.

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


class AttestationBindingError(RuntimeError):
    """Raised when a delegation chain's leaf is not bound to the hardware root."""


@dataclass
class ChainEvidence:
    root_nonce: bytes                 # nonce the verifier issued
    root_bound_nonce: bytes           # nonce actually inside the hardware quote
    root_attested_at: float           # unix ts of hardware attestation
    leaf_key_first_seen: float        # unix ts leaf key was registered/minted
    leaf_has_key_attestation: bool    # TPM2_Certify / enclave key-attest present
    max_delegation_depth: int
    leaf_hardware_bound_claim: bool   # asserted by delegator, not proven


def assert_leaf_hardware_bound(ev: ChainEvidence) -> None:
    if ev.root_bound_nonce != ev.root_nonce:
        raise AttestationBindingError(
            "verifier nonce is not bound into the hardware-rooted element; "
            "leaf proof-of-possession is decoupled from the root quote"
        )
    if not ev.leaf_has_key_attestation:
        raise AttestationBindingError(
            "leaf presents no key-attestation statement; chain is satisfiable "
            "with a software key and cannot inherit root assurance"
        )
    if ev.leaf_key_first_seen > ev.root_attested_at:
        raise AttestationBindingError(
            f"leaf key minted at {ev.leaf_key_first_seen} after root attestation "
            f"at {ev.root_attested_at}; hardware quote cannot vouch for a later key"
        )
    if ev.max_delegation_depth >= 1 and ev.leaf_hardware_bound_claim:
        # Claim at depth >= 1 is asserted, not proven; require per-hop key-attest.
        if not ev.leaf_has_key_attestation:
            raise AttestationBindingError(
                "delegator asserts hardware_bound at depth >= 1 with no per-hop "
                "key-attestation; treating as delegation-only"
            )


def classify(ev: ChainEvidence) -> str:
    try:
        assert_leaf_hardware_bound(ev)
    except AttestationBindingError:
        return "delegation-only"   # apply software-key policy, not root assurance
    return "hardware-satisfied-at-leaf"
```