> ## 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 is the gateway's proof of identity. It shows that the gateway is a
specific piece of software running inside a genuine Intel TDX TEE, and it publishes the public keys
the gateway uses to sign receipts and to run end-to-end encryption. Every other guarantee depends on
this report, so verify it first.

Fetch it with a fresh nonce:

```bash theme={null}
curl "https://api.redpill.ai/v1/aci/attestation?nonce=$(openssl rand -hex 16)" \
  -H "Authorization: Bearer $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_id`                    | A SHA-256 identity for the running workload. Acts as the stable name of "which gateway is this".                                                       |
| `workload_keyset_digest`         | A SHA-256 digest over the published key set. Binds the keys below to this identity.                                                                    |
| `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 public keys this workload uses: `workload_identity`, `receipt_signing_keys`, `e2ee_public_keys`, `tls_public_keys`, and the `keyset_epoch`.        |
| `attestation.keyset_endorsement` | A signature, under the workload identity key, over the keyset. Ties the keys to the identity.                                                          |
| `attestation.source_provenance`  | The source the workload was built from: `repo_url`, `repo_commit`, and optional `image_digest` / `image_provenance`.                                   |
| `attestation.freshness`          | `fetched_at` and `stale_after` timestamps for the report.                                                                                              |
| `service_capabilities`           | Runtime facts, including `supported_e2ee_versions`.                                                                                                    |
| `all_attestations`               | An array of full attestation objects, one per server, for multi-instance deployments.                                                                  |

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. `keyset_endorsement` verifies under `workload_keyset.workload_identity`, so the receipt-signing
   and E2EE keys genuinely belong to this workload.
3. `workload_id` and `workload_keyset_digest` match what later receipts cite.
4. The report is fresh (`freshness.stale_after` is in the future).
5. In production, `source_provenance` matches the reviewed release.

Steps 1 through 4 are mechanical and run offline once you hold the report. Step 5 is a policy
decision: it compares the attested source against the release you are willing to trust.

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

## Multi-server deployments

An endpoint can be served by more than one TEE instance behind the same hostname. The
top-level `attestation` is the instance that answered your request; `all_attestations` lists every
instance's report. When you verify, check the instance that signed your receipt by matching
`workload_id` and `workload_keyset_digest`.

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