Privacy Model & TEE

​

The vision

Inference you don’t have to trust an operator with. Your prompt is encrypted client-side before it ever leaves your device, then processed inside a Trusted Execution Environment (TEE): an isolated enclave where the hardware itself prevents anyone, including LETHE’s own infrastructure and staff, from reading what’s inside while it runs. When the request finishes, a cryptographic attestation proves it ran in that enclave and was discarded afterward. Not a policy that says the data was deleted. Proof. That’s the difference between “we promise not to look” and “we structurally cannot look.” Candidate TEE providers under consideration: AWS Nitro Enclaves, Google Confidential Space, Phala, and Marlin.

​

What’s actually live today

• API requests (/v1/*) are stateless and not stored server-side, but they are not processed inside a TEE, and there is no attestation of deletion yet.
• Signed-in chat and Studio history is stored as regular, unencrypted rows in Supabase Postgres. This is the known gap between the vision above and where the product is right now.
• Guest history stays in browser localStorage only, private by virtue of never leaving your device, not by any server-side encryption guarantee.

Guest mode is currently the mode that most closely matches the “nothing remembered” promise end to end, precisely because nothing is ever sent to a server-side store in the first place.

​

Planned mitigation

Client-side encryption of signed-in history, or moving that storage behind a TEE-backed store, is the leading candidate fix for the plaintext-Postgres gap. Not yet built. This page will be updated the moment it ships, not before.