Selective encryption is the practice of encrypting only the genuinely sensitive notes inside a vault, rather than encrypting (or segregating) everything. It treats the privacy boundary as a per-note property rather than a vault-wide one. The pattern is articulated most clearly by Dries Buytaert, who runs his thinking environment public-by-default with an "Encrypt – Encrypts specific notes with password protection" workflow for "sensitive information that I want in my knowledge base but need to keep secure."
The Argument for Per-Note Encryption
A vault-wide encryption posture (everything encrypted at rest) defends well against breach but pays high discoverability costs. Search, semantic similarity, and AI integration all degrade or require the user to enter a password each session. Hard segregation (separate vaults) defends well but makes cross-domain connections invisible — the most valuable PKM property.
Selective encryption keeps the unsensitive majority of the vault in clear plain text where Bidirectional Linking, RAG for Personal Knowledge, and Serendipity Machine all work normally. Encryption applies only to the small subset of notes whose exposure would be costly. This pays a much smaller discoverability tax: encrypted notes do not surface in search or AI context, but everything else does.
What Belongs Behind the Lock
The candidate set is narrow but stable across users:
- Account credentials and recovery codes that have escaped a password manager into a note
- Health and medical detail beyond what is comfortable to expose in journal entries
- Personal finance specifics (account balances, stock positions, plans)
- Confidential professional content under NDA or legal hold
- Notes about other people that contain attributable observations the user would not want them to read
- Drafts of decisions or letters that are mid-deliberation and would be misread out of context
What does not belong behind the lock: most of the vault. Topic notes, public-leaning drafts, reading highlights, daily notes without sensitive entries, project documentation. The default is plain text; the lock is the exception.
Implementation Patterns
Several patterns coexist:
- Plugin-level encryption (Obsidian Encrypt, Meld Encrypt). Per-note password or vault-wide passphrase. Notes appear in the file tree but their content is unreadable without decryption. Best for low-friction selective use.
- Filesystem-level encryption (Cryptomator, age, gpg). Encrypted at the file level using standard tools. Survives plugin churn. Higher friction (decrypt before read).
- Folder-level encryption (encrypted volume mounted on demand). One encrypted folder inside the vault for sensitive notes. Simple mental model, but the folder boundary is rigid.
- Inline encrypted blocks. Encryption applied to specific blocks within an otherwise plaintext note. Useful when most of a note is general but a section is sensitive (e.g., a meeting note where one paragraph names a person).
The right choice depends on threat model and tolerance for friction. A plugin approach is enough for casual sensitivity; a filesystem approach is needed for serious threat models.
Tradeoffs
Selective encryption is not free:
- AI agents cannot reach encrypted content, by design. Smart Connections, copilots, and RAG pipelines all see plaintext only. This is the privacy benefit but also the discoverability cost.
- Encrypted notes are invisible to backlink graphs. They cannot participate in Knowledge Graphs visualizations.
- The encryption boundary requires maintenance. A note that becomes sensitive over time (e.g., contains a person's evolving private detail) needs to be moved into the encrypted set. Nothing automates this — it requires capture discipline.
- Plugin lock-in. Encrypted-via-plugin notes may be unreadable if the plugin is abandoned. Filesystem-level approaches mitigate this but do not eliminate it (cipher tools can also become legacy).
- Loss of password = loss of data. The most common selective-encryption failure mode is forgotten passwords. The vault has no recovery path.
The Default-Public Posture
Selective encryption is the natural complement of Buytaert's "if a note can be public, it should be" stance. The two together form a coherent posture: most knowledge benefits from being public (or at least shareable); the small remainder benefits from being locked. This rejects both extremes — keeping everything private (loses Public Learning benefits) and publishing everything (creates exposure on the inevitable sensitive items).
The posture is not for everyone. Users in heavily regulated professions or politically sensitive contexts may need to invert it — default-private with selective publishing — but the architectural shape is the same: a per-note privacy decision.
Key Points
- Selective encryption applies the lock per-note, not vault-wide
- The candidate set is small and stable: credentials, health, finance, NDA, attributable observations, mid-decisions
- Implementation options range from plugins (low friction) to filesystem encryption (durable) to folder volumes (simple)
- AI agents cannot reach encrypted content — this is the design, and the tradeoff
- Pairs naturally with a default-public posture (Buytaert pattern)
- Failure modes: password loss, plugin abandonment, drift in what counts as sensitive
Open Questions
- Can AI agents safely operate over encrypted notes via local-only inference with explicit unlock per session?
- Should encryption boundaries be tagged or computed (e.g., automatic detection of sensitive content)?
- What is the right backup strategy for encrypted notes — encrypt the backups separately, or rely on the in-place encryption?
- Is there a clean pattern for time-based encryption (notes lock automatically after N years)?
References
- Buytaert, "How I Collect and Connect Ideas" (dri.es, 2026) — Readwise capture
- Obsidian Encrypt plugin, Meld Encrypt plugin
- Cryptomator (cryptomator.org)
- age (age-encryption.org)