Encrypting AI memory: why a key per project beats a key per database

A memory worth having is a memory worth protecting. If a system is going to hold what you told it about your child's diagnosis, your legal case, or your finances, then "encrypted at rest" — the phrase every vendor uses — deserves a harder look at what it actually means.

TL;DR

Every memory file and every chat message is encrypted under a key belonging to one project alone, not a single key for the whole database.
Deleting a project destroys its key, so the data becomes unreadable in backups too — not just in the live system.
We do not search over ciphertext, and we do not store your text in the search index. Both choices follow from published attacks, not from taste.

What "encrypted at rest" usually means

Most often it means full-disk or volume encryption. The disk is encrypted; the database process holds the key and decrypts everything it reads. That defends against one specific thing — somebody physically removing the drive — and against almost nothing else. An attacker who reaches the running database, a stolen backup that ships with its key, an over-broad internal query: in all of these the data is plainly readable, because from the database's point of view it always was.

It also has an uncomfortable property for a product built on memory: one key opens everyone. There is no technical boundary between your material and another customer's, only correctly written queries.

A key per project

FocusLM encrypts at the level of the row, not the disk. Each project gets its own data key. Every memory file, every revision of it, and every message in that project's chat is encrypted with that key and no other. Chat threads that belong to no project are encrypted under a workspace key on the same principle.

Those per-project keys are themselves encrypted by one key for the environment, which is never stored beside the data it protects. This arrangement — a key that encrypts keys, which encrypt data — is envelope encryption, and it is the standard recommendation for key hierarchies in NIST's key-management guidance. It buys two practical things: rotating the top key touches one small row per project rather than re-encrypting anyone's data, and a single project's key can be destroyed on its own.

One environment key wraps a separate data key per project. Project A's material is encrypted only under A's key — the database never holds a key that opens everything.

The binding is tighter than "same key, same project". Each encrypted value is cryptographically tied to the exact row and project it belongs to, so a ciphertext copied into another project does not decrypt into the wrong context — it fails to decrypt at all. Moving data between tenants is not a subtle bug that surfaces later; it is an error at the moment of the attempt.

Why we do not search over ciphertext

The obvious wish is to keep everything encrypted and still run ordinary text search over it. Schemes exist — deterministic encryption makes equal values equal, order-preserving encryption keeps values sortable — and they are exactly as convenient as they sound.

They also leak. A long line of work on inference attacks against property-preserving encrypted databases shows that when ciphertexts preserve equality or order, an attacker with nothing but the encrypted column and ordinary public statistics can recover a great deal of the plaintext. Frequency analysis does most of the work: in real data, the distribution of values is rarely flat, and encryption that preserves structure preserves the distribution along with it.

This is why FocusLM decrypts inside the application and filters there, rather than asking the database to match on ciphertext. The cost is real and worth naming: a literal search reads the whole project's notes rather than letting an index narrow them first, so the work grows with the size of your memory instead of staying flat. We took that over buying searchability with a permanent leak of term frequencies — which, in a personal memory, are the words that matter most.

The search index does not hold your text

Semantic search needs vectors, and vectors have their own privacy story — one that is easy to get wrong, because an embedding looks like an inert list of numbers.

It is not inert. In Text Embeddings Reveal (Almost) As Much As Text, Morris and colleagues showed that dense embeddings can be inverted back into their original text by treating reconstruction as controlled generation and iteratively correcting a guess until it re-embeds to the same point. They recovered 92% of 32-token inputs exactly, and recovered full patient names from a corpus of clinical notes. Later work generalised the attack: a generative inversion model can reconstruct coherent whole sentences from a single sentence embedding, and follow-up studies have reproduced and extended the result.

92%of short texts reconstructed exactly from their embeddings alone

The consequence for a memory product is direct: a stolen vector index should be treated as close to stolen plaintext. So FocusLM's index stores the vector, the file path and a keyed fingerprint — and not the text of your notes. When a search matches, the snippet you read is fetched and decrypted from the encrypted store at that moment. The index knows where something relevant is; it does not know what it says.

An embedding is not an anonymised version of your text. It is a reversible one.

Removing the text is not the end of that argument, though, and it would be dishonest to present it as one. The vector itself is still there — it has to be, because the geometry between vectors is exactly what makes semantic search possible. Encrypting it the way we encrypt a note would leave nothing to search.

So the next step is to bind the vector space to the same per-project key that already protects the content: each project's vectors are held in a space only that project's key describes, which keeps search working unchanged while making the vectors unusable in the embedding model's own coordinates — where the published inversion attacks operate. That raises the cost of an attack rather than removing it, and we would rather say so than call it encryption. It is in progress, not shipped.

Deletion that survives the backup

"Delete" in most systems means a row is marked deleted. The data stays — in the table, in last night's dump, in the replica, in whatever retention the backups have. For a note about a child's illness, that is not deletion in any sense the person asking would recognise.

Because each project has its own key, we can do something stronger: deleting a project destroys that key. The ciphertext remains wherever it already sits, and none of it can be read again — not in the live database, not in a snapshot taken before the deletion. This is crypto-shredding, and it is the standard answer for erasure in systems where physically overwriting every copy is impractical or unverifiable, which is every distributed system with backups.

Recent work makes the case sharper for AI systems specifically. A 2026 study of vector databases found that embeddings which have merely been soft-deleted remain reconstructible from the index structure — the deletion is a flag, and the data is still there for anyone who reads the file rather than asking the query engine. Combined with embedding inversion, a soft delete in a vector store is not a delete at all.

Crypto-shredding is genuinely irreversible, which is the point and also the risk. Restoring a deleted project from a backup brings back rows nobody can read. FocusLM therefore asks you to type the project's name before it goes — the same friction that guards a destructive action anywhere else.

What is honestly still visible

Encryption claims are worth exactly as much as the exceptions they admit. Ours:

Structure is not content. Folder and file names in your memory are stored in the clear, because the system browses and globs over them. A path like health/oncology/… reveals a topic even though the note itself is unreadable.
A brief window on upload. A file goes from your browser straight to storage and is sealed by the worker that first picks it up — minutes at most, on a private bucket, but not zero.
Chat titles.A thread's title is stored in the clear so the sidebar can search it, and it is generated from your first message. The conversation is encrypted; the sentence that opened it is not.
File names.The name you uploaded travels in the storage key and in the operational log, even though the file's contents are sealed.
The search vectors, for now.Today they sit in the index in the embedding model's own space, which is the space the inversion research applies to. Binding them to the project key is the work described above.
Operational metadata. Which model ran, how long it took, what it cost. Not what was said.

A pattern runs through them: content is protected, names are not. Paths, titles and file names are what the system must read in order to organise and find things, so they stay legible. That is a real limit, it is the one we would want to be told about as a user, and it is the next thing to work on rather than a footnote to wave away.

Why this matters for a memory product in particular

A chat assistant that forgets you between sessions holds little worth stealing. A system built to accumulate the things you keep returning to — the structured memory that makes grounded answers possible — accumulates exactly the material that should never leak. The value of the memory and the sensitivity of the memory grow together; they are the same property seen from two sides.

That is the reason to spend the engineering on a key per project rather than a checkbox that says encrypted. The stronger the memory, the less acceptable the ordinary answer.

Sources