Skip to main content
Verifying an upstream’s attestation is not enough by itself. The gateway must also prove it sends the prompt to the same verified endpoint. Channel binding closes that gap. For a confidential response, gateway verification and binding are one fact: if the provider cannot be verified and bound, the prompt is not forwarded.

​
Binding Types

The binding type depends on the provider. See Providers.

​
Fail-Closed Forwarding

When upstream.verified.required is true, the gateway must verify the upstream and enforce the binding before forwarding. If verification fails, or if the binding cannot be enforced on the live connection, the gateway rejects instead of sending the prompt. On the Phala TEE-only endpoint, required is true for every routed request. A failed verification refuses forwarding; it does not fall back to an unverified provider.

​
How to Confirm Binding

You do not enforce the provider binding from your client. You verify that the gateway did:
  1. Verify the Attestation Report.
  2. Fetch the Receipt.
  3. Verify the receipt signature and exact request/response body_hash values; require upstream.verified.result: verified, required: true, and a session_id.
  4. Fetch the full Session, verify its content address and evidence, and inspect channel_binding under your policy.
The TypeScript SDK and Private AI Proxy implement client-side checks. cURL inspection alone does not establish channel binding.

Trust Boundary

TCB and Claims