Channel Binding and Fail-Closed Forwarding

Verifying an upstream’s attestation is not enough on its own. A verifier could prove a genuine enclave exists while the gateway still talks to a different, unverified server. Channel binding closes that gap: the value the gateway verifies is the same value it enforces on the wire before it forwards your prompt.

​

The two binding types

Every confidential provider produces exactly one binding, and that value lives inside the verified attestation. Which providers use which binding is listed on the Providers page.

​

The invariant: verified implies an enforceable binding

The gateway treats verification and binding as one fact. A “verified” result that carries no enforceable binding is rejected. A provider can never be “verified but unpinned”. This is enforced in the gateway, not left to configuration.

​

Fail-closed forwarding

For a confidential model, upstream.verified.required is true. If the gateway cannot verify the upstream, or cannot enforce the verified binding on the actual connection, it does not send your prompt. Retries and reconnects cannot bypass this: if the channel binding no longer matches, the gateway re-verifies before forwarding. For a routed model, required is false. The gateway forwards to the third-party provider over ordinary TLS without an attested binding, and the receipt records result: failed. Your prompt still leaves the gateway, so use confidential models when the upstream must be attested. See Trust boundary for the full picture.

​

How you confirm it

You do not enforce the binding yourself; the gateway does, before forwarding. What you verify after the fact is that it happened:

1. Verify the attestation report and the receipt.
2. Read upstream.verified. For a confidential response, result is verified and required is true, and the event references the attested session whose binding the gateway enforced.

​

Next