https://inference.phala.com/v1 uses the TEE-only serving policy. The Phala gateway requires upstream verification and channel binding before forwarding; if that fails, it refuses the request. The evidence covers different boundaries for different providers.
What the gateway protects
- Gateway identity: A fresh attestation report binds the gateway keyset to hardware evidence.
- Per-response integrity: A signed receipt binds request and response hashes to that keyset.
- No body retention in receipts: Receipts contain hashes and verification facts rather than prompt or response bodies.
- Required upstream verification: The gateway verifies the provider boundary and enforces channel binding before forwarding.
- Optional retention constraint:
provider: {"zdr": true}restricts routing to serving routes that do not retain prompt or completion content. See Zero Data Retention.
Limits
- Plaintext is processed in the gateway TEE: TLS terminates there. Field-level E2EE encrypts to an attested gateway key and decrypts inside that gateway.
- Upstream coverage varies: Some verifiers cover a model CVM, others a router or broker. Read the cited session’s claims; gateway attestation does not independently attest every upstream model worker, GPU link, or model weight.
- Client verification is explicit: Ordinary clients do not verify the quote, pin TLS to the attested key, or audit receipts. Use the TypeScript SDK or Private AI Proxy.
- Receipts are not a permanent public log: Fetch them promptly and archive them if durable evidence is required.
- Local tools remain separate: Agent tools, MCP servers, browser automation, and telemetry can expose data outside the inference boundary.
Where plaintext exists
Upstream binding boundaries
The Privatemode proxy owns Contrast verification, secret exchange, and body encryption after that internal hop. Its dynamic manifest observation is not bound to the active inference secret.