Skip to main content
For a confidential model, the gateway verifies the upstream enclave before it sends your prompt, and refuses to send if it cannot. Verification produces three things: a channel binding the gateway enforces on the wire, an attested session it records, and the typed claims inside that session. The receipt’s upstream.verified event ties a response to all three.

​
Channel binding

Verifying an upstream’s attestation is not enough on its own: a genuine enclave could exist while the gateway talks to a different server. Channel binding closes that gap. The value the gateway verifies is the value it enforces on the connection before forwarding. Every confidential provider produces exactly one binding, and it lives inside the verified attestation. A “verified” result without an enforceable binding is rejected in the gateway itself: a provider can never be verified but unpinned. Which provider uses which binding is on the Confidential providers page. For a confidential model, upstream.verified.required is true. If the gateway cannot verify the upstream or enforce the binding on the actual connection, it does not send your prompt. If the binding stops matching, the gateway re-verifies before forwarding; retries cannot bypass this. For a standard model, required is false: the gateway forwards to the third-party provider over ordinary TLS, the receipt records result: failed, and your prompt leaves the gateway. See Trust boundary.

​
Attested sessions

When the gateway verifies an upstream, it records an attested session: an immutable snapshot of the verified channel. A session is the channel, not a model. One channel can serve many models, so a router-backed provider produces one session and the served model is recorded on the receipt. A session captures:
  • the verified upstream identity and endpoint;
  • the enforced channel binding;
  • the typed claims about the TEE, each with its source; and
  • the byte-preserving evidence the verifier checked.
The session_id is the SHA-256 of the full session document in canonical JCS form, as 64 lowercase hex characters. Any change to the document produces a different id, so recomputing the hash proves the session you fetched is exactly the one the receipt cited.
Fetch GET /v1/aci/sessions/{session_id} for the provider, binding, claims, and evidence. You do not enforce the binding yourself; you confirm after the fact that the gateway did: result is verified, required is true, and the cited session carries the binding.

​
Claims

A session never says “trusted”. It carries a fixed set of claims, each with a status, a source, and a plain reason, so a hardware-proven fact and an operator’s assertion never look alike.
Two claims need care when you read them:
  • tcb_up_to_date is read from the verifier’s reported TCB status. An up-to-date platform asserts it, a stale platform refutes it, and an absent status leaves it unknown. Freshness comes from the evidence, never from policy.
  • gpu_attested is asserted with source verifier_derived when the provider’s NVIDIA confidential-computing GPU attestation is verified and bound to the nonce. It proves a genuine confidential GPU exists for that nonce, not that the GPU is bound to the CPU TEE serving your request, so it never gates a session.
To use claims in a decision: require tee_attested to be asserted with source hardware_proven; treat serving_software_known_good: asserted as stronger than any provider_asserted claim about software; decide your own policy on tcb_up_to_date: refuted; read gpu_attested as supplemental; and treat every unknown as not proven. Which provider asserts which claim is on the Confidential providers page.

Confidential providers

Binding type and asserted claims per provider.

Receipts

The upstream.verified event that cites a session.

Session endpoint

Fetch a session by id, or list current sessions.

Trust boundary

What the gateway does and does not protect.