Skip to main content
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: 
curl "https://api.redpill.ai/v1/aci/attestation?nonce=$(openssl rand -hex 16)" \
  -H "Authorization: Bearer $API_KEY"
See GET /v1/aci/attestation for the full field reference. This page explains what each part proves.

​
What the report contains

FieldWhat it proves
workload_idA SHA-256 identity for the running workload. Acts as the stable name of “which gateway is this”.
workload_keyset_digestA SHA-256 digest over the published key set. Binds the keys below to this identity.
attestation.tee_typeThe TEE technology, for example tdx.
attestation.evidence.quoteThe hardware-signed TDX quote. This is the root of trust for everything else in the report.
attestation.report_dataThe 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_keysetThe public keys this workload uses: workload_identity, receipt_signing_keys, e2ee_public_keys, tls_public_keys, and the keyset_epoch.
attestation.keyset_endorsementA signature, under the workload identity key, over the keyset. Ties the keys to the identity.
attestation.source_provenanceThe source the workload was built from: repo_url, repo_commit, and optional image_digest / image_provenance.
attestation.freshnessfetched_at and stale_after timestamps for the report.
service_capabilitiesRuntime facts, including supported_e2ee_versions.
all_attestationsAn 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 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.
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.

​
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

Receipts

How a single response is bound to this attested identity.

Verify a response

Run the full check end to end.