upstream.verified.provider, result, required, session_id, channel_bindings, and claims.
Provider and model coverage changes over time. Do not treat documentation as a provider allowlist. Use the live model catalog to discover available models, and use receipts for per-response truth.
Binding Methods
Confidential AI can bind a verified upstream session in more than one way:| Binding | Meaning |
|---|---|
tls_spki_sha256 | Pins the provider-facing HTTPS connection to a verified TLS key. |
e2ee_public_key_sha256 | Encrypts the provider-facing request to a verified enclave key. |
Claim Coverage
Each verified session carries typed claims. Coverage depends on the serving environment and verifier, so clients should evaluate the claims required by their own policy instead of assuming every model has the same evidence.tee_attestedis the baseline hardware claim. A confidential response should assert it with hardware-backed evidence.tcb_up_to_dateis tri-state. A stale TCB (Trusted Computing Base) is recorded as refuted, not hidden.serving_software_known_goodmeans the verifier can connect software measurements to known source or build provenance.gpu_attestedproves GPU attestation evidence was verified and nonce-bound. It is supplemental; the session gate is still the verified and bound upstream channel.model_weights_provenanceis not generally proven today. TreatUnknownas not proven.
Router-Backed Serving
Some serving environments front many models behind one verified gateway. In that case, the attested session belongs to the verified provider channel, and the served model is recorded on the receipt. Do not infer provider security from the model id alone.Routed Responses
Routed responses still pass through the attested Phala gateway, but the upstream serving environment is not attested. The receipt recordsresult: failed and required: false for upstream.verified.