TEE.

CPU confidential VM — establishes the trust boundary
  Intel TDX      /dev/tdx-guest, Intel PCS verification
  AMD SEV-SNP    /dev/sev-guest, AMD KDS VCEK chain
  AWS Nitro      /dev/nsm, NSM CBOR + COSE_Sign1 ES384
  Intel Tiber    Tiber Trust Authority hosted EAT

Applied on top of one of the above — never on its own
  NVIDIA GPU CC  NVML evidence + NRAS/RIM appraisal, JWT + SPDM

NVIDIA GPU CC is not a standalone vendor. It extends a CPU TEE rather than replacing one: the trust boundary is the confidential VM created by SEV-SNP or TDX, and the GPU is admitted into it over an SPDM-authenticated PCIe link with its VRAM protected. A GPU report attests the device, not the environment the workload runs in.

detect_tee therefore requires a CPU anchor and returns the composite NvidiaGpuProvider::with_cpu_anchor(cpu), or nothing. A host with no CPU TEE cannot offer confidential computing however capable its GPU is.

A TPM and UEFI Secure Boot are real and worth enabling, but they are platform integrity rather than confidential computing:

Measured boot proves what was loaded. A TEE proves what is running, and protects it while it runs.

A TPM-only host reports tee_available: false and cannot serve the tee role. It can still carry a hardware-rooted machine identity and attest its boot chain. The node models this as AttestationClass::MeasuredBoot, which does not satisfy a confidential-compute requirement.

This is why a DGX Spark (GB10) cannot be a TEE provider — a Blackwell GPU paired with an Arm CPU that has no SEV-SNP, no TDX and no confirmed Arm CCA leaves no boundary to anchor to.

AES-256-GCM via the shared enclave_crypto.rs module. Keys derived with HKDF-SHA256 and a per-vendor domain tag. Wire format: nonce(12) || ciphertext || tag(16).

Enclaves can prove a STARK and sign the commitment with a PQ-hybrid composite key (Ed25519/Secp256k1 + ML-DSA-65). Both legs must validate.

tenzro tee detect
tenzro tee attest --vendor intel-tdx