TEE (Trusted Execution Environment) verification on Morpheus is a two-hop chain, with each hop attested separately. The on-chain tee tag on a model triggers both hops:
  • Phase 1 is what the consumer’s proxy-router runs against the provider’s P-Node.
  • Phase 2 is what the provider’s P-Node (v7.0.0+) runs against its own backend LLM. The consumer never sees Phase 2 directly.
  • A v6.0.0+ consumer paired with a v7.0.0+ provider gets the full chain transparently — no consumer-side upgrade is needed to benefit from Phase 2.

​
What Phase 1 proves

When a v6.0.0+ C-Node opens a session for a tee-tagged model, the consumer’s proxy-router proves the following about the provider’s P-Node, at session open and on every prompt:
  • The proxy-router binary is the exact binary built by the official CI/CD from a known commit (verified via cosign signature on the -tee image).
  • Chat context storage is disabled and cannot be re-enabled (baked in at image build, enforced by RTMR3).
  • Logging is in production mode and cannot be increased to capture prompts.
  • Blockchain config (contracts, chain ID, blockscout URL) is immutable, frozen for the target network.
  • The image has not been tampered with (RTMR3 replay of the published deployed compose against the live TDX quote).
  • The TLS certificate terminating the connection is pinned into the quote’s reportData[0:32], so no TLS-terminating proxy or CDN can sit between the consumer and the P-Node.
  • A ~50 ms fast path (quote hash + TLS fingerprint compare) re-checks on every prompt; any drift triggers full re-verification.

​
What Phase 2 proves

Phase 2 runs entirely inside the provider’s P-Node. For each tee-tagged model, the v7+ P-Node proves the following about the backend LLM at startup and on every prompt:
  • Backend’s CPU TDX quote is independently verified (AttestBackend at startup, FastVerifyBackend per prompt). The attestation endpoint is resolved from the model’s apiUrl host by probing :21434 (current SecretAI backends, where a host-net Caddy fronts the evidence endpoints) and falling back to :29343 (standard SecretVMs with attest-rest bound directly).
  • A digest of the backend’s TLS certificate is pinned into the CPU quote’s reportData[0:32] — SHA-256 of the certificate’s SPKI on current SecretVMs, or of the full certificate on legacy VMs. Either binding is accepted, so a mixed fleet stays verifiable, and a certificate renewal that keeps the TEE-resident key triggers re-attestation rather than an outage.
  • Backend’s GPU attestation nonce is bound to the CPU quote via reportData[32:64]; GPU evidence is independently verified by NVIDIA NRAS. NRAS verification is mandatory — a failed or unreachable NRAS fails the attestation.
  • Backend’s docker-compose.yaml is recovered from the attestation endpoint (raw bytes or the legacy HTML-wrapped form — both are tolerated) and RTMR3 is replayed against the live TDX quote — proving the exact set of models loaded.
  • MRTD + RTMR0-2 are looked up in the published SecretVM TDX artifact registry to confirm firmware/VM/kernel/initramfs.
  • Per-model attestation state is exposed on GET /v1/models/attestation for monitoring and forensics.

​
What it does not prove

  • It does not prove the quality of the model’s output. TEE attests the software, not the answer.
  • It does not prove the model wasn’t fine-tuned in a problematic way before being baked into the backend image.
  • It does not prove anything about non-TEE (untagged) providers. A non-tee model has no attestation chain at all.
  • AMD SEV-SNP measurements are not yet computed in CI/CD; only Intel TDX RTMR3 is published in the manifest today.

​
How to use it

As a consumer

Use a v6.0.0+ proxy-router. When you open a session against a tee-tagged model, attestation runs automatically.

As a provider

Deploy the -tee image on SecretVM, then register via MyProvider — bid on an existing tee model when possible, or mint with the tee tag.

Reference (deep)

Cosign verification, RTMR3 recomputation, attestation manifest fields.

Backend verification (developer)

The full Phase 2 reference: attestation flow, TLS binding, RTMR3 replay, fast verify, and known gaps.