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

# Attested sessions & claims

> The verified upstream channel behind a confidential response — its channel binding, typed TCB claims, and evidence — resolvable from a receipt's session_id.

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.session_id` (`as_…`) references it, so you can trace any confidential response to the exact security context that served it.

***

## Resolve a session

```bash theme={null}
curl "https://api.t2000.ai/v1/aci/sessions/{session-id}"
```

It captures the verified upstream identity + endpoint, the enforced [channel binding](#channel-binding), a set of [typed claims](#typed-claims), and the byte-preserving evidence the verifier checked. The `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 |

A "verified" result that carries no enforceable binding is rejected — there's no "verified but unpinned".

***

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

A claim that isn't established is `unknown` — transparency, never a silent pass. Treat any `unknown` as "not proven" and weigh it accordingly.

See [verify a response](/confidential-ai/verify) — `t2 verify` prints each claim with its status + source.