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

# Attestation Report

> The gateway attestation report proves which TEE workload served your request and publishes the keys it signs with.

The attestation report establishes a measured workload running inside an Intel TDX TEE and publishes
the keys used for receipts, TLS, and end-to-end encryption. A reviewed-release allowlist is required
to turn that measurement into a claim about approved software.

Fetch it with a fresh nonce:

```bash theme={null}
curl "https://tee.redpill.ai/v1/aci/attestation?nonce=$(openssl rand -hex 32)" \
  -H "Authorization: Bearer $REDPILL_AI_API_KEY"
```

See [`GET /v1/aci/attestation`](/api-reference/attestation) for the full field reference. This
page explains what each part proves.

## What the report contains

| Field                                   | What it proves                                                                                                                                         |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `workload_keyset_digest`                | A SHA-256 digest over the published keyset. Receipts cite this digest.                                                                                 |
| `attestation.tee_type`                  | The TEE technology, for example `tdx`.                                                                                                                 |
| `attestation.evidence.quote`            | The hardware-signed TDX quote. This is the root of trust for everything else in the report.                                                            |
| `attestation.report_data`               | The value bound into the quote. It commits to your `nonce` and the published keyset, which is how you prove the quote is fresh and matches these keys. |
| `attestation.workload_keyset`           | The keyset subject, expiry, receipt-signing keys, E2EE keys, and TLS SPKI pins.                                                                        |
| `attestation.workload_keyset.not_after` | Unix timestamp after which verifiers reject the keyset.                                                                                                |
| `attestation.source_provenance`         | Workload-declared source labels: `repo_url`, `repo_commit`, and optional image fields. These are not a release trust anchor.                           |
| `service_capabilities`                  | Runtime facts, including `supported_e2ee_versions` and `serving`.                                                                                      |

The receipt-signing keys live in `attestation.workload_keyset.receipt_signing_keys`, and the E2EE keys
in `attestation.workload_keyset.e2ee_public_keys`. (The legacy
[`/v1/attestation/report`](/api-reference/attestation-report) alias also adds top-level
`signing_address` / `signing_algo` / `signing_public_key` for older clients.)

## Why the nonce matters

You pass `?nonce=<random>`. The gateway mixes your nonce into `report_data` inside the
hardware-signed quote. Because the quote is signed by the TEE, a report that commits to a nonce you
just generated cannot be a replay of an old capture. Generate a new nonce every time you verify, and
confirm the report's `report_data` is derived from that nonce and the published keyset.

## How verification uses the report

A verifier checks, in order:

1. `attestation.evidence.quote` verifies against Intel's DCAP collateral, and the quote's report
   data binds your `nonce` and the `workload_keyset`.
2. The quote-bound statement commits to the JCS digest of `workload_keyset`.
3. `workload_keyset_digest` matches what later receipts cite.
4. The keyset has not expired (`workload_keyset.not_after` is in the future).
5. The event log replays to the quote's RTMR3 and its measured `compose-hash` equals
   `sha256(app_compose)`.
6. For reviewed-release enforcement, the measured compose hash is in an independently obtained
   allowlist.

`source_provenance` helps locate source for review, but the workload declares it. The compose hash is
the value bound into RTMR3 and accepted by verifier policy.

<Note>
  The gateway loads its identity and signing keys from dstack KMS inside the TEE. There is no
  ephemeral-key or stub-quote mode: a report always carries a real hardware quote.
</Note>

## Next

<CardGroup cols={2}>
  <Card title="Receipts" icon="receipt" href="/confidential-ai/receipts">
    How a single response is bound to this attested identity.
  </Card>

  <Card title="Verify a response" icon="circle-check" href="/guides/verify-a-response">
    Run the full check end to end.
  </Card>
</CardGroup>