How end-to-end encryption protects personal AI data
End-to-end encryption protects personal AI data by encrypting it on your device before it syncs, under a key derived from your passphrase that never leaves the device. The server stores only a nonce and ciphertext per record, so it can hold and return your data but never read it. Edits, deletes, and multi-device sync all work over that sealed envelope.
Why personal AI data needs a stronger guarantee
A personal AI that actually helps you accumulates the most sensitive dataset you own: what you worry about, who matters to you, what you are planning, what you wrote at midnight. If that data syncs to a cloud the provider can read, your protection is a policy, and policies change. End-to-end encryption replaces the policy with a property: the provider cannot read your content because the provider never has the key. This page walks through how that works mechanically, using Violet's published protocol as the concrete example, and then states honestly what the approach does and does not protect against.
Step 1: derive the key on the device
Everything starts with a passphrase only you know. On your device, the passphrase is run through PBKDF2 with SHA-256 and 200,000 iterations, mixed with a random per-account salt, to produce a 256-bit AES key. PBKDF2 is deliberately slow: the iteration count multiplies the cost of every guess an attacker makes, while costing you a fraction of a second once at sign-in. The salt is not a secret. It is stored on the server and handed back at sign-in so that each of your devices can re-derive the exact same key from the same passphrase. The key itself is different: it is created in the browser's cryptography engine and marked non-extractable, which means the platform itself refuses to export the key material. It is never written to disk, never sent to the server, and never visible to the provider.
Step 2: seal each record in an envelope
Before a record syncs, the device encrypts it with AES-256-GCM under that derived key. Each encryption uses a fresh random 96-bit nonce, and the output is an envelope of exactly two fields:
{ "nonce": "<base64>", "ciphertext": "<base64>" }That envelope is the entire content the server ever stores for a record. AES-GCM is authenticated encryption, which matters twice. First, the ciphertext reveals nothing useful without the key. Second, decryption verifies an authentication tag, so if the envelope was tampered with, or the wrong key is used, the operation fails outright instead of silently producing garbage. The system fails closed.
Step 3: sync over ciphertext
Multi-device sync usually forces a choice: either the server reads your data so it can merge changes, or you give up sync. Envelope encryption removes the dilemma by making merge decisions from metadata alone. Alongside each envelope, a record carries a collection name, a record id, a version number, an updated-at timestamp, and a deleted flag. The server merges two versions of the same record by last-writer-wins: the higher version wins, ties break on the later timestamp, and replaying the same write is harmless. At no point does the merge look inside the envelope, because it does not need to.
- An edit is a new envelope with a higher version. The old ciphertext is simply replaced.
- A delete is a tombstone: the record is kept but marked deleted, its envelope is cleared to nothing, and the tombstone propagates to your other devices so the delete wins everywhere.
- A device that was offline pulls every record changed since its last cursor, decrypts locally, and catches up. Conflicts resolve by the same version-then-timestamp rule on every device, so all devices converge to the same state.
Tombstones are worth pausing on, because they are an honest detail most descriptions skip. If deleting a record just removed the row, a device that was offline during the delete would later push the old record back: the deleted data would resurrect itself. Keeping a tombstone, with the content erased and only the merge metadata left, is how a delete becomes durable across devices.
The threat model, honestly
No encryption scheme protects against everything, and a trustworthy product tells you where its protection ends. Here is what this architecture does and does not defend against.
| Threat | Protected? | Why |
|---|---|---|
| Server breach or stolen database | Yes | An attacker gets envelopes and merge metadata, not content. The key is not on the server to steal. |
| A provider insider reading your content | Yes | Sealing and opening run only on the client. The server cannot derive the key from anything it holds. |
| Tampering with stored records | Detected | AES-GCM authentication makes an altered envelope fail decryption instead of decrypting to something wrong. |
| Metadata exposure | No | The provider still sees account identifiers, record counts, envelope sizes, collection names, and sync timing. |
| A compromised device | No | Encryption ends where your device begins. Malware on your endpoint sees what you see. |
| A weak passphrase | Partly | 200,000 PBKDF2 iterations slow down guessing, but they cannot rescue a short or reused passphrase. Length and uniqueness are your real defense. |
| Losing your passphrase | No recovery | Nobody, including the provider, can decrypt without it. That is the point of the design, and it is also its cost. |
| Content you choose to send to a hosted model | No | A request sent to a cloud model is plaintext to that model at request time. End-to-end encryption protects stored content, not the question you are actively asking. |
Common mistakes when evaluating e2e claims
- Confusing HTTPS with end-to-end encryption. HTTPS protects the wire; the server still reads everything on arrival.
- Accepting the word encrypted without asking who holds the keys. Encryption at rest with provider-held keys protects the provider's disks, not you from the provider.
- Ignoring the recovery test. If the provider can reset your passphrase and your content survives, the provider holds a key to your content.
- Forgetting the endpoint. The strongest envelope means nothing on a device you no longer control.
- Assuming e2e hides that you use the service. It hides content, not the existence, timing, or volume of your activity.
How Violet implements this
Violet is a personal AI companion built on exactly this protocol, currently pre-launch. The key derivation (PBKDF2-SHA256, 200,000 iterations, non-extractable AES-256-GCM key), the two-field envelope, the last-writer-wins merge, and the tombstone rules described above are Violet's actual sync protocol, not a simplified sketch. The functions that seal and open envelopes run in the client and in tests, never in the server code path, and the server-side sync endpoints validate and store envelopes without any code path that could decrypt them. Inside the app, a Trust panel reports what is stored and what the cloud can see, read from real state.
Questions
Why is the salt stored on the server if the key must stay secret?
A salt is not a secret. Its job is to make the same passphrase produce a different key for every account, which defeats precomputed guessing tables. The server storing the salt lets each of your devices re-derive the same key from your passphrase, while the key itself is derived and kept only on the client.
Can a deleted record be recovered from its tombstone?
Not its content. When a record is deleted, the stored envelope is cleared and only the merge metadata remains: the record id, version, timestamp, and the deleted flag. The tombstone exists so the delete propagates to your other devices instead of being resurrected by one that was offline.
Is my data end-to-end encrypted while the AI is answering me?
Stored data is. The message you actively send to a hosted model is a different case: it must be plaintext to that model at request time, or the model could not answer. An honest product keeps at-rest content sealed, avoids logging inference message contents, and says this boundary out loud.