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.
CONFIDENTIAL INFERENCEINTEL TDX TEE + NVIDIA H200 / B300
A direct path from your device to attested compute
Privacy you can
verify yourself.
CyberGLM 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
01Your browser
or official SDKVerifies before it sends
or official SDKVerifies before it sends
02Signed policy
& fresh evidenceVerified locally
& fresh evidenceVerified locally
03Attested confidential
runtimeDecrypts and runs inference
runtimeDecrypts and runs inference
TLS + HPKE KEY
BOUND TO QUOTE
BOUND TO QUOTE
04BillingSigned count-only event
SIGNED RECEIPT → YOUR DEVICE
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.
NVIDIA H200 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.
PLATFORMCONFIDENTIAL-COMPUTING ROLEWHAT THE CLIENT MUST VERIFY
NVIDIA H200
Hopper · 141 GB per GPU
Hopper · 141 GB per GPU
Supports NVIDIA Confidential Computing. For a multi-GPU H200 TDX VM, NVIDIA requires Protected PCIe (ppcie) mode. GPU-to-GPU traffic over NVLink is not encrypted in this mode, so the exclusive NVSwitch fabric remains within the trusted boundary.
Intel TDX quote, NVIDIA device evidence and RIM status, the attested proxy key, and the exact policy for the H200 endpoint.
NVIDIA B300
Blackwell · 288 GB per GPU
Blackwell · 288 GB per GPU
Supports multi-GPU confidential computing on validated HGX B300 platforms. Blackwell uses NVLink encryption: traffic is protected in transit between GPUs, placing NVSwitches outside the trusted computing base. The regular CC on mode is used instead of Hopper ppcie.
Intel TDX quote, NVIDIA device evidence and RIM status, the attested proxy key, and the exact policy for the B300 endpoint.
GPU-TO-GPU BOUNDARY / NVLINK
B300 encrypts NVLink. Hopper H200 does not.
That is the material confidentiality difference for a multi-GPU model server. H200 still offers a TDX-backed confidential VM and protected CPU-to-GPU handling, but its Hopper Protected PCIe mode trusts the isolated NVLink/NVSwitch fabric. B300’s Blackwell TEE-I/O encrypts the NVLink path, so a physical observer of that interconnect cannot read the GPU-to-GPU traffic. The endpoint policy identifies which platform and mode a client is accepting.
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.
Does this apply to the existing API automatically?
No. The legacy API remains available for compatibility. Confidential guarantees apply only when a supported client verifies the published policy and fresh evidence, encrypts to the attested key, and receives a valid runtime receipt.
What should I look for before sending sensitive content?
Check the policy’s model and endpoint identity, the evidence freshness and verification result, the TLS/HPKE key binding, and the receipt signer. A verification failure should stop the client before it transmits the prompt.
CONFIDENTIAL INFERENCE / AVAILABLE THROUGH VERIFIED CLIENTS