Confidential AI ･ Overview

How confidential inference, attestation, and signed receipts work in the Inference API.

The Inference API processes a request through three parts:

Client → public gateway → attested inference worker

The client uses HTTPS to reach the public gateway. The gateway validates the client API key and sends the inference request to the worker through a verified TLS channel. The worker runs in a confidential virtual machine. Intel TDX encrypts its memory from the host and lets it produce hardware-signed evidence about its booted software.

The gateway also runs in a confidential virtual machine. Before it forwards a request, it verifies fresh worker evidence that binds the worker's live TLS identity to the expected worker policy. A client can verify fresh gateway and worker evidence before it sends a prompt.

This does not prove that a model response is correct or useful. It does not prevent denial of service. It does not prove who owns an API key. It proves specific hardware-backed claims about the gateway and worker software, their TLS identities, and a fresh client nonce when the client verifies the evidence against its expected policies.

Operational flow

Use this sequence when you need an attested completion. The API reference gives the exact curl calls and response shapes.

1. Request attestation before you use an API key

Generate a new random 32-byte nonce and call the public canonical attestation endpoint. Do not include an API key or prompt in this request.

The response contains linked evidence from the gateway and the inference worker. It also contains the public Ed25519 key that verifies completion receipts. Verify this response before you send sensitive input:

The native Intel TDX gateway quote is signed by the hardware trust chain. It binds the supplied nonce, the live gateway TLS identity, and the receipt-signing public key to the gateway's report data. Verify the quote, the expected gateway measurement, and its TCB policy.
The c8s Intel TDX worker evidence is fresh evidence obtained by the gateway from the inference worker. It binds the same client nonce to the worker's live TLS public key. Verify the worker quote, the expected worker measurement and TCB policy, and the TLS-key binding.

An HTTP 200 alone is not proof. The response does not contain an API key, prompt, completion, or a claim that the model output is correct.

2. Obtain an API key

An administrator provisions a named API key for an application in the admin dashboard. Treat the plaintext key as a secret. Store it only in the application's secret store and send it as a Bearer token to the public gateway.

The API key authorizes access to inference. It is not attestation evidence and it is not sent from the gateway to the inference worker.

3. Send a completion

Call the OpenAI-compatible chat-completions endpoint with the API key, a model ID from the public model catalog, and the request messages. The gateway checks the key and the model ID. It forwards a valid request only after its verified worker channel is ready.

The successful response includes an x-request-id header. Save this value. It identifies the receipt for this request. The completion response is model output; it is not proof by itself. For server-sent events, use the same chat-completions endpoint with stream: true.

4. Get and verify the receipt

Read the receipt by using the completion's x-request-id. A receipt contains safe metadata, request and response hashes, and an Ed25519 signature. It does not contain the API key, prompt, completion text, or receipt private key.

Verify the receipt signature with the receipt public key from step 1. That key is bound by the gateway's TDX evidence. This proves that the attested gateway signed the receipt for the listed hashes. It does not reveal or prove the plaintext request or response unless you independently compare those hashes with the values you have retained.

5. Request fresh attestation when needed

Request new attestation with a new nonce whenever you need current proof. Do not reuse an attestation nonce. Fresh evidence lets you check the current gateway and worker claims again; it does not change a completed receipt.

6. Revoke the API key and test access removal

An administrator can revoke the named API key in the key management control plane. A later completion request with that key returns 401 invalid_api_key. This shows authorization was removed. It is separate from the hardware attestation and receipt checks.

Check service readiness and models

Use health to check whether the gateway can use its verified worker channel. Use models to read the public model catalog. Neither endpoint is hardware evidence; request attestation when you need that proof.