What the gateway protects
- Gateway identity. You can prove the gateway is a specific reviewed workload in a genuine TEE, using the attestation report.
- Per-response integrity. A signed receipt binds your request and response hashes to that workload. Tampering is detectable.
- No body retention. The gateway does not store request or response bodies . Receipts hold hashes, not content.
- Confidential upstreams. For confidential models, the upstream enclave is verified and the channel is bound before your prompt is forwarded, fail-closed.
What it does not protect
- Plain TLS is visible to the attested gateway. After TLS terminates inside the TEE, the gateway processes your request in plaintext. The protection is that the gateway is attested and retains nothing, not that the gateway never sees the request. Add E2EE for field-level encryption, which is still decrypted inside the attested gateway.
- Routed models expose your prompt to the third party. For a routed model (for example
openai/*oranthropic/*), the gateway forwards to the provider over ordinary TLS. That provider sees your prompt and is not attested. Routing does not make a third-party provider confidential. - The gateway does not make an arbitrary upstream private. A provider is only confidential when its adapter can verify a provider-specific identity and enforce the channel binding.
- Receipts are retained for a limited window. Receipts are kept in memory with a configurable TTL; there is no durable public transparency log yet.
Where plaintext exists
| Stage | Who can see plaintext |
|---|---|
| Your device to gateway | Protected by TLS; with E2EE, selected fields are encrypted to the gateway’s attested key. |
| Inside the gateway TEE | The attested gateway, after TLS termination or E2EE decryption. It retains nothing. |
| Gateway to confidential upstream | Only the attested upstream enclave (channel-bound). |
| Gateway to routed upstream | The third-party provider, over ordinary TLS. |
A note on optional middleware
The gateway design allows an optional middleware layer for routing and business logic. If a deployment enables middleware, that middleware runs inside the same attested deployment and can see plaintext after gateway decryption, by design. Middleware never creates verification facts: upstream verification and channel binding remain the backend’s responsibility, and the receipt records the verified result.Choosing a model for sensitive data
- Use a confidential response when the upstream that runs the
model must be attested and your prompt must not reach a non-attested third party. Confidentiality is
a property of the verified upstream provider, confirmed per response from the receipt’s
upstream.verifiedevent, not from the model id. - Add E2EE when you want field-level encryption in addition to TLS.
- Use a routed model when you accept that the third-party provider sees the prompt and you mainly want a single endpoint with a signed integrity receipt.