Command A+ on a verified confidential cluster
This is a private inference deployment of Cohere's Command A+ (CohereLabs/command-a-plus-05-2026-fp8) served by vLLM v0.28.0. The topology is DP2 x TP2 across 4 NVIDIA B300 GPUs with Intel TDX.
The deployment runs on Kubernetes, with c8s (Confidential Kubernetes) installed to provide confidentiality guarantees. Confidential Kubernetes lets you draw a trust boundary around the whole cluster. Pod admission is fail-closed: only measured and allowlisted images may launch. The admission policy does not rely on the control plane, which stays outside the trust boundary. The full mechanics are in the c8s paper. The cluster's service mesh also uses RA-TLS to bind all mTLS networking to attestation. As a result, the ingress router and the two vLLM replicas sit under one trust boundary, and their networking is secured by RA-TLS. With this setup, attestation claims can be made about the security posture of the cluster as a whole. A verifier can verify the whole cluster behind an endpoint, and that also covers scaling events.
This website showcases an attested chat with the cluster along with a sample trust page for cluster-based attestation. The verification runs fully on the browser side, using the open-source c8s-verify-js library.
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.
Where the measurements come from
The pinned MRTD, RTMR[1] and RTMR[2] come from the build manifest of the node image. This page serves that manifest and your browser hashes it, right now, against the pinned digest.
Hashing ./manifest.json with SubtleCrypto…
Re-derive it yourself:
oras pull ghcr.io/confidential-dot-ai/c8s-base:rke2-cdi-3a2517b
shasum -a 256 manifest.json # expect 9051a5d3b04c123f…Image: ghcr.io/confidential-dot-ai/c8s-base@sha256:2192a638405053d7f4afdbeb1c1f5ef39ce0545e1a987fc5521d12598881db10. Built from Confidential OS rev 92a07633e94506ec0a85dfdae0d01e643c051253. And reproducible: anyone can rebuild and arrive at the same MRTD.
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.
Hit the endpoint from a terminal
A request
curl https://confidential-command-a-plus-demo.confidential.ai/v1/chat/completions -H 'content-type: application/json' -d '{"model":"CohereLabs/command-a-plus-05-2026-fp8","messages":[{"role":"user","content":"Say hello."}],"max_tokens":32}'Fresh attestation evidence
NONCE=$(head -c32 /dev/urandom | base64 | tr '+/' '-_' | tr -d '=') curl -s "https://confidential-command-a-plus-demo.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.