CONFIDENTIAL INFERENCEINTEL TDX TEE + NVIDIA H200 / B300
A direct path from your device to attested compute
Privacy you can
verify yourself.
CyberGLM/CyberKimi confidential inference runs in a hardware TEE: an Intel TDX confidential VM with NVIDIA H200 or B300 GPUs. Your browser or SDK verifies the TEE evidence and endpoint-bound key before it sends a prompt.
TRUST BOUNDARY / CONFIDENTIAL ROUTE
01 · VERIFY POLICY + QUOTE
02 · BIND ATTESTED KEY
03 · HPKE / EHBP PROMPT
04 · SIGNED COUNTS
SIGNED RECEIPT
or official SDKVerifies before it sends
& fresh evidenceVerified locally
runtimeDecrypts and runs inference
TLS + HPKE KEY
BOUND TO QUOTE
BOUND TO QUOTE
INTEL TDX TEE · NVIDIA H200 / B300VERIFY THE QUOTE · VERIFY THE GPU · VERIFY EACH RECEIPT
01 / THE VERIFICATION LOOPBEFORE A PROMPT LEAVES YOUR DEVICE
Verify first.
Then encrypt.
The confidential route is intentionally separate from the legacy API. A capable client refuses the route when it cannot validate current evidence against the published policy.
- 01
Load a signed policy
Your client obtains the public endpoint policy, release metadata, verifier configuration, and pinned public keys from verify.adverserial.ai.
- 02
Validate fresh hardware evidence
The browser or official SDK verifies the Intel TDX quote, NVIDIA GPU attestation evidence, the measured runtime identity, and the hardware-bound public key.
- 03
Bind the endpoint key
The client checks that the TLS and encryption key it will use are bound to the attested runtime. A key substituted outside the measured environment fails that check.
- 04
Encrypt directly to the runtime
The client encrypts the prompt to the attested key using HPKE/EHBP. The private decryption key remains inside the confidential runtime.
- 05
Verify the signed receipt
The runtime returns an inference receipt. The Verification Center and SDK can show the policy, evidence, key binding, and metering identity associated with that request.
02 / ARCHITECTURETHE CONFIDENTIAL REQUEST PATH
The prompt does not
take the long way around.
Hosting, DNS, identity, billing, and the model server have deliberately different jobs. The content path is direct; the account path carries only what it needs.
PUBLIC EVIDENCEverify.adverserial.aiPolicy · manifests · receipt keys
CLIENT DEVICEBrowser verifier
Official SDKLocal trust decision
Official SDKLocal trust decision
INTEL TDX CONFIDENTIAL VM / TEE
Attest proxyAttested TLS + HPKE
Entitlement validation
Signed receipt
Entitlement validation
Signed receipt
Inference serverLoopback only
Model execution
Model execution
Durable meter outboxSigned counts only
Retry-safe delivery
Retry-safe delivery
BILLINGbilling.adverserial.aiEntitlements · ledger settlement
POLICY + QUOTE
HPKE / EHBP ENCRYPTED PROMPT
LOOPBACK
MTLS · SIGNED TOKEN COUNTS ONLY
SIGNED RECEIPT
CONTENT PATH: CLIENT → ATTESTED PROXY → LOCAL INFERENCE. ACCOUNT PATH: ENTITLEMENT + COUNT-ONLY SETTLEMENT.
03 / THE TEE AND GPU STACKINTEL TDX · NVIDIA H200 / B300 · ATTESTED PROXY
The hardware is part
of the proof.
The confidential endpoint is designed around a measured execution environment rather than a private-network claim. Each layer contributes evidence that the client checks.
Intel TDX confidential VM
Intel Trust Domain Extensions isolate the confidential VM from the host environment. The VM produces a signed quote that identifies the measured TEE environment a verifier is willing to trust.
H200/B300 confidential computing
The H200 inference GPUs contribute device evidence to the verification flow. The client checks that the GPU evidence matches the policy accepted for the confidential model endpoint.
Attest proxy + local inference
The proxy holds the quote-bound TLS and HPKE keys inside the TEE, decrypts only there, and connects to SGLang over local loopback. The model server is never a public internet endpoint.
Independent browser or SDK check
The trust decision remains on the user’s device. It validates Intel TDX, NVIDIA, policy, release, and key-binding evidence before encrypting a prompt to the runtime.
TEE EVIDENCE IS EVALUATED AGAINST THE PUBLISHED ENDPOINT POLICY. A FAILED OR STALE CHECK STOPS THE CONFIDENTIAL CLIENT BEFORE CONTENT IS SENT.
| Platform | Confidential-computing boundary | Evidence a client verifies |
|---|---|---|
| NVIDIA H200Hopper · 141 GB per GPU | ppcie is required for multi-GPU Hopper. CPU↔GPU is protected, while NVLink traffic remains plaintext inside an exclusively assigned, trusted NVSwitch fabric. |
Intel TDX quote, NVIDIA device evidence and RIM status, the attested proxy key, and the endpoint policy for H200. |
| NVIDIA B300Blackwell · 288 GB per GPU | Validated multi-GPU Blackwell uses standard CC on with NVLink encryption, protecting GPU↔GPU traffic and placing NVSwitches outside the trusted computing base. |
Intel TDX quote, NVIDIA device evidence and RIM status, the attested proxy key, and the endpoint policy for B300. |
04 / WHAT EACH COMPONENT CAN SEESEPARATION OF DATA AND ACCOUNTING
Privacy is a system
property, not a promise.
Each component is constrained to the smallest role it needs. The evidence tells you whether the endpoint is actually running the published version of that system.
Prompt, completion, receipt
Your browser or SDK performs policy and evidence verification, encrypts the request, and verifies the signed receipt.
Encrypted content, in memory
The confidential proxy decrypts requests only inside the attested environment and sends inference to the local model server over loopback.
Entitlements and token counts
Billing issues a short-lived signed entitlement and settles signed count-only meter records. It does not need the prompt or completion to do this.
Policies and release evidence
The registry publishes verification material: policy documents, release metadata, public keys, and the source needed to reproduce checks.
THE COMMITMENT
No content logging. No training on customer content.
On the verified confidential route, prompts and completions are not forwarded to billing, the website host, DNS, or the meter. Content logging is disabled in the published runtime policy. Customer prompts and completions are not used to train Adverserial models. Verify the current policy and a fresh receipt before relying on this route.
05 / PUBLIC PROOFEVIDENCE, NOT A STATUS BADGE
What you can
independently check.
Verification is useful only when the client can make its own decision. The published evidence is designed for that decision, not for a marketing claim.
Runtime identity
Validate the Intel TDX quote, NVIDIA H200 or B300 GPU evidence, and the measurement of the confidential runtime.
Inspect the verifierPolicy binding
Confirm the model ID, permitted endpoint, image and release digests, and attested TLS/HPKE key all match the signed policy.
Inspect policiesSource and release
Compare public source, build and release manifests, SBOMs, and provenance records with the policy the client accepted.
Open source repositoriesPer-request receipt
Verify that the receipt was signed by the attested runtime and is associated with the evidence and policy your client accepted.
Use the confidential client06 / QUESTIONSREAD THE BOUNDARY PRECISELY
What the evidence
does — and does not — say.
The confidential route makes specific, testable claims. It does not ask you to extend those claims to endpoints or software versions that have not passed verification.
Where does TLS terminate on the confidential route?
For a verified confidential endpoint, TLS terminates at the attested proxy inside the Intel TDX TEE. The frontend host, DNS provider, and billing service are outside the prompt content path.
How is billing possible without reading my prompt?
Billing signs short-lived entitlements before a request. The confidential runtime validates them locally, then sends a signed, idempotent record containing token counts and settlement identifiers only. It does not need prompt or completion bytes.
How does the confidential client protect me automatically?
The official client SDK performs the policy, evidence freshness, attestation, TLS/HPKE key-binding, and receipt-signer checks before it transmits a prompt. The same verification flow is available through supported harness integrations. If a required check fails, the client stops before content is sent.
How do I know you are not logging my prompts?
On the verified confidential route, your prompt is encrypted to a TLS/HPKE key held inside the attested runtime. The signed policy binds that key to a measured release with content logging disabled; the frontend host, DNS provider, and billing service cannot decrypt the prompt. Billing receives signed token counts only. Your client can independently verify the current measurement, policy, key binding, and signed receipt, which proves it used that published confidential release. The guarantee applies to this verified route and its supported clients.
CONFIDENTIAL INFERENCE / AVAILABLE THROUGH VERIFIED CLIENTS