> ## Documentation Index
> Fetch the complete documentation index at: https://docs.redpill.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Attested Sessions

> An attested session is the verified security context behind a confidential response: one immutable record per verified TEE channel, with typed claims and an enforceable binding.

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](/confidential-ai/channel-binding) (a TLS SPKI digest or an E2EE
  public key).
* A set of [typed claims](/confidential-ai/tcb-and-claims) about the TEE, each with an honest source.
* The byte-preserving evidence the verifier checked.

## Immutable and content-addressed

The `session_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:

| Source              | Meaning                                              |
| ------------------- | ---------------------------------------------------- |
| `hardware_proven`   | Comes from the verified TEE quote or its collateral. |
| `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.                    |

A claim that is not established is `unknown`, never a silent pass. Read
[Reading TCB and claims](/confidential-ai/tcb-and-claims) for the full vocabulary and how each
provider populates it.

## Tracing a receipt to its session

```text theme={null}
response  → x-receipt-id
receipt   → upstream.verified { session_id }
session   → { binding, claims (+ reasons), evidence }
```

The receipt's `upstream.verified` event carries `result`, `required`, `model_id`, and `session_id`.
Fetch [`GET /v1/aci/sessions/{session_id}`](/api-reference/sessions) for the provider, channel
binding, claims, and evidence.

## Next

<CardGroup cols={2}>
  <Card title="Channel binding" icon="lock" href="/confidential-ai/channel-binding">
    How the gateway enforces the binding a session records.
  </Card>

  <Card title="Reading TCB and claims" icon="list-check" href="/confidential-ai/tcb-and-claims">
    The typed claim vocabulary and per-provider mapping.
  </Card>
</CardGroup>