Data Privacy

We assume our own logs, our own team, and our cloud infrastructure could all be adversarial. The guarantee has to hold even if our database is breached, one of our engineers goes rogue, or our cloud provider is compelled to hand over our data.

Two independent layers, each doing its own job:

1. By design (cryptographic). Verification happens on the user's device, or inside a TEE-hosted client. From there, the verified data and its zero-knowledge proof are delivered directly to your application's backend callback. Our servers never see either one.
2. By audit (behavioral). Every week we pull a random sample of live sessions, then run a large language model over every log line looking for PII that might have leaked. Findings are published on this page.

The cryptographic guarantee is what you actually rely on in production. The weekly audit is a tripwire. It's how we'd catch ourselves if we ever shipped a regression that broke layer 1.

All of Reclaim Protocol's verification code is open-source on GitHub. Clone it and confirm for yourself that no raw data path ever leaves the user's device or the TEE-hosted client. Every weekly audit run is published below, with per-session verdicts and the exact PII categories we scan for.

The mathematical soundness of Reclaim Protocol's cryptography, always. And, when verification runs inside our TEE-hosted client (the Node SDK path, not the in-app SDK), the hardware TEE itself: AMD SEV on Google Cloud Confidential VMs. We deliberately do nottrust the user's device. The zk proofs are sound even against a fully malicious user. That's the whole point of using them.