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

| Source             | Meaning                                              |
| ------------------ | ---------------------------------------------------- |
| `HardwareProven`   | Comes from the verified TEE quote or its collateral. |
| `VerifierDerived`  | Computed by the verifier from verified evidence.     |
| `ProviderAsserted` | Published by the provider, not independently proven. |
| `OperatorAsserted` | 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 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}`](/api-reference/sessions).

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