Encrypted AI memory: what the word actually covers

An AI memory ends up holding the things you would not paste into a public chat: clients, prices, health details mentioned in passing, half-made decisions. So "is it encrypted?" is the right first question. The trouble is that the honest answer is almost always "yes", and it tells you very little until you know which encryption.

Layer 1: in transit

TLS between your AI assistant and the memory server. It stops someone on the network from reading the traffic. Every serious service has it; its absence would be disqualifying, its presence proves nothing else.

Layer 2: at rest, on the disk

The disk or volume holding the database is encrypted. This protects against a stolen drive or a decommissioned server that was not wiped. It does not protect against anyone who can query the running database: to the database, the data is plain text.

Layer 3: per-account keys

Each account's content is encrypted with its own key, and that key is itself locked by something only the user has, typically a password. A database dump, a backup leak, or a bug that returns the wrong rows then yields ciphertext, not memories. This is a real step up from layer 2, because it protects against mistakes and leaks inside the provider's own systems.

Its limit is honest and structural: to search your memories and answer your assistant, the server must use your key while you are signed in. During that window, the provider's running code can read your data.

Layer 4: zero-knowledge (end-to-end)

The provider never holds a usable key. Only your devices can decrypt. This is the only layer that protects you from the provider itself, including a compelled one.

It is rare in AI memory for a concrete reason: semantic search needs the meaning of the text. Something has to compute embeddings and rank results over plaintext. If that happens on your device, the assistant in the cloud cannot simply call the memory as a remote tool; if it happens on the server, the server sees the text. When a hosted memory that searches by meaning advertises "end-to-end encryption", ask where the search runs.

Six questions to ask any provider

1. Which of the four layers do you have? Name them one by one.
2. Is there a key per account, and what locks it: my password, or a key you hold?
3. When exactly can your servers read my memories in clear? ("Never" deserves a technical explanation.)
4. Are backups encrypted with the same per-account keys?
5. If I forget my password, how is my data recovered — and who else could use that path?
6. Which third parties (language models, email, analytics) ever receive the text of a memory, and is that optional?

What Pryzm does, and does not

Pryzm has layers 1, 2 and 3. Each account's memories are encrypted with the account's own key (AES-256-GCM); accounts created before October 2026 switch over at their next sign-in. That key is locked by your password (Argon2id) and by a 12- or 24-word recovery phrase that only you are given. Backups contain the encrypted form. Each account also has its own database schema and role.

Pryzm does not have layer 4. While you are signed in, the server holds your key in memory to search and answer your assistant. Optional AI features (tagging, nightly grouping, summaries) send memory text to a language model provider only if you turn them on in Settings; they are off by default. A message starting with ## is never stored.

If you need a provider that can never read your data, a memory server you host yourself is the honest answer, and several good ones are free. If you want a hosted memory shared by all your assistants, with the provider's own leaks and mistakes kept out of reach, that is what layer 3 is for.