ZeroRecallRead the Proof Registry

Security

Built so you do not have to take our word for it.

We sell proof that data was erased. A product like that cannot ask for trust it has not earned, so this page states what we store, what never leaves your side, and which certifications we do not hold.

The commitments

The audited system stays yours

Your chat endpoint, RAG pipeline or vector store is your infrastructure, reached at run time with credentials you provide. We do not choose it, do not keep its data beyond the run, and do not use it for anything except the audit you asked for.

Credentials never enter the evidence pack

Connector credentials are read from the environment at run time and used only to build the request header. They are not written into the evidence pack and not persisted. This is a property of the code, not a promise on a page.

The evidence survives a dishonest reader

Every audit ships as a signed pack: a SHA-256 hash chain, a manifest hash and an ECDSA (P-256) signature made with a key we publish at /.well-known/zerorecall-signing-key.pem. A reader recomputes all four and any alteration by anyone who does not hold our private key shows up. Until 12 August 2026 this page claimed the checks also caught tampering by us. That was wrong and we are saying so here rather than quietly editing it: we hold the signing key, so we could re-issue a different pack and it would verify. Catching that needs a timestamp or a public log outside our control, which is the next thing we are building.

Verification runs in your browser and the file never reaches us

The public verify page recomputes all four checks locally with WebCrypto. The pack is not uploaded, not sent to an API, and not stored: measured in a real browser, the whole verification produces no network request at all. Until 14 August 2026 this check ran on our server, and this page said so, because the verdict was then still our word. It no longer is. A regulator or counsel can confirm a seal without an account and without telling us they looked. The pack format is fully specified on the pack spec page and the algorithms are standard, so you can also verify it with your own tool.

The judge layer is optional

Ambiguous findings can be sent to Anthropic for a second opinion. That step only runs if it is enabled on your audit, and it sees the finding in question rather than your whole corpus.

Card data never reaches us

Payments run through Creem as merchant of record. We never see or store a card number.

Where the data sits

Account data, audit records, findings and evidence metadata are stored in Supabase. The application runs on Vercel. Every provider we use is located outside Türkiye and outside the EU. We put that here rather than in a footnote, because for a compliance buyer it is the first question, not the last.

Which provider touches which data, and why, is listed one by one on the sub-processors page. The contractual side is in the DPA, and your rights are in the GDPR and KVKK notices.

Check a seal yourself

The strongest security property of this product is that it does not depend on our honesty. Drop any .pack.json on the verify page and the hash chain, manifest hash and signature are recomputed in front of you. If we had altered a finding after the fact, that check would fail.

Editing a pack is caught by arithmetic. Replacing one is not, because we hold the key. That case is governed by a written rule instead: our archive policy says a re-issued audit must name the pack it supersedes, by hash, inside the signature. It also says plainly what the rule cannot enforce on its own.

What we do not have yet

When one of these changes, this page changes with it. Dressing a roadmap item up as a shipped control is the one thing an evidence company cannot do.

Found a hole

Write to hello@zerorecall.ai or pick "Bug report" on the contact form. We read it the same business day and tell you what we intend to do within three. There is no bounty programme; we do ask that you hold off publishing until a fix is out.