Most notes belong in search. A meeting note from last Tuesday is more useful when you can find it again. But a handful — incident postmortems, board minutes, salary discussions, the password recovery codes you keep telling yourself you'll move to a real password manager — should never come back in a search result, and should definitely not end up in an AI assistant's context.
Encrypted notes are a per-note opt-in. Tick a box at creation, and that note's body is stored as AES-256-GCM ciphertext at rest, excluded from keyword search, and never sent to any AI feature. Everything else stays the same.
What "encrypted" actually means here
The body of an encrypted note is encrypted with AES-256-GCM before it touches the database. The key lives outside the database — in production, in AWS SSM SecureString, decrypted via a KMS-managed key that only the running app instance can use. A database backup leaking on its own is a pile of ciphertext. The same vault already protects user emails, OAuth tokens, and other personally-identifying fields; encrypted notes plug into it.
Each write uses a fresh initialization vector, so the ciphertext is non-deterministic — which is exactly the point, but also the reason these notes can't be indexed. There is no "find by content" path that doesn't require decrypting every row, and that's a feature.
Excluded from search
The global search bar searches plaintext notes by title and body. Encrypted notes are filtered out at the query level — they don't appear in results even if their title would match. If you typed it into an encrypted note, you wanted it gone from search. We respect that.
Excluded from AI features
Plaintext notes are queued for embedding generation, which sends the title and body to a third-party embedding provider so the AI assistant can do semantic search across your data. Encrypted notes never enter that queue. The text is never extracted, never serialized, never sent. The MCP semantic-search tool can't surface them either — they're invisible to the entire AI surface.
This means the AI assistant won't be able to answer questions about your encrypted notes. That's the trade. If you want it answerable by AI, don't encrypt it. If you don't, encrypt it.
The flag is set once
Encryption is a creation-time decision. You cannot toggle a plaintext note to encrypted later, and you cannot decrypt an encrypted note back to plaintext. Why: the moment a note has been written in plaintext, it has potentially been embedded, indexed, logged, and backed up. Flipping the flag later doesn't unring those bells. Forcing the choice up-front keeps the security boundary honest.
If you change your mind, the answer is to copy the contents into a new note with the right setting and delete the old one. Friction here is intentional.
What still works
Titles stay plaintext. The note appears in your notes list, sorts by date, and shows up under the project, contact, or deal it's attached to. You can edit the body in the rich text editor exactly like any other note — decryption happens on read, encryption happens on save, transparently. Private (only-visible-to-you) and Encrypted are separate flags that compose: a private encrypted note is exactly what it sounds like.
When to use it
Use it for the things you'd be uncomfortable with a colleague stumbling onto via search, or with an AI assistant referencing in a summary: confidential incident reports, sensitive client briefings, internal HR notes, recovery codes, anything that has a regulatory or contractual reason not to be machine-readable. For everything else, stick with plaintext — searchable, AI-aware notes are more useful most of the time.
Open any note form, tick "Encrypted note", and the rest takes care of itself.