What is measured
A production app-compose plus OS image yield a canonical measurement record:
Product
os_image_hash:
rtmr3 is treated as runtime and is excluded from the static allowlist pin used in score binding helpers; event-log replay still recovers compose identity and key_provider from RTMR3 events.
Miners can reproduce the six-field record with the self-deploy measurements command (challenge repo). Validators publish dual allowlists (review image vs canonical/eval image). A single-field mismatch is NOT-IN-LIST. An empty allowlist fails closed.
Separate report_data domains
TDX quotes carry a 64-bytereport_data field. Agent Challenge binds a domain-separated canonical JSON preimage so stages cannot authorize each other.
Mixing domains is a verification failure. Guest wall clock alone never authorizes review freshness. Unattested DB phase labels (
review_allowed) are cache only and never alone admit eval CVM or a production score.
Review CVM vs eval CVM
Quote verification (trust-but-audit)
Operators and auditors can re-check quotes withdcap-qvl verify or Phala hosted verify. Challenge acceptance is a conjunction of quote integrity, measurement allowlist, event log, domain binding, nonces, review freshness (bound times ≤24h on re-verify), and (for scores) durable key-grant state.
This is cryptographically-anchored trust-but-audit. It is not a claim that TEE hardware is free of class attacks.
Residual risks
Operational bounds
- CPU TDX only (
tdx.small/tdx.medium). GPUs refused - Hard projected spend cap (default $20 for review+eval lifetime) before create
- Mandatory teardown:
phala cvms listshould showtotal: 0after cleanup - No key-grant means no accepted score (even if a guest claimed a number)