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 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

The session_id is a content hash of the verified material (as_<sha256>), with timestamps excluded. Two consequences follow:
  • Idempotent. Re-verifying the same endpoint with the same result resolves to the same session_id. The record is not duplicated.
  • Tamper-evident by construction. Any change in the verified material (a rotated TLS certificate, a new measurement after a redeploy, a changed claim) produces a different session_id, that is, a new session. The security context can never silently change under a fixed id.
Because the id is a content hash, the session a receipt points to is exactly the one the gateway committed to when it served your request.

​
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:
SourceMeaning
HardwareProvenComes from the verified TEE quote or its collateral.
VerifierDerivedComputed by the verifier from verified evidence.
ProviderAssertedPublished by the provider, not independently proven.
OperatorAssertedDeclared by the gateway operator.
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

response  → x-receipt-id
receipt   → upstream.verified { session_id }
session   → { binding, claims (+ reasons), evidence }
The receipt’s upstream.verified event carries the verified result, the typed claims, and the channel binding inline (provider, result, required, session_id, claims, channel_bindings), so you can check a response without a second request. For the immutable, deep-audit record with full evidence, fetch GET /v1/aci/sessions/{session_id}.

​
Next

Channel binding

How the gateway enforces the binding a session records.

Reading TCB and claims

The typed claim vocabulary and per-provider mapping.