Why your AI note app isn't end-to-end encrypted
Reviews of note apps have a habit of flagging encryption in one sentence and moving on. Something like "it's also not fully encrypted, which raises quite a few data privacy concerns," and then straight back to the interface. It reads like a vendor cutting a corner.
It usually isn't. There is a specific architectural reason almost no AI note app is end-to-end encrypted, the vendors who explain it are describing a real constraint rather than making an excuse, and the ways around it are narrower than the marketing suggests. Worth knowing before you decide which app your client notes live in.
Quick answer: End-to-end encryption means the server cannot read your notes. A cloud AI model has to read your notes to summarize or search them. Those two things cannot both be true of the same request, so apps pick one. The note apps with real end-to-end encryption have no AI, and the ones with AI can read your content.
Why can't a cloud AI read encrypted notes?
Because the model needs the plaintext. Not a hash of it, not a token of it, the actual words. If the server holds a key that can turn your ciphertext back into readable notes, then by definition it is not end-to-end encrypted any more; end-to-end means the endpoints hold the keys and the middle does not.
The clearest statement of this comes from a company with every commercial reason to phrase it otherwise. Proton, whose entire brand is encryption, ships an AI assistant called Lumo, and its security model page explains exactly what happens to your message:
"The LLM server possesses the private counterpart of the PGP key the request was encrypted with, and thus can decrypt the AES key. Using this key, the LLM gets to see the decrypted user message and process it directly."
The model sees your text. Proton's protection is what happens around that moment rather than instead of it: the request is stateless, and "The user's cleartext message never leaves the server, and the request is not logged or retained by the LLM server after completing that request," with conversation history separately held under zero-access encryption. That is a real and meaningful design. It is not end-to-end encryption of the inference itself, and Proton does not pretend it is.
The obvious question is why nobody encrypts in a way the model can compute on directly. That is fully homomorphic encryption, and it exists, and it is far too slow. Proton's own explanation is that where a normal assistant answers in seconds, experiments with homomorphic encryption produced responses taking more than a day. The 2026 research literature puts the gap at roughly four orders of magnitude against plaintext inference. It works today for narrow things: private lookups, small models, low volumes. Nothing in the notes or knowledge-management space runs on it, and nothing is close.
Which note apps actually have end-to-end encryption?
Sorting the market this way produces a pattern that is hard to unsee.
Real end-to-end encryption, no AI. Standard Notes (now owned by Proton), Notesnook, and Cryptee all encrypt on the device before anything reaches a server, and none of them ship an AI assistant. That is not an oversight. It is the same decision, made three times. Worth noting because it would be the obvious objection: Proton's own AI assistant is a separate product, and there is no Standard Notes integration today, only a customer request for one.
End-to-end encryption with honest caveats. Obsidian Sync defaults to it, and Obsidian's security page says so directly: "End-to-end encryption (default) offers the strongest security but requires you to safely store your encryption password." It also publishes what the encryption does not cover, which more vendors should copy:
"Some metadata is not end-to-end encrypted: which device uploaded or deleted a file, when it was uploaded, and the mapping between encrypted file paths and encrypted content."
Anytype is encrypted by default too, and keeps its search index on your own machine rather than syncing it, so search does not require a server that can read you. Joplin supports end-to-end encryption but leaves it off until you turn it on, and its AI features come from community plugins, which means the moment a plugin ships your note to a cloud model, that note is outside the encryption for that request. Pointing the same plugin at a local Ollama model keeps it inside.
No end-to-end encryption at all. Notion and Evernote encrypt in transit and at rest with keys they control, which protects you against a stolen disk and not against the vendor. Both ship AI heavily. There is nothing to reconcile because there was never an end-to-end guarantee to break.
The closest thing to a counterexample. Reflect markets itself as end-to-end encrypted, with an independent security audit and XChaCha20-Poly1305, and it also ships an AI feature. Its security page explains how both are true at once: "The contents of your notes are end-to-end encrypted. This means that nobody else can see your notes," and, separately, text you select and run through the AI feature is sent to the model provider's servers. Reflect then states the tradeoff in a sentence more vendors should borrow: "There's always a user-experience tradeoff with security and this is where we've chosen to draw the line." That is the same carve-out Proton makes, drawn deliberately and disclosed. The encryption holds right up until you use the feature that has to read your notes, and then, for that content, it doesn't.
The pattern across all three groups: the apps that can read your notes are the apps that can do things with your notes. Capability and confidentiality are trading against each other, and every vendor has picked a point on that line whether or not they told you.
Don't Apple and Google solve this with secure enclaves?
Partly, and the distinction matters more than the marketing admits.
Apple's Private Cloud Compute is the most serious attempt. Its guarantees are specific and unusually falsifiable: "PCC deletes the user's data after fulfilling the request, and no user data is retained in any form after the response is returned," data "must not be retained, including via logging or for debugging," and "User data is never available to Apple — even to staff with administrative access to the production service or hardware." Apple publishes measurements of the code running in production to a tamper-proof transparency log so researchers can verify the software is what was inspected. In 2026 the same model was extended onto third-party hardware, with a requirement for independent roots of trust.
But read what it does not say. The compute node still decrypts your request; Apple's own description is that the Secure Enclave guarantees the decryption keys cannot be extracted or duplicated, not that decryption never happens. The model sees plaintext inside the boundary. The guarantee is about what is technically possible to do with that plaintext afterwards: no retention, no logging, no operator access, attestable code.
Google's Private AI Compute makes a structurally similar pitch with attestation and sealed hardware. Neither is end-to-end encryption. They are attestable trust rather than mathematical impossibility — you are trusting a hardware and software chain that has been designed to be inspectable, instead of trusting a promise. That is a real upgrade over "we won't look." It is a different category from "we can't."
The other thing to notice: this is an operating-system-platform capability. No note app builds it. A notes startup can call into Apple Intelligence, but it cannot ship its own Private Cloud Compute, which is why none of the apps above use confidential computing for their own AI features.
Which vendors admit the tradeoff?
Very few, which is why the ones that do deserve naming.
Capacities publishes a page titled after the thing it does not do. It states plainly that "At the moment your data is encrypted in transit and at rest on our servers," and then that on end-to-end encryption, "Capacities is not following this principle." It gives three reasons: that "Simple, user-friendly and powerful APIs would not be possible," that "AI assistance would be significantly harder to build," and that its existing integrations with WhatsApp, email, calendar and Readwise do not support end-to-end encryption on their side either.
You can disagree with the choice. It is hard to argue with the disclosure, and it is a more useful thing to read than a review sentence saying the app is "not fully encrypted" without saying that it is in fact encrypted at rest and in transit, and that what is missing is specifically the end-to-end property.
Proton, as above, is the other one. Between them they describe the entire tradeoff accurately, from opposite ends of the privacy market.
What can you actually do about it?
Three options, and they are genuinely different rather than three flavours of the same thing.
Accept server-side AI, and choose your vendor on what happens to the plaintext. This is where almost everyone lands. The questions worth asking are narrow and answerable: is my content used for training, how long is it retained, who are the AI subprocessors, and is any of that in writing. A vendor that answers all four is doing better than one that says "your data is private."
Take end-to-end encryption and give up the AI. Standard Notes, Notesnook and Cryptee are good products and this is a coherent choice, especially for a narrow set of genuinely sensitive notes. You are choosing a filing cabinet over an assistant, and for some material that is the right call.
Run the model locally. This is the only option that gets you both, because there is no server in the loop to need plaintext. The cost is real: you are limited to what your own hardware runs, which in 2026 is meaningfully behind frontier models for hard reasoning, though closer than most people assume for summarizing and tagging your own notes. Ollama and a local model is the practical setup, and it is the same escape hatch Joplin users reach for when they point an AI plugin at localhost.
Disclosure, since this is my product: Calmara is not end-to-end encrypted either, and that is a deliberate decision rather than a roadmap gap I am hiding. Full end-to-end encryption with server-side AI is an explicit non-goal, for the reason this whole article describes: it would break the AI features that are the point of the product. What exists instead is the third option, made a first-class mode. You can point the app at a local model and turn on a hard local-only setting that blocks any cloud fallback rather than silently degrading to one, and the request goes from your browser to your own machine without a server hop. Where cloud AI is used, it runs under your own provider key with structured identifiers redacted first, and the hosting, subprocessors and gaps are written down. Note-level end-to-end encryption for the knowledge store is on the backlog and honestly not near the top, precisely because it conflicts with the AI layer for everyone, not just for me.
FAQ
Is my note app encrypted if it isn't end-to-end encrypted?
Almost certainly yes, and the distinction is the point. Most reputable apps encrypt in transit (TLS) and at rest (encrypted disks). That protects you against interception and against someone walking off with a drive. End-to-end encryption additionally protects you against the vendor, because the vendor holds no key that can read your content.
Why can't an AI just work on encrypted text?
Fully homomorphic encryption allows computation on ciphertext, but for language-model inference it currently runs on the order of thousands of times slower than plaintext. Proton reports experiments producing responses that took more than a day. It is used today for narrow workloads, not interactive assistants.
Does Apple Private Cloud Compute make AI end-to-end encrypted?
No. It makes server-side AI attestable: no retention, no logging, no operator access, and code that researchers can verify. The compute node still decrypts your request so the model can process it. That is a stronger guarantee than ordinary cloud AI and a weaker one than end-to-end encryption.
Which note apps have real end-to-end encryption?
Standard Notes, Notesnook and Cryptee by default with no AI features; Obsidian Sync by default, with published metadata caveats; Anytype by default, keeping its search index local; Joplin if you switch it on. Notion and Evernote do not offer it.
If I turn on end-to-end encryption in Joplin, are my AI plugins still private?
Not for the content you send. Encryption protects your notes in sync and storage. If a plugin sends a note to a cloud model, that note is decrypted on your device and transmitted to that provider under their terms. Pointing the plugin at a local model avoids this.
Is a local model actually good enough?
For summarizing, tagging, extracting and searching your own notes, usually yes. For hard multi-step reasoning, frontier cloud models are still ahead. A reasonable pattern is local for anything touching client or personal material, cloud for general work.
What should I ask a vendor who has no end-to-end encryption?
Four things, in writing: is my content used to train models, how long is it retained, which AI subprocessors receive it, and can I use my own API key or a local model. Silence on any of them is itself an answer.
---
Before you move your notes anywhere, open the vendor's encryption page and look for two specific things: whether they say "end-to-end" or only "at rest and in transit," and whether they say anything at all about what their AI features do with your content. Capacities and Obsidian both publish enough to make the decision on. Most vendors publish neither, and that gap is the finding.
Written by Dan Hagen