Key custody, explained: who holds the keys to your workspace?
Every encrypted workspace has keys. The question is who holds them. Here's why key custody is the most important detail in any encryption claim.
Every encrypted system has keys. The keys are what turn ciphertext back into readable content. The question that determines what a vendor can actually see is: who holds those keys?
There are three patterns, and most workspace tools use the first.
Pattern 1: vendor holds the keys
This is the default for Slack, Notion, Gmail, Drive, Dropbox, OneDrive, Teams. Data is encrypted at rest (so the database file itself is encrypted) and in transit (TLS), but the encryption keys live on the vendor's infrastructure. The vendor can read everything; their team can; their AI features can.
This isn't a flaw — it's the trade-off that makes server-side search, AI grounding, and customer support possible. But it means the vendor's privacy promise is a policy promise, not a property of the data.
Pattern 2: customer-managed keys (KMS)
Google Workspace Client-Side Encryption and Microsoft 365 Customer Key let enterprises run their own KMS and hold the keys themselves. This works — but it requires Enterprise Plus or E5 licensing, an engineering team, and a KMS deployment. It's also limited to specific surfaces (parts of Drive, some Gmail flows; specific O365 services).
For a small business or solo professional, this is procurement and engineering overhead measured in months.
Pattern 3: user-held keys (Koaich's model)
Each device generates its own keypair on first launch. The private key never leaves the device. Vault keys are wrapped to each member's device public key. The vendor (us) holds ciphertext and operational metadata. We don't have a copy of any key that could decrypt your content.
Trade-off: we can't recover for you (see Shamir-split recovery instead). Benefit: there's no key for us to lose, leak, or be compelled to surrender.