Attestation

Attestation lets you verify which software can receive your prompt.

Threat model

Do not trust the physical host, Kubernetes control plane, or cloud operator. Trust the verified TDX hardware, measured ConfOS image, c8s policy enforcement, and software that you reviewed.

Attestation does not prove that software has no bugs. It proves that approved software controls the protected request path.

Inspect the evidence

Request /attestation with a new random 32-byte nonce. The response includes:

• The nonce, which prevents reuse of old evidence.
• Intel TDX evidence, which identifies the confidential VM.
• MRTD, RTMR1, and RTMR2 measurements for the firmware, kernel, boot configuration, and root filesystem.
• The TLS certificate binding for the public connection.
• The c8s mesh CA, which connects workload identities to the cluster.
• The static allowlist and its digest. The allowlist defines every image, command, and workload that may enter the protected path.
• Workload receipts, which show the images and commands that c8s admitted.
• The public release identifier and OCI image digests.
• NVIDIA evidence. The response currently labels this as raw evidence. Do not treat it as verified GPU proof until a compatible verifier checks it.

Review the software

Review the Confidential Inference source. Rebuild its images and compare their digests with the response. Review the allowlist. Its digest covers the full policy, not one image.

Protect inference

Configure TEErminator with the reviewed allowlist, full TDX image measurements, TLS name, and expected front-door workload.

Your application sends a normal OpenAI request to TEErminator. Before it forwards prompt data, TEErminator verifies the exact upstream TLS connection. It confirms the measurements, sealed allowlist, certificate name, and workload.

If any value differs, TEErminator fails closed and does not forward the prompt. It repeats verification after every new upstream TLS connection. After an upgrade, review the new release and attest again.