upstream.verified event
references it by session_id, so you can trace any confidential response back to the exact security
context that served it.
What a session captures
A session is the verified channel (an attested upstream endpoint), not a model. One channel can serve many models, so a router-backed provider produces one session, and the served model is recorded on the receipt, not the session. A session captures:- The verified upstream identity and endpoint.
- The enforceable channel binding (a TLS SPKI digest or an E2EE public key).
- A set of typed claims about the TEE, each with an honest source.
- The byte-preserving evidence the verifier checked.
Immutable and content-addressed
Thesession_id is the 64-character lowercase hex SHA-256 of the full session document in canonical
JCS form. Any change to that document, including its evidence or timestamps, produces a different
id. Sessions are immutable and never updated in place.
Because the id is a content hash, recomputing it proves the fetched session is exactly the document
the receipt cited.
Typed claims
A session does not say “trusted”. It carries a fixed set of claims, each with a status, a source, and a plain reason. The source states who vouches for the claim, so a hardware-proven fact and an operator’s assertion never look alike:
A claim that is not established is
unknown, never a silent pass. Read
Reading TCB and claims for the full vocabulary and how each
provider populates it.
Tracing a receipt to its session
upstream.verified event carries result, required, model_id, and session_id.
Fetch GET /v1/aci/sessions/{session_id} for the provider, channel
binding, claims, and evidence.
Next
Channel binding
How the gateway enforces the binding a session records.
Reading TCB and claims
The typed claim vocabulary and per-provider mapping.