What "zero-knowledge" means for a secrets manager, and 10 questions to ask any vendor
Short answer: a zero-knowledge secrets manager encrypts and decrypts on your side, with keys the vendor never receives, so its servers store only ciphertext. If the vendor, its database or its backups are compromised, your secret values and names stay unreadable. The price is real: the server can't process what it can't read, and if you lose your keys the vendor can't recover them. This page explains the architectures, gives you questions to ask any vendor (including us), and states where Dynv's own model has gaps.
“Zero-knowledge” is used loosely. In password managers it has a settled meaning; in developer secrets tools it is often claimed and rarely defined. We make Dynv, a zero-knowledge secrets manager, so read this with that in mind: the definition and the questions apply to us too, and we give our own answers at the end.
Three architectures
| Model | Who holds the keys that open your data | If the vendor’s database leaks | If the vendor’s servers are fully compromised |
|---|---|---|---|
| Server-side encryption | The vendor’s service decrypts on request | Ciphertext, with keys usually held elsewhere in the vendor’s infrastructure | Plausibly everything: the service can decrypt, so an attacker controlling it can too |
| Customer-managed keys (KMS/BYOK) | A key service you control, called by the vendor | Ciphertext | The vendor can still decrypt while your key service grants access; revoking the key stops it |
| Client-side (zero-knowledge) | Only your clients | Ciphertext and metadata | Ciphertext and metadata; the attacker can deny service or withhold updates but cannot read values |
Server-side encryption is not “bad”. It is a legitimate design with real benefits (the service can search, rotate against providers, sync to platforms and show values in the UI without your client). It simply means you are trusting the operator and its infrastructure. As one example, Infisical’s published security overview says its server “securely retrieves and decrypts requested data from the storage backend” before responding, which describes a trusted-server model (Infisical security overview); the page does not use the phrase “zero-knowledge” and we do not claim they do. Bitwarden’s product page, by contrast, lists “zero-knowledge encryption” among its core features (Bitwarden).
What a zero-knowledge server still knows
Zero-knowledge describes the content, not everything. Be suspicious of any vendor that doesn’t tell you what remains visible. For Dynv, from our security page:
- A database or backup leak reveals ids, counts, timestamps, padded sizes, token verifiers, the public signing key, audit IPs and keyed email hashes, but not any name, value or service name.
- The operator can see metadata: which token fetched when, from which IP. It can deny service, withhold updates, or serve a stale but validly signed version to a process that has never seen a newer one. It cannot forge or modify a document (signatures), swap documents between services or accounts, or roll a client back below the newest version it has seen.
- Vulnerability findings are sealed too: the server sees severity counts, not package names (monitoring docs).
The costs of zero-knowledge
- Lose the keys, lose the data. Dynv hands you a recovery kit at sign-up and says “We cannot recover it, or your data, if you lose it and every passkey. That is what zero-knowledge costs.”
- The server can’t compute on values. Anything that needs plaintext (syncing to a platform, calling a provider’s API to rotate a password) has to run on your machines or in your CI, not on the vendor’s servers. That is why Dynv rotation runs from the CLI with a keyholder.
- Browser-delivered apps have a ceiling. The dashboard is JavaScript the server sends you and it handles your keys, so a malicious or compromised server could serve different code. Dynv’s page says it plainly: the guarantee against an actively malicious server holds for the CLI and the local MCP server, while the hosted dashboard protects against database leaks, backups, logs and a curious operator, not an operator who tampers with the code. No cryptography prevents that for any web-delivered encrypted app.
- Freshness isn’t guaranteed. A server can withhold updates; “trust on first use” applies to a process that has never seen a newer version, unless it keeps a cache.
- It does not protect a compromised endpoint. Anything that runs as you, on a machine that holds keys or plaintext, can read them.
Ten questions to ask any secrets vendor
- Can your servers decrypt my values? In what situations, and with what keys?
- Can you read my variable and service names? Names alone describe your infrastructure.
- What does a full database dump reveal? Ask for the list (counts, timestamps, IPs, sizes).
- What can your operator or a compromised server do? Deny service? Serve old data? Forge or swap data?
- How are documents authenticated? Signed by whom, with whose key, and who checks it?
- Where does decryption happen for each client (CLI, SDK, dashboard, agent integration)? Is any of it JavaScript you serve?
- What happens if I lose my keys? Is there a recovery path that doesn’t involve you reading my data?
- Which features need plaintext on your servers (rotation hooks, syncs, search, AI features) and how are they run?
- What do your logs, alerts and email contain? Do alerts leak names or values?
- What has been independently reviewed or tested, and what hasn’t?
How Dynv answers
- No: names and values are encrypted on your machine with keys derived from tokens the server never receives (AES-256-GCM, HKDF-SHA256, SHA-256, Ed25519 per the docs).
- No names or values, and no service names; only opaque ids.
- The list above. Dynv’s tests dump every collection and search for every name, value, email, code and token in several encodings.
- Deny service, withhold updates, serve a stale-but-valid version once to a process with no cache, see metadata. Not forge, swap or roll back.
- Each document is signed with a key only the account’s writer holds; services verify.
- The CLI, SDKs and local MCP server decrypt locally. The dashboard is served JavaScript: see the caveat above.
- No recovery. The recovery kit is yours.
- Plaintext-needing work runs on your machines; the server never sees plaintext.
- Alerts carry counts and a link, never names or package names (why).
- We run our own zero-knowledge tests; we are not claiming an external audit here, and you should ask for current reports from any vendor, including us.
Known gaps from our own security page: a single writer by design; invited members are viewers who can read every secret in the account, because their keys open all of it (teams are opt-in and give roles per workspace; per-service grants are planned, not built); account-root rotation is not built yet; and metadata is visible to us. We would rather you know that before you choose.
When it matters, and when it doesn’t
It matters most if you want the vendor’s breach, an insider, a subpoena of the vendor or a rogue operator not to be a path to your secrets. It matters less if your threat model is mostly “someone steals our laptop” or if you need server-side features that require plaintext. Pick the model that fits the threat, then verify the claims with the questions above.
Facts last verified . Spotted an error? Tell us.