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
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:| Binding | What it pins |
|---|---|
tls_spki_sha256 | The upstream’s TLS public key — pins the HTTPS connection to the verified key |
e2ee_public_key_sha256 | The upstream’s E2E key — encrypts the request body so only the attested enclave can decrypt |
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:
| Source | Assurance |
|---|---|
hardware_proven | From the verified TEE quote or its collateral (strongest) |
verifier_derived | Computed by the verifier from verified evidence |
provider_asserted | Published by the provider, not independently proven |
operator_asserted | Declared by the gateway operator (weakest) |
| Claim | Asks |
|---|---|
tee_attested | Is this a genuine CPU TEE with an identity bound to the channel? |
tcb_up_to_date | Is the platform’s Trusted Computing Base current? (tri-state — a stale TCB is refuted, recorded, not hidden) |
gpu_attested | Is a genuine confidential-computing GPU attested + nonce-bound? |
serving_software_known_good | Does the serving software map to reviewed source? |
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.