Skip to main content
It is inference served by a gateway running in a TEE that proves its own identity with an attestation report and signs a per-response receipt binding your request and response to that attested workload. You verify the proofs yourself rather than trusting an API’s word.
A confidential response runs on an upstream enclave that the gateway verifies before forwarding your prompt, fail-closed. A routed response passes through the TEE gateway but the upstream is not attested and sees your prompt. Confidentiality is a property of the verified upstream provider, not of the model id; confirm it per response from the receipt’s upstream.verified event (result = verified, required = true). See How it works and Trust boundary.
Plaintext is visible to the attested gateway after TLS or E2EE decryption, because it has to process the request. The gateway is a reviewed workload running in a TEE and does not retain request or response bodies. It does not mean no software ever sees the request. For the exact boundary, read Trust boundary.
No. E2EE encrypts selected fields to a key from the attested keyset, and the gateway decrypts them inside the TEE to process the request. E2EE proves the decryption key belongs to the attested workload; it does not hide the request from that workload.
Verify the attestation report, then fetch the receipt by its x-receipt-id and confirm upstream.verified.result = verified and required = true. The full procedure is in Verify a response.
The gateway binds your nonce into the hardware-signed quote’s report_data. A report that commits to a nonce you just generated cannot be a replay of an older capture, which is how you prove freshness. Use a new random nonce each time.
Receipts, which hold hashes of your request and response, not the content. The gateway does not store request or response bodies. Receipts are retained for a configurable window.
Tinfoil, NEAR AI, Chutes, and Phala-backed enclaves, among others the platform adds over time. Each enforces a channel binding and attests a set of typed claims. The receipt’s upstream.verified.provider records which provider served a given request. See Providers.
The canonical endpoints live under /v1/aci/: GET /v1/aci/attestation, GET /v1/aci/receipts/{id}, and GET /v1/aci/sessions/{id}. The older GET /v1/attestation/report and GET /v1/signature/{id} remain as legacy compatibility aliases that return the same data in a legacy envelope. Use the /v1/aci/* endpoints for new integrations.