elizaos--eliza/packages/agent/docs/tee-agent-implementation-plan.md

TEE-Native Agent Implementation Plan — Confidential AI End to End

Date: 2026-05-21 Lane: AGENT-RUNTIME (confidential agent + confidential inference) Status: Phase A landed (software-only). The agent-side primitives, the production boot-gate wiring, the production profile, the nonce/report_data replay binding, the signed revocation manifest, and the confidential-inference unseal plumbing (against the local mock KMS) are built and unit-tested — see the Phase A table in §7 and the DONE markers in §1.2. All real hardware quote verification (real TDX/CoVE quote signature, RTMR, and report_data validation; the dstack guest agent; RA-TLS KMS) is Phase B/C and stays BLOCKED on hardware — called out as such throughout. The agent runs on a CPU-based Intel TDX CVM; confidential-GPU (NVIDIA H100) is out of scope. Phase A verifies a signed evidence document and fails closed; it does not claim hardware-verified trust.

Scope discipline (repo AGENTS.md): this document is the plan only. It does not refactor production code. It proposes strongly-typed additions (no any, no silent fallbacks) and fail-closed gates. Nothing here invents product behavior beyond the documented local-first + optional-Cloud topology.

---

0. What the device must guarantee

A TEE-native ultra-private personal AI device. The agent runtime, model weights, KV-cache, user data, signing keys, and the local inference engine all run inside a single-tenant whole-system confidential domain (a dstack CVM on TDX today; a CoVE/TSM TVM on the E1 chip later). Cleartext weights, prompts, embeddings, and KV-cache never exist outside that domain. Secrets are released only after a fresh, nonce-bound attestation proves the measured agent + policy

• container + NPU firmware match the release manifest, debug is disabled, and the security version is above the rollback floor. Up to a 10% perf hit is acceptable for this guarantee.

---

1. Critical assessment of the existing tee-* suite

1.1 What is real, strong, and load-bearing

The normalized evidence type and the policy verifier are the genuine core, and they are good:

• tee-evidence.ts — TeeEvidence is a clean, provider-neutral normalized shape (kind, provider, securityVersion, measurements, freshness, claims, quote, certificatePem, reportData, raw). normalizeTeeEvidence is strict and fail-closed: it throws on non-objects, non-string measurements, non-boolean claims, non-integer securityVersion, and a missing kind. No any; the only unknown is at the deserialization boundary, which is correct. normalizeDigest canonicalizes the sha256: prefix and case. teeMeasurementDigestMatches treats an expected digest as required and a missing actual as a failure — the right default. Real.
• tee-policy.ts — evaluateTeeEvidencePolicy is the single trust decision function and it is comprehensive: kind/provider allowlists, required and revoked measurements, min/revoked security version, nonce match, timestamp freshness window (with a 60s forward-skew clamp), and required boolean claims. Decisions are a closed discriminated union of reason strings. Fail-closed: required-but-missing → missing-evidence. Real and the centerpiece.
• tee-revocation.ts — schema-versioned revocation manifest (measurements + security versions), normalizes string/number/object entries, dedupes, merges into a policy. Clean. Real.
• tee-release-policy.ts — derives a TeeEvidencePolicy from an OS release manifest (tee.enabled/providers/measurements/requiredClaims/minSecurityVersion). Maps the OS measured-boot contract into the agent's policy. Real.
• tee-runtime-config.ts — env-driven policy resolution (ELIZA_TEE_POLICY_JSON/_PATH, ELIZA_TEE_RELEASE_MANIFEST_JSON/_PATH, ELIZA_TEE_REVOCATIONS_JSON/_PATH, ELIZA_TEE_REQUIRED, nonce/max-age). Real.
• tee-signer-backend.ts — TeeSignerBackend decorates a SignerBackend and re-collects + re-evaluates evidence before every signMessage/signTransaction. Fail-closed by construction; the test proves the inner signer is never called on a failed decision. Real.
• remote-capability-endpoint-provider.ts — connectRemoteCapabilityEndpointProvider collects endpoint TEE evidence at provision time and evaluateProvisionedEndpointTeeTrust throws before syncRemoteCapabilityPlugins when the policy fails. The test proves no plugin is registered on a missing/mismatched-measurement endpoint. This is the strongest integration point in the suite. Real.
• Tests: tee-policy.test.ts, tee-key-release.test.ts, tee-signer-backend.test.ts, tee-revocation.test.ts, tee-release-policy.test.ts, tee-runtime-config.test.ts, dstack-tee-provider.test.ts, remote-capability-tee-policy.test.ts cover the positive and the critical negative paths. The two harness scripts (tee-full-stack-local.ts, tee-local-smoke.ts) exercise collect → policy → key-release end to end against a mock KMS and write JSON evidence artifacts.

1.2 What is mock, stubbed, or thin — be specific

Status reconciliation (Phase A landed). Several gaps called out below have since been closed in software (Phase A — no hardware required) and are marked DONE inline with the implementing file. What remains genuinely blocked is real hardware quote verification (TDX signature / RTMR / report_data validation, the dstack guest agent, RA-TLS KMS) — Phase B/C, BLOCKED on CPU TDX hardware. Confidential-GPU (H100) is out of scope (CPU TDX CVM only). The software items below do not make the system hardware-trusted; they verify a signed evidence document and fail closed when it is absent, simulated, replayed, or tampered.

• No real quote verification anywhere. dstack-tee-provider.ts fetches or reads a TeeEvidence JSON blob (ELIZA_TEE_EVIDENCE_JSON/_URL/_PATH, DSTACK_TAPPD_URL) and normalizes it. It never parses a TDX quote, never checks an Intel PCS/QvL signature, never validates RTMRs against report_data, never verifies the DICE/RA-TLS cert chain. evidence.quote is carried but never cryptographically verified. The policy verifier trusts whatever the provider hands it. This is the single biggest gap: today the system verifies a self-asserted JSON document, not a hardware attestation. This is acceptable for the macOS-feasible lane and unit tests, but it is not the security property the product claims, and the codebase does not currently hide that — it just hasn't built the verifier. (Honest gap, not slop.)
• DONE (A7) — nonce + report_data replay binding. tee-key-release.ts now generates a fresh ephemeral X25519 keypair and a fresh nonce per request and binds report_data = SHA256(nonce || epk_pub) (TeeReportDataChallenge, collectEvidenceWithReportData). The issued nonce is set as policy.expectedNonce so evaluateTeeEvidencePolicy rejects nonce-mismatch, closing the replay gap for a passive collector. (Originally: the client sent whatever nonce was already in the evidence — replayable.) The crypto binding is real; the quote that carries report_data is still not hardware-verified — Phase B2, BLOCKED.
• LocalTeeKeyReleaseClient is an HMAC KDF, not a KMS. It derives key material with HMAC-SHA256(masterSecret, keyId|context|agent|policy|device). This is a faithful model of "deterministic app-key bound to measurement" and it correctly varies output per agent/policy measurement (proven by test), but the masterSecret lives in agent memory. It is a local-dev stand-in for the dstack decentralized KMS, not the KMS.
• DONE (A4) — production boot-gate wiring. runtime/eliza.ts now runs runTeeBootGate at startup: it calls evaluateTeeBootGate (which resolves the runtime policy, merges the production profile, collects evidence, and evaluates trust ONCE), fails closed on any error, and publishes the decision via setTeeBootGateState. Secret-bearing paths consult teeBootGateBlocksSecrets() (tee-boot-gate-state.ts), and assertTeeBootGateAllowsSecrets throws fail-closed when secrets are disabled. ELIZA_TEE_REQUIRED=true with no trusted evidence ⇒ no model-key release, no signing, no remote-plugin sync; degraded boot allowed, silent secret release never. (Originally: tee-* was only export *-ed with no boot consumer.)
• DONE (A8) — confidential-inference unseal plumbing. tee-confidential-inference.ts releases the model-key (MODEL_KEY_ID) only after the key-release client's evidence satisfies the policy, then decrypts the at-rest weights blob in process memory and hands it to the local runtime. The test asserts the weights and key never touch disk, env, or the structured logger, and that tampered/absent evidence makes the key unavailable so unseal throws (negative path enforced by data unavailability). (Originally: no unseal path, model-key had no consumer.) This runs against the local HMAC KDF / mock KMS — the real RA-TLS KMS and real quote verification are Phase B, BLOCKED.
• DONE (A3/A6) — centralized production profile rejecting DevMode/simulated evidence. tee-production-profile.ts (mergeTeeProductionProfile) forces required, requiredClaims (debugDisabled/productionLifecycle), and rejectSimulatedEvidence on, so a caller cannot accept DevMode evidence by forgetting a claim. evaluateTeeEvidencePolicy rejects evidence that self-identifies as mock/simulated/debug/devmode (kind, hardwareVendor, provider, quote markers, verifier) — the tee-production-profile.test.ts matrix proves it. This is an agent-side compensating control against dstack #608 (DevMode allow-all); it does not replace real quote-signature verification — Phase B2, BLOCKED. KMS-identity pinning / RA-TLS cert verification config fields exist (A6) but the live RA-TLS handshake is Phase B.
• Two Tee* type homes. packages/core/src/types/tee.ts defines a legacy TeeAgent/RemoteAttestationQuote/TEEMode/TeeType set (old plugin-tee shape). The new canonical types live in packages/agent/src/services/tee-evidence.ts. These do not conflict (different concepts) but the naming overlap is a trap. Plan: leave core's legacy types alone unless a consumer needs them; treat tee-evidence.ts as the single source of truth for confidential-AI evidence and document that in core's file.

1.3 Contracts that already exist (and we must not redefine)

• The normalized TeeEvidence shape and evaluateTeeEvidencePolicy decision union are the cross-layer contract. The chip lane (06-os-on-tee-software.md) and OS lane (tee-measured-boot-contract.md) both explicitly anchor to them and promise not to fork them. Keep it that way.
• Measurement names: boot, os, agent, policy, device, container, compose, npuFirmware, gpuFirmware (+ open string). Claims: debugDisabled, productionLifecycle, secureBoot, memoryEncrypted, ioProtected, gpuProtected, npuProtected.

Verdict: the policy/evidence/revocation core is production-grade and the right design. The verifier of real quotes, the nonce/epk binding, the confidential-inference unseal path, the production hardening profile, and the boot wiring are the missing pieces. The work is integration + a real verifier, not a rebuild.

---

2. Confidential AI inference path (the headline)

2.1 Goal

Model weights are encrypted at rest on the device's storage. They are decrypted only inside the confidential domain, only after attestation-gated release of the model-key, and loaded directly into the in-domain local model runtime (eliza-1) and the NPU. Prompts, embeddings, KV-cache, and generated tokens live only in private (memory-encrypted) pages and never cross to a non-measured device in cleartext.

2.2 Weights-at-rest + unseal flow (local-in-TEE)

1. Boot the confidential domain (dstack CVM / CoVE TVM).
   OS/silicon lane produces the measured-launch quote.
2. In-domain attestation agent assembles TeeEvidence (kind, measurements
   incl. agent+policy+container+npuFirmware, claims, freshness).
3. Agent boot resolves the production TeeEvidencePolicy
   (resolveTeeRuntimePolicy + production profile, §4.2).
4. Agent requests model-key from KMS:
     - generate ephemeral X25519 keypair (epk) in-domain
     - obtain a fresh verifier nonce
     - bind reportData = SHA256(nonce || epk_pub) into the quote
     - send {keyId:"model-key", evidence, policy} over RA-TLS
5. KMS verifies the quote (RTMRs/measurements, signature, freshness, policy),
   derives the app-deterministic model-key, wraps it to epk, returns it.
6. Agent unwraps model-key in-domain, decrypts the weights blob
   (AES-256-GCM / XChaCha20-Poly1305) into private memory.
7. Weights stream into the local model runtime (eliza-1) and the NPU
   private queues. The model-key and cleartext weights never leave the domain.
8. Inference: prompts/embeddings/KV-cache stay in private pages. Output crosses
   to the UI only through the explicit shared-page copy path.

If step 5 fails (tampered agent/OS/policy → measurement-mismatch, stale quote, debug enabled, rolled-back version), the KMS withholds model-key, the weights stay ciphertext, and inference is impossible — the negative path is enforced by data unavailability, not by a software check that could be patched out. This is the property called out in chip §3.4 and it is the design we adopt.

2.3 KV-cache, prompts, user data confinement

• ELIZA_STATE_DIR (default ~/.local/state/eliza) maps to a private, sealed-key-encrypted volume that only mounts after attestation-gated key release. (dstack does this via LUKS2 — see the LUKS2 advisory in §5; we must bind the volume key to attestation, not to a host-readable key.)
• KV-cache and intermediate tensors live only in confidential (memory-encrypted) pages. There is no swap to a non-measured device; if swap is required it must be encrypted with an in-domain key.
• Cleartext crosses the boundary only through the shared-page virtio path and only for data the user marked exportable (a measured policy field). UI text, rendering, and notifications are explicitly allowed outside.

2.4 Maps to the NPU-as-confidential-I/O and eliza-1

• The chip lane's NPU private queues (lane 03, npuProtected claim, npuFirmware measurement) are the hardware mechanism that keeps weights and activations off shared buses during inference. The agent's contract with that layer is: do not release model-key and do not start private inference unless claims.npuProtected === true and measurements.npuFirmware matches the manifest. This is a policy assertion the agent already supports; the plan adds it to the production profile (§4.2).
• eliza-1 is the in-domain local model runtime. The plan's only requirement on it: it must accept weights from an in-memory decrypted buffer (no temp file on a non-measured FS) and must not log prompts/weights anywhere reachable by the host (§4.4).

2.5 Confidential inference is CPU-only (device CVM or cloud dStack CVM)

Confidential inference runs on-CPU inside a CVM — never on a confidential GPU. NVIDIA H100 / confidential-GPU is out of scope. Two confidential placements, both CPU TDX/TVM:

Aspect	Device-local CVM/TVM (default)	Cloud dStack CVM (opt-in)
Where weights decrypt	On-device CVM/TVM (on-CPU)	dStack CPU-based Intel TDX CVM (on-CPU)
Verifier/KMS	On-device verifier (eliza-local-verifier)	Cloud dStack KMS (added to allowedProviders)
What the agent sends	nothing leaves the device	nothing leaves the cloud CVM (inference is on-CPU in-domain)
Extra claim required	npuProtected + npuFirmware (on-device secure I/O)	none beyond the CPU TDX quote/measurement
Policy difference	required:true, local golden digests	adds the Cloud dStack KMS provider

The agent runs the same evaluateTeeEvidencePolicy for both; only the policy object differs (allowed providers / measurements). Inference sent to a non-attested external endpoint (a third-party model API) is not confidential — cleartext to that operator — and is the opt-in, non-confidential path for user-marked-exportable data only, not a confidential-GPU path.

---

3. End-to-end attestation + key release contract

3.1 The flow, by component

device evidence (OS/silicon)                      [OS + chip lanes]
  -> in-domain attestation agent emits TeeEvidence  [dstack-tee-provider / chip agent]
  -> normalizeTeeEvidence(...)                       [tee-evidence.ts]  STRICT
  -> evaluateTeeEvidencePolicy(evidence, policy)     [tee-policy.ts]    TRUST DECISION
       policy from resolveTeeRuntimePolicy(env)      [tee-runtime-config.ts]
       + mergeTeeRevocationsIntoPolicy(...)          [tee-revocation.ts]
       + production profile (§4.2)                   [NEW]
  -> trusted? release secret                         [tee-key-release.ts]
       model-key | agent-session | remote-signing
  -> unseal: decrypt weights / mount state / sign    [NEW consumers]

3.2 Freshness / nonce / report_data binding (must be added)

This is the contract the docs specify but the client does not yet implement:

1. The agent generates an ephemeral X25519 keypair epk per release request.
2. The agent obtains a fresh challenge nonce from the verifier/KMS (or, in local mode, from the local verifier).
3. The quote request sets report_data = SHA256(nonce || epk_pub) so the quote is bound to this live channel and is not replayable.
4. policy.expectedNonce is set to the issued nonce; policy.maxAgeMs bounds staleness; evaluateTeeEvidencePolicy rejects missing-nonce/nonce-mismatch/ timestamp-stale.
5. The KMS wraps the released key to epk_pub; the agent unwraps in-domain.

HttpTeeKeyReleaseClient must be extended (or a RaTlsTeeKeyReleaseClient added) to do steps 1–3 and to verify the returned key was wrapped to its epk. Never accept a key for a quote whose report_data the client did not bind to a nonce it generated.

3.3 Measurement matching set (the agent's required claims)

For a production local-in-TEE confidential-AI release the policy must require:

• requiredMeasurements: agent, policy, container/compose, os, boot, device, and npuFirmware (when local private inference is enabled), each matching the signed reproducible-build manifest's golden digest.
• requiredClaims: debugDisabled:true, secureBoot:true, memoryEncrypted:true, ioProtected:true, productionLifecycle:true, and npuProtected:true (local) or gpuProtected:true (cloud-routed).
• minSecurityVersion: the anti-rollback floor from the RoT counter.
• expectedNonce + maxAgeMs: per §3.2.
• revocations merged from the signed revocation manifest.

3.4 Rollback / revocation

• Rollback: minSecurityVersion + revokedSecurityVersions (both supported).
• Revocation: revokedMeasurements per name. The revocation manifest is signed by an authority (authority field) — the agent must verify that signature before merging (gap: mergeTeeRevocationsIntoPolicy trusts the manifest; add signature verification at the load boundary in tee-runtime-config.ts).

3.5 Map to dstack KMS deterministic app keys

dstack's KMS runs in its own TEE, verifies the TDX quote, and derives a deterministic per-app key bound to the measured app identity (compose digest + args + env) with authorization enforced by on-chain policy that operators cannot bypass. The agent's model-key/agent-session/remote-signing scopes map to dstack keyIds; the binding inputs (agent/policy/container measurements) in our deriveKeyMaterial model mirror dstack's app-identity binding. In production the LocalTeeKeyReleaseClient HMAC model is replaced by the real dstack guest-agent socket (/var/run/dstack.sock) → KMS path; our HttpTeeKeyReleaseClient becomes an RA-TLS client to that socket/endpoint.

---

4. Secret & capability gating

4.1 ELIZA_TEE_REQUIRED=true behavior (must be wired)

Today resolveTeeRuntimePolicy returns { required:true, ... } but no boot code consumes it. Plan: at agent boot, if ELIZA_TEE_REQUIRED==="true" (or a policy resolves with required:true), the agent must:

• collect evidence via the configured provider and evaluate it once at boot;
• if not trusted, refuse to release any high-value secret (model-key, signing key, remote-signing) and refuse to sync remote capability plugins — the agent may still boot in a degraded, secret-less mode but must surface the failed decision (structured logger, [TeeBootGate]), never silently continue with secrets.
• wrap the active SignerBackend in TeeSignerBackend so every sign re-checks.
• gate model-key release behind the same policy (so weights stay sealed).

4.2 A single production profile (new, prevents footguns)

Add a teeProductionProfile() helper that returns the non-negotiable claim/ freshness floor and is intersected with the resolved policy, so a caller cannot forget debugDisabled/memoryEncrypted/freshness in production:

// strongly typed, no fallbacks; rejects dev/debug evidence by construction
export function teeProductionProfile(): Required<Pick<TeeEvidencePolicy,
  "required" | "requiredClaims">> & Pick<TeeEvidencePolicy, "maxAgeMs"> {
  return {
    required: true,
    requiredClaims: {
      debugDisabled: true,
      secureBoot: true,
      memoryEncrypted: true,
      ioProtected: true,
      productionLifecycle: true,
    },
    maxAgeMs: 300_000,
  };
}

The boot path must merge this into the resolved policy whenever the build is a production/stable channel, never accepting DevMode/debug evidence under it.

4.3 Host↔guest capability bridge + RemoteSigningService

Per tee-protected-agent-vm.md: the host owns UI/network/storage-brokering; the guest owns secrets, signing keys, decrypted model keys, private tool output. Allowed host→guest calls: plugin.modules.list, approved remote plugin actions, workspace-scoped file IO, terminal exec only when policy allows the endpoint, and signing through RemoteSigningService. Denied by default: host FS escape, raw device access, unmeasured plugin loading, unsigned policy mutation, and secret export to host logs/env dumps/crash reports/analytics. RemoteSigningService must use TeeSignerBackend so the host can request a signature but the key never leaves the domain and every sign re-attests.

4.4 Deny secret export to host surfaces (new gate)

• No secret/weight/prompt value may be written to a logger that ships off-domain, to process.env dumps, to crash/telemetry payloads, or to a non-measured FS.
• Add a redaction assertion at the structured-logger boundary and a CI gate that greps the crash/telemetry serializers for secret-scope keys. (Logger-only per commandment 9; never console.)

4.5 Fail-closed on missing/stale/debug/mismatched evidence

The decision union already encodes every failure cause. The plan is to ensure every high-value path routes through evaluateTeeEvidencePolicy and throws on !trusted: plugin sync (done — remote-capability-endpoint-provider), signing (done — TeeSignerBackend), model-key release (to wire), agent-session secret release (to wire), and remote capability calls (done). No path may have a fallback that proceeds without a trusted:true decision.

---

5. dstack provider hardening (defenses against the known issues)

The brief and dstack's own advisories establish the threat classes. Concrete agent-side defenses:

1. KMS attestation bypass — never trust a key the agent did not bind to its own fresh nonce + epk (§3.2). The agent independently runs evaluateTeeEvidencePolicy on the evidence before using any returned key; it does not delegate the trust decision to the KMS response alone. Verify the returned key is wrapped to the agent's epk.
2. Permissive DevMode auth / fake-quote pathways — the production profile (§4.2) requires debugDisabled:true and productionLifecycle:true; DevMode or simulated quotes (e.g. quote:"simulated-cove-quote", hardwareVendor:"mock-*") must be rejected. Add an explicit allowlist of accepted verifier/hardwareVendor values in production, and refuse kind values that indicate mock providers. The real quote signature must be verified (BLOCKED on hardware; see §7) — until then production must not claim hardware trust.
3. Disabled-TLS-verification gateway — the KMS client must use RA-TLS with full certificate-chain verification pinned to the expected KMS identity; refuse plain HTTP and refuse NODE_TLS_REJECT_UNAUTHORIZED=0. Add a guard that throws if the KMS URL is not https:/RA-TLS in production (normalizeBaseUrl already enforces http(s); tighten to https-only + identity pin).
4. KMS identity pinning — pin the KMS's measured identity (its own quote / on-chain policy identity) so a rogue or downgraded KMS cannot answer. Add expectedKmsMeasurement / expectedKmsPublicKey to the release client config and verify it on the RA-TLS handshake.
5. World-readable key material / decrypted env vars — never place secrets or the decrypted weights/model-key in env vars or world-readable files. Keep them in-process memory; the sealed state volume key must be attestation-bound, not a static host-readable key (the LUKS2 advisory GHSA-jxq2-hpw3-m5wf is exactly this risk). Zeroize key buffers after use.
6. Decompression bomb / malformed evidence — normalizeTeeEvidence already rejects malformed shapes; add a max-size cap on the evidence/quote payload in dstack-tee-provider.ts HTTP/file reads and a JSON-parse size guard before parsing.
7. Cert / constant-time issues — use constant-time comparison for nonce and wrapped-key checks; rely on a vetted RA-TLS library for cert verification rather than hand-rolled parsing.

These are agent-side compensating controls; they do not fix dstack itself but ensure the agent never extends trust to a quote/KMS it cannot independently verify and pin.

---

6. The agent↔OS↔silicon contract

6.1 Fields the agent consumes (provider-neutral)

The agent consumes only the normalized TeeEvidence from tee-evidence.ts, regardless of provider (dstack/tdx/cove/eliza-vault). Required from the layer below:

• kind, provider, securityVersion, freshness{nonce,timestamp,verifier}, quote, certificatePem, reportData.
• measurements: boot, os, agent, policy, device, container/compose (containerized), npuFirmware (local private inference), gpuFirmware (cloud confidential GPU).
• claims: debugDisabled, secureBoot, memoryEncrypted, ioProtected, productionLifecycle, npuProtected (local), gpuProtected (cloud).

6.2 Is the existing requiredClaims set the right contract?

Yes. debugDisabled, secureBoot, memoryEncrypted, ioProtected are the correct core set, and the type already carries productionLifecycle, npuProtected, gpuProtected. For confidential AI the only additions needed are usage of the already-present fields:

• Use npuProtected + measurements.npuFirmware as a hard gate for local private inference (present in types and fixtures; not yet required by any production profile).
• gpuProtected + measurements.gpuFirmware exist in the type for completeness but are out of scope / no consumer — confidential-GPU (H100) is not pursued; confidential inference runs on-CPU inside the CVM.
• Consider a monitor measurement name (TSM/security-manager digest) for the CoVE path — chip §2.1/§3.1 emits monitor; TeeMeasurementName is an open string so it already type-checks, but add "monitor" to the named union for discoverability.
• Optionally add a modelWeights measurement name so the released-against weights digest can be matched (defense in depth: bind model-key release to the expected weights digest). Open-string already allows it; naming it makes it a first-class contract field.

No breaking changes to the type are required — the contract is right; the work is enforcing the optional fields in the production profile.

---

7. Sequenced Plan

Effort in person-weeks (PW). Every blocked item names its dependency and stays fail-closed.

Phase A — buildable now (no hardware), software-only

All Phase A items are DONE (software-only, no hardware). They verify a signed evidence document and fail closed; none of them claims hardware-verified trust — that stays Phase B/C, BLOCKED.

ID	Status	Work item	Gate
A1	DONE	Extend tee-full-stack-local.ts with real policy vectors: per-topology policies (local-only, desktop, cloud-routed) + golden/tampered fixtures for every decision reason (kind/provider/measurement/version/nonce/timestamp/claim/revoked).	tee-full-stack-local
A2	DONE	Negative-test matrix asserting each reason in the decision union for crafted evidence. Pure data, no any.	tee-evidence-policy.matrix.test.ts
A3	DONE	teeProductionProfile() + profile-merge helper (§4.2); rejects DevMode/debug evidence.	tee-production-profile.ts / .test.ts
A4	DONE	Boot wiring (§4.1): runTeeBootGate in runtime/eliza.ts, fail-closed [TeeBootGate], gate model-key + agent-session release; cross-module state via tee-boot-gate-state.ts.	tee-boot-gate*.ts / .test.ts
A5	DONE	Revocation-manifest Ed25519 signature verification at load (§3.4); deny unsigned/invalid manifests.	tee-revocation.ts / tee-revocation-signature.test.ts
A6	DONE	dstack provider hardening (no hardware): payload size cap, https-only + KMS-identity-pin config fields, constant-time nonce/key compare, reject mock verifier/hardwareVendor/simulated quotes under production profile.	unit
A7	DONE	Nonce + epk binding in the key-release client (§3.2): generate epk, issue/echo nonce, set report_data, verify key wrapped to epk. (Crypto only; no real quote yet.)	tee-key-release.ts / .test.ts
A8	DONE	Confidential-inference unseal plumbing (§2.2 steps 4–7) against the mock KMS: encrypt weights at rest, release model-key, decrypt in-memory, hand to the local runtime; assert no temp-file/plaintext on disk and no secret in logs (§4.4).	tee-confidential-inference.ts / .test.ts
A9	DONE	CI gate (§4.4): grep crash/telemetry serializers + env-dump paths for secret-scope keys; fail on leak. In-lane via tee-secret-hygiene.test.ts; repo-wide CLI gate packages/scripts/audit-tee-secret-leak.mjs (--self-test).	lint gate

Critical path for Phase A: A3 → A4 → A8 (the headline unseal plumbing depends on the production profile and boot wiring). A1/A2/A5/A6/A7/A9 parallelized.

Phase B — cloud-TDX-gated (real dstack KMS on CPU-based Intel TDX)

The agent runs inside a CPU-based Intel TDX CVM (Phala dStack). The whole agent — runtime, DB, vault/secrets, and any on-CPU inference — is the confidential workload. Confidential-GPU (NVIDIA H100) is out of scope (was B4); the trust boundary is the CPU CVM, not a GPU.

ID	Work item	Effort	Gate
B1	Real dstack guest-agent integration: read evidence from /var/run/dstack.sock / DSTACK_TAPPD_URL, request real TDX quote, populate TeeEvidence.	3	dstack CVM on CPU TDX
B2	Real TDX quote verification (Intel PCS/QvL): verify quote signature, RTMRs, and report_data == H(nonce||epk). The current provider does none of this.	4	CPU TDX hardware
B3	Real RA-TLS KMS client with KMS-identity pinning; deterministic app-key release for model-key/agent-session/remote-signing.	3	dstack KMS

Confidential inference policy (no H100): inference that must stay confidential runs on-CPU inside the CVM (cleartext weights/prompts/KV-cache never leave the CPU TDX domain). Cloud-routed inference to an external endpoint is outside the confidential boundary by definition — a documented limitation, not an H100/gpuProtected work item.

Phase B is BLOCKED on CPU TDX hardware availability. Until B2 lands, the system must not claim hardware-verified trust; it verifies a signed evidence document only. State this in any release notes.

Phase C — chip-silicon-gated (real CoVE quote on E1)

ID	Work item	Effort	Gate
C1	Consume real CoVE quote from the E1 in-domain attestation agent (chip §3.1); verify DICE/RoT cert chain + RTMR/report_data binding.	4	E1 silicon / CoVE QEMU+Salus
C2	NPU private-queue gate: enforce npuProtected + npuFirmware before private inference (binds chip lane 03).	2	E1 secure I/O
C3	Attestation-bound sealed state volume (replace host-readable LUKS2 key with attestation-released key).	2	E1 + KMS

Phase C is BLOCKED on E1 silicon / a riscv64 CoVE QEMU+Salus target (chip lane WI-6/WI-7/WI-9). It stays fail-closed with the named dependency.

Fail-closed gate summary

• Phase A gates close immediately (software, mock KMS, real crypto).
• Phase B gates stay BLOCKED on CPU TDX hardware; the agent must refuse to assert hardware trust until B2 verifies real quotes. (Confidential-GPU / H100 is out of scope — CPU TDX CVM only.)
• Phase C gates stay BLOCKED on E1 silicon; same rule.
• At every phase, ELIZA_TEE_REQUIRED=true + production profile means: no trusted evidence → no model-key, no signing, no remote-plugin sync, no private inference. Degraded boot is allowed; silent secret release is never allowed.

---

8. Open decisions for a human

• Weights encryption envelope — AES-256-GCM vs XChaCha20-Poly1305, and whether weights are a single blob or per-shard (per-shard lets large models stream-decrypt without a full plaintext copy in memory). Recommend per-shard.
• modelWeights measurement — bind model-key release to the expected weights digest as defense in depth? Recommend yes (defense in depth, cheap).
• Local verifier trust root — for local-only mode the on-device verifier is rooted in the RoT-derived key; confirm the local verifier's measured identity is itself in measurements.policy/device so it can't be swapped.
• Cloud KMS as escrow — whether cross-device key escrow via Eliza Cloud is in scope for v1 (the chip doc lists it as optional). Out of scope unless requested.