Skip to main content
A confidential model is served by an upstream provider whose enclave the gateway verifies before forwarding your prompt. Each provider produces one enforceable channel binding and a set of typed claims. This page summarizes what each provider proves. The receipt’s upstream.verified.session_id identifies the attested session that served a request. Fetch that session for the provider, channel binding, and verified claims. The platform adds confidential providers over time, so treat the cited session as the authoritative per-response record rather than this list.

​
Providers and bindings

  • A tls_spki_sha256 binding pins the upstream HTTPS connection to the verified TLS key.
  • An e2ee_public_key_sha256 binding encrypts the request body to the verified enclave key, so only that enclave can decrypt it.
  • A proxy_image_sha256 binding records provider, proxy_image_digest, and credential_sha256 for Privatemode’s co-deployed proxy. The gateway checks the credential and forwards only to the private proxy in its measured deployment; the proxy verifies and encrypts the provider hop.
  • Zero data retention means the provider does not keep prompt or completion content after serving a request. It rests on the provider’s contract or published policy, not on the attestation report. Third-party routed providers such as openai and anthropic are not in this set. To enforce the property per request, send provider: {"zdr": true}. See Zero data retention.

​
What each provider attests

Claims are honest about their source. A claim is asserted only when that provider’s verifier backs it; anything not established is Unknown. See Claims for the vocabulary. Notes:
  • tee_attested is hardware-proven for Tinfoil, NEAR AI, Chutes, Phala, and 0G: a genuine TEE quote is verified and the request channel is bound to it. Privatemode’s claim is verifier-derived by privatemode-proxy/co-deployed-contrast/v1, based on its co-deployed proxy and channel binding.
  • tcb_up_to_date is tri-state when the verifier reports a TCB status: an up-to-date platform asserts it, a stale platform refutes it, and an absent status is Unknown. Tinfoil’s verifier requires an up-to-date TCB but exposes no separate status, so its claim is verifier-derived.
  • os_known_good is verifier-derived for Phala when the attested OS image resolves to a known production image. The other providers in this table leave it Unknown.
  • serving_software_known_good is asserted for Tinfoil by comparing its launch measurement against published Sigstore golden values for the build. Other providers in this table leave it Unknown today.
  • gpu_attested asserts when the provider’s NVIDIA confidential-computing GPU attestation is verified and nonce-bound. It attests a genuine confidential GPU, not its binding to the serving CPU TEE, so it is verifier-derived and never gates a session.

​
Router-backed providers

Some providers (NEAR AI, Tinfoil) front many models behind one TEE gateway. The gateway verifies that gateway channel, so it produces one attested session per router, and the served model is recorded on the receipt. Per-model coverage is delegated to the verified router, which attests its own backend model enclaves.

​
Generic routed providers

A routed response goes to a third-party provider with no confidential-inference verifier (for example OpenAI or Anthropic). The receipt records upstream.verified.result = failed and required = false. The request is served through the TEE gateway, but the upstream is not attested. See Trust boundary.

Verified upstreams

Channel binding, attested sessions, and how to read a claim.

Models

Confirm a confidential response from its receipt.