E2EE, in plain terms
Every platform says “encrypted”. The word does almost no work until you ask one question: who holds the key? This page answers it for Mindward, with pictures, including the parts that are not finished.
“Encrypted” usually means their key
Encrypted in transit, encrypted at rest — with a key they hold. That protects their disks from thieves. It does not protect your text from them: staff tools, indexing, training pipelines and policy changes all happen on the readable side.
The key never visits the server. What the server stores, the server cannot open — not by policy, but by arithmetic. The question “can we read your stored messages?” stops being a promise and becomes a property.
How Mindward seals a message
Two standard, boring, well-studied primitives. No invented cryptography — inventing cryptography is how this goes wrong.
The recipient public key sits in the server’s configuration. The private half is generated by you and never touches the box — not at setup, not at runtime, not during backups. The same mechanism seals the automatic snapshots: the server produces backups whose message bodies it cannot decrypt.
The machine cannot read the messages it keeps
“Cannot” includes the operator. Where your message bodies live, root sees ciphertext, a compromised admin account sees ciphertext, a rogue script sees ciphertext; a copied disk is a copied pile of sealed envelopes — with the tool-call caveat below.
The honest cost: lose the private key and the archive stays sealed — for us too. There is no recovery desk, because a recovery desk is a second key held by somebody else. That is not a flaw in the design; it is the design.
What the seal covers — and what it cannot
Covered
- The message bodies of your stored conversations on the hosted tier.
- Every automatic backup of those bodies — sealed by a machine that cannot open them.
- A stolen or copied disk: your message bodies yield only ciphertext.
- A curious operator, a compromised root account, a rogue script — none can open a sealed body.
Not covered
- Text being processed. To run your prompt, whoever runs the harness handles it in the clear — on hosted rungs, that is us, under the retention policy.
- The model that runs your prompt sees it. Point at your own models and that is you.
- Your own device. E2EE cannot help a compromised laptop.
- Tool-call records, today. The seal covers message bodies; extending it is in progress, and until it ships we do not claim complete coverage. What we do not claim keeps score.
A page that tells you exactly where encryption stops is rarer than encryption itself. Judge vendors by whether they will print this list.
Why AI platforms rarely do this
A typical AI service wants your stored history readable: for features, for support, for analytics, sometimes for training. So the key stays with them, and your protection is a paragraph in a policy — a paragraph that can change, at a company that can be acquired.
Mindward can seal storage because the business does not depend on reading it. The product is the harness, not your data. The seal costs us features — no server-side search inside your sealed history, no “we noticed you talked about…” — and we consider that a fair trade, because it is the trade you would choose.
And where the seal cannot reach — the processing of a live prompt — we do not wave the word “encrypted” at you. On that side our own protection is also a policy, which is exactly why we do not call it a seal, and why the seal exists for storage. The privacy simulator shows which stages stay open on each rung, in amber, on purpose.