Skip to main content
The platform runs inference behind an Attested Confidential Inference (ACI) gateway. The gateway is a workload running inside a Trusted Execution Environment (TEE, Intel TDX). It does two things a normal API cannot:
  1. It proves which code is running, in a real TEE, with an attestation report.
  2. It signs a per-response receipt that ties your exact request and response to that attested workload.
You do not have to trust the platform’s word. You fetch these artifacts and check the signatures and hashes yourself. This page explains the model. To run the checks, see Verify a response.

​
The two proof layers

Attestation report

Proves the gateway is a specific workload running in a genuine TEE, and publishes the keys it signs with. Fetch it from GET /v1/aci/attestation?nonce=.

Signed receipt

Proves what the gateway received and returned for one request, signed by a key from the attested report. Fetch it from GET /v1/aci/receipts/{id}.
The report answers “who served me?”. The receipt answers “what did they do with my request?”. A receipt is only meaningful once you have verified the report, because the report is what tells you the receipt’s signing key is bound to a genuine TEE.

​
Request flow

  1. You call the API over TLS, or add E2EE for field-level encryption.
  2. The gateway records your request and computes its hash.
  3. For a confidential model, the backend verifies the upstream provider and enforces a channel binding before forwarding. If it cannot, it does not send your prompt (fail-closed).
  4. The response returns through the gateway, which signs the receipt after it has observed the final response bytes.

​
Confidential vs routed models

The platform serves two kinds of models through the same TEE gateway. The difference is whether the upstream that runs the model is itself attested.
ConfidentialRouted
Upstream verifiedYes, before forwardingNo
Receipt upstream.verified.resultverifiedfailed
Receipt upstream.verified.requiredtrue (fail-closed)false
Attested sessionYes (session_id present)No (session_id absent)
Who can see your promptOnly the attested gateway and the attested upstream enclaveThe attested gateway, then the third-party provider (for example OpenAI)
Both kinds run through the TEE gateway, so the gateway protects your request in transit and does not retain request bodies. Only confidential responses extend that protection to the upstream that actually runs the model. For the precise limits, read Trust boundary.
Whether a response is confidential depends on the upstream provider that serves it, not on the model id. Confirm it from the receipt: upstream.verified.result is verified and required is true, and upstream.verified.provider names the provider that served it. See Confidential models.

​
What you can verify

After one request you hold enough to check, locally:
  • The gateway is a genuine TEE workload with a known identity (attestation report).
  • The receipt was signed by a key that report endorses.
  • The signed request hash matches the request you sent, and the signed response hash matches the response you received.
  • For a confidential model, the upstream was verified and the channel was bound before your prompt was forwarded.
Continue with the concept pages below, or jump to the hands-on Verify a response guide.

Attestation report

Receipts

Attested sessions

Channel binding