Your documents are sealed on your device and stay sealed in the cloud. Here is the whole path — including the one step where a document is readable.
The journey of one document
Your documents exist as plaintext in two places only: on your own devices, and for the length of a single analysis call.
Who holds the keys
What the server can see
Encrypted
The document itself. Its filename, summary, labels, dates and embeddings — every one of them rides inside the ciphertext.
Visible
Routing metadata: which library a record belongs to, its id and version, which device wrote it and when, and how large the blob is. Two things are not encrypted at all: the name you give a library, and a fingerprint of each file’s contents.
Every record is sealed before it leaves the device, and the server has no key to open it.
We say “encrypted”, not “invisible” — a log of when and from where is still a log.
The fingerprint is how your devices recognise the same file twice and store it once. Someone already holding an identical copy of a file — including a publicly available one — could use it to confirm that file is in your library; it reveals nothing about a document to anyone who doesn’t already have an identical copy.
When it’s readable, and to whom
To describe a document, a model has to read it. That is unavoidable, and it is the one time the document itself leaves your device unsealed. It happens when a document is filed, when it is indexed for search by meaning, and when you ask a question — the first two without your asking, and those are the common cases rather than a complete list.
Without a key of your own, the request goes out under a key we issue, and carries a zero-data-retention flag — it may only be served by endpoints that do not keep what they are sent.
With your own key, the terms are the ones you accepted with Gemini or Claude directly, and they differ by plan: Google’s paid tier does not train on what you send it, its free tier does. For paperwork you care about, use a paid key.
The copy goes straight from your device to the model provider — it never passes through Enqlave’s servers, and we keep no copy.
What comes back — summary, labels, embeddings — is encrypted on your device before it is stored.
A second, smaller exception is off by default: turn on place lookup and the place names our AI found in your documents — addresses, employers, clinics, schools — go to Apple to be turned into map coordinates. The switch is in Enqlave’s settings. The documents themselves never go.
Search never leaves home
Every client decrypts locally. The index lives on your device, not on a server.
Keyword search runs entirely on the machine in your hands — nothing is sent anywhere.
Search by meaning sends your search text, never your documents, to be turned into a vector; the comparison against your library then happens on your device.
When you ask a full question, a short, summarized slice of the relevant documents goes out as well, so the model can compose an answer.
Where this is going
As laptops and phones get faster, more of this work moves on-device — and the one readable moment shrinks toward zero.
Today Enqlave uses frontier models because they give you materially better answers, and we would rather be honest about that
trade than ship a worse product and call it privacy.