What the receipt proves
Every Confidential AI response includes a signed receipt id in thex-receipt-id header. The receipt is an ordered transparency event log. It records request and response hashes, the selected route, upstream verification status, and the signature that binds the record to the attested gateway keyset.
For a confidential response, the receipt’s upstream.verified event shows result: verified, required: true, and a session_id. That session records the verified upstream security context and channel binding.
Prerequisites
curl, jq, and a SHA-256 tool. On Linux use sha256sum; on macOS use shasum -a 256.
1. Fetch a fresh gateway attestation
2. Make a request and capture the receipt id
response.json; the receipt commits to the exact response bytes.
3. Fetch the signed receipt
4. Match the receipt to the attested gateway
5. Check the response hash
Theresponse.returned.wire_hash event must match the bytes you received.
request.received.body_hash. In production, hash the exact request body bytes you sent and compare them to that event.
6. Verify the receipt signature
The receipt signature covers the canonical receipt bytes. Verify it under one of thereceipt_signing_keys entries from attestation.workload_keyset.
7. Confirm the upstream was confidential
- Confidential response:
resultisverified,requiredistrue, andsession_idis present. - Routed response:
resultisfailed,requiredisfalse, and nosession_idis present. The gateway was attested, but the upstream provider was not.
Legacy signature endpoint
Older clients may callGET /v1/signature/{id}. It returns the same receipt inside a compatibility envelope:
GET /v1/aci/receipts/{id} directly.
What a passing verification proves
- The gateway is a specific reviewed workload in a genuine TEE.
- The receipt is signed by a key in the attested gateway keyset.
- The response you received is exactly the response the gateway signed.
- For a confidential model response, the upstream provider was verified and channel-bound before forwarding.

