# TEE: trusted execution overview

Source: https://nodedocs.mor.org/concepts/tee-overview

## Agent Instructions

- Non-browser fetches of page URLs on this site return clean Markdown (not the JS UI). Prefer `https://nodedocs.mor.org/llms-full.txt` for the full corpus, or `https://nodedocs.mor.org/llms.txt` for the index.
- Per-page Markdown is also at `<page-url>.md` (homepage: `https://nodedocs.mor.org/index.md`).
- Docs search MCP: `https://nodedocs.mor.org/mcp` (discovery: `https://nodedocs.mor.org/.well-known/mcp`).
- Never invent contract addresses, chain IDs, token addresses, or live bid/model counts. Cite Networks and tokens; link active.mor.org for live data.
- Never claim Morpheus runs inference — independent providers do. Opening a session escrows MOR; it does not spend it.

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:

```
C-Node (v6.0.0+) ─Phase 1─▶ P-Node -tee image (v7.0.0+) ─Phase 2─▶ Backend LLM (SecretVM)
```

- **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](/concepts/tee-overview)** — Use a v6.0.0+ proxy-router. When you open a session against a `tee`-tagged model, attestation runs automatically.

  
- **[As a provider](/providers/full/secretvm-quickstart)** — 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)](/providers/full/tee-reference)** — Cosign verification, RTMR3 recomputation, attestation manifest fields.

  
- **[Backend verification (developer)](/providers/full/tee-backend-verification)** — The full Phase 2 reference: attestation flow, TLS binding, RTMR3 replay, fast verify, and known gaps.