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

# How Confidential AI Works

> The platform serves an API from a TEE-attested gateway and proves each response with an attestation report and a signed receipt.

The platform runs inference behind an **Attested Confidential Inference (ACI)** gateway. The gateway is a
workload running inside a Trusted Execution Environment (TEE, Intel TDX). It does two things a normal
API cannot:

1. It proves which code is running, in a real TEE, with an **attestation report**.
2. It signs a **per-response receipt** that ties your exact request and response to that attested
   workload.

You do not have to trust the platform's word. You fetch these artifacts and check the signatures and
hashes yourself. This page explains the model. To run the checks, see
[Verify a response](/guides/verify-a-response).

## The two proof layers

<CardGroup cols={2}>
  <Card title="Attestation report" icon="microchip" href="/confidential-ai/attestation-report">
    Proves the gateway is a specific workload running in a genuine TEE, and publishes the keys it
    signs with. Fetch it from `GET /v1/aci/attestation?nonce=`.
  </Card>

  <Card title="Signed receipt" icon="receipt" href="/confidential-ai/receipts">
    Proves what the gateway received and returned for one request, signed by a key from the attested
    report. Fetch it from `GET /v1/aci/receipts/{id}`.
  </Card>
</CardGroup>

The report answers "who served me?". The receipt answers "what did they do with my request?". A
receipt is only meaningful once you have verified the report, because the report is what tells you
the receipt's signing key is bound to a genuine TEE.

## Request flow

```mermaid theme={null}
flowchart LR
  user["Your app<br/>OpenAI SDK"]
  upstream["Upstream model<br/>provider"]
  subgraph gw["Gateway (TEE)"]
    direction TB
    fe["Frontend"]
    be["Backend<br/>provider verification"]
    fe --> be
  end
  user <-->|"TLS or E2EE"| fe
  be <-->|"verified channel"| upstream
```

1. You call the API over TLS, or add [E2EE](/confidential-ai/e2e-encryption)
   for field-level encryption.
2. The gateway records your request and computes its hash.
3. For a confidential model, the backend verifies the upstream provider and enforces a
   [channel binding](/confidential-ai/channel-binding) before forwarding. If it cannot, it does not
   send your prompt (fail-closed).
4. The response returns through the gateway, which signs the receipt after it has observed the final
   response bytes.

## Confidential vs routed models

The platform serves two kinds of models through the same TEE gateway. The difference is whether the
**upstream** that runs the model is itself attested.

|                                      | Confidential                                                | Routed                                                                   |
| ------------------------------------ | ----------------------------------------------------------- | ------------------------------------------------------------------------ |
| Upstream verified                    | Yes, before forwarding                                      | No                                                                       |
| Receipt `upstream.verified.result`   | `verified`                                                  | `failed`                                                                 |
| Receipt `upstream.verified.required` | `true` (fail-closed)                                        | `false`                                                                  |
| Attested session                     | Yes (`session_id` present)                                  | No (`session_id` absent)                                                 |
| Who can see your prompt              | Only the attested gateway and the attested upstream enclave | The attested gateway, then the third-party provider (for example OpenAI) |

Both kinds run through the TEE gateway, so the gateway protects your request in transit and does not
retain request bodies. Only confidential responses extend that protection to the upstream that
actually runs the model. For the precise limits, read [Trust boundary](/confidential-ai/trust-boundary).

<Note>
  Whether a response is confidential depends on the upstream provider that serves it, not on the model
  id. Confirm it from the receipt: `upstream.verified.result` is `verified` and `required` is `true`,
  and `upstream.verified.provider` names the provider that served it. See
  [Confidential models](/confidential-ai/confidential-models).
</Note>

## What you can verify

After one request you hold enough to check, locally:

* The gateway is a genuine TEE workload with a known identity (attestation report).
* The receipt was signed by a key that report endorses.
* The signed request hash matches the request you sent, and the signed response hash matches the
  response you received.
* For a confidential model, the upstream was verified and the channel was bound before your prompt
  was forwarded.

Continue with the concept pages below, or jump to the hands-on
[Verify a response](/guides/verify-a-response) guide.

<CardGroup cols={2}>
  <Card title="Attestation report" icon="microchip" href="/confidential-ai/attestation-report" />

  <Card title="Receipts" icon="receipt" href="/confidential-ai/receipts" />

  <Card title="Attested sessions" icon="link" href="/confidential-ai/attested-sessions" />

  <Card title="Channel binding" icon="lock" href="/confidential-ai/channel-binding" />
</CardGroup>