Skip to main content
When the gateway verifies a confidential upstream, it records an attested session: an immutable snapshot of the verified TEE channel the request was bound to. A receipt’s upstream.verified.session_id (as_…) references it, so you can trace any confidential response to the exact security context that served it.

​
Resolve a session

It captures the verified upstream identity + endpoint, the enforced channel binding, a set of typed claims, and the byte-preserving evidence the verifier checked. The session_id is a content hash of that material — re-verifying the same channel resolves to the same id (idempotent), and any change (rotated cert, new measurement) produces a new id, so the context can’t silently change.

​
Channel binding

Verifying an upstream isn’t enough on its own — the gateway also binds the connection to the verified enclave before forwarding, and refuses if it can’t: A “verified” result that carries no enforceable binding is rejected — there’s no “verified but unpinned”.

​
Typed claims

A session doesn’t just say “trusted”. It carries a fixed set of claims, each with a status and an honest source — so a hardware-proven fact and an operator’s assertion never look alike. t2 verify surfaces these: A claim that isn’t established is unknown — transparency, never a silent pass. Treat any unknown as “not proven” and weigh it accordingly. See verify a response — t2 verify prints each claim with its status + source.