A Confidential Inference Cluster Demo
This is Confidential AI's production inference deployment. It serves deepseek-ai/DeepSeek-V4-Flash-0731 behind https://api.confidential.ai. The serving cluster runs c8s (Confidential Kubernetes) on Intel TDX hardware, with NVIDIA GPUs in confidential-compute mode.
The cluster publishes live attestation for every workload it runs: the gateway, the router, the inference workers, and the supporting services, plus NVIDIA GPU evidence relayed from the workers. This page fetches a fresh attestation bundle and verifies the whole cluster in your browser: the Intel TDX quotes, the pinned image measurements, the operator key, the mesh identity, and the admission allowlist. No server of ours takes part in the check.
Attested chat
The attested chat opens here once you verify the cluster.
Verify the cluster first. The composer unlocks on a green verdict.
What gets checked
Fresh, genuine hardware evidence
- Fresh evidence, made for this session
The attestation was produced just now, for your browser. It is not replayed from an earlier session or another machine.
A 32-byte nonce is generated in this tab and echoed by the enclave. The TD quote's report_data must bind it, via a SHA-384 transcript over the session keys, nonce, mesh leaf and issuing CA. Stale or replayed evidence fails closed.
- Real Intel TDX silicon
The hardware quote is genuine. Its signature chains to Intel's root of trust. A simulator, or a different kind of TEE, cannot pass.
The TDX quote's PCK certificate chain verifies to the pinned Intel SGX Root CA inside the attestation-rs WASM verifier. The QE report binding is checked and debug-enabled TDs are rejected. The CCEL event log is replayed against RTMR[0] to RTMR[3]. Revocation collateral is not checked in the browser. See the limits section.
The exact published image
- The pinned firmware
The enclave booted exactly the audited firmware, not a modified lookalike.
MRTD is the SHA-384 launch measurement of the TDVF firmware regions. It must equal the reference from the c8s-base image manifest. MRTD alone does not identify the guest OS. The next registers cover that.
- The pinned guest kernel
The Linux kernel inside the enclave is exactly the one from the published image.
RTMR stands for run-time measurement register. RTMR[1] covers the guest kernel: the UKI PE image, the GPT layout and the boot path. It is compared exactly against the image manifest.
- The pinned guest rootfs
The whole guest filesystem matches the audited image. Every system binary and config file.
RTMR[2] covers the guest rootfs, via the UKI section measurement chain. It is compared exactly against the image manifest.
This deployment, this cluster
- This operator's own deployment
This is the deployment whose operator key was bound at launch. Not just anyone's genuine copy of the open-source image.
RTMR[3] equals SHA-384 of 48 zero bytes followed by SHA-384 of the operator public key. The images are reproducible, so a matching MRTD alone would only prove a genuine instance of the audited build. RTMR[3] pins this deployment. It survives reinstalls and can be published in advance.
- This cluster's identity
The load balancer belongs to this cluster. Its mesh certificate chains to the cluster CA pinned out of band. The verdict is specific-cluster, not some genuine cluster.
The mesh leaf proves possession of its private key with an ECDSA P-384 signature over the identity transcript. It must chain to the pinned c8s Mesh CA. The transcript commits to the issuing CA, so a substituted chain fails closed.
The sealed channel
- A sealed, post-quantum channel
Your traffic now travels inside encryption that only the verified enclave can open. The TLS terminator and every middlebox see only ciphertext.
ML-KEM-768 plus X25519 hybrid key agreement, then HKDF-SHA-256 to an AES-256-GCM key. Chat rides POST /.well-known/c8s/tunnel. Traffic remains confidential as long as ML-KEM-768 holds.
What this cluster is allowed to run
The admission allowlist the cluster enforces. Only these exact image digests can run in the cluster. Everything else is rejected at admission, fail closed.
Loading the served allowlist…
The allowlist is advertised by the CDS, the cluster identity service that runs inside the enclave. The same service enforces admission. Changes are operator-key-signed writes, bound to the operator key pinned in RTMR[3]. Fail-closed admission was proven twice on this cluster: both candidate inference images were rejected (“image not in allowlist”) before the serving engine was admitted.
Try it yourself
A request
The /v1 endpoints need an API key. Get one from Confidential AI (hello@confidential.ai), then:
export CONFIDENTIAL_API_KEY='<API_KEY>'
curl https://api.confidential.ai/v1/chat/completions -H "Authorization: Bearer $CONFIDENTIAL_API_KEY" -H 'content-type: application/json' -d '{
"model": "deepseek-ai/DeepSeek-V4-Flash-0731",
"messages": [{"role": "user", "content": "Say hello."}],
"max_tokens": 32
}'Fresh attestation evidence
NONCE=$(head -c32 /dev/urandom | base64 | tr '+/' '-_' | tr -d '=') curl -s "https://api.confidential.ai/.well-known/c8s/attest-pq?nonce=$NONCE" | jq .
The response is a c8s-verify/v1 bundle: the signed Intel TDX report bound to your nonce, the CDS certificate chain, the hybrid session keys, and the mesh identity proof.
Built on open, inspectable pieces
Every link in the chain is public. The platform source, the image the measurements came from, the serving engine, the model, and the very verifier running on this page.