Zero-knowledge guarantee
“Zero-knowledge” is an overloaded term in security. Here’s exactly what it means for OpaqueVault.
What we guarantee
Section titled “What we guarantee”The OpaqueVault server cannot decrypt your secrets.
This is not a policy statement — it’s an architectural constraint. The server stores only ciphertext. It has no master password, no KEK, and no decrypt endpoint. Even if OpaqueVault staff wanted to read your secrets, they couldn’t.
AI models cannot see your secret values.
The 8 MCP tools are designed so no plaintext value ever appears in a tool response. The interceptor enforces this at the transport layer as a second line of defense.
What we do NOT guarantee
Section titled “What we do NOT guarantee”We do not guarantee:
- Protection from malware on your local machine (anything with access to
ov mcp serve’s memory could read the KEK) - Protection from a compromised master password (your password is the root of trust — protect it)
- Protection from a subprocess that deliberately smuggles secrets out through side channels (since v0.16.0
vault_runreturns no stdout/stderr at all — output goes to the daemon terminal / agent log — but a subprocess you inject secrets into can still encode them into exit codes, files, or network calls; treat the subprocess as trusted with the secrets you grant it) - Full metadata privacy. Secret names are encrypted and indexed by an HMAC lookup token — the server has no plaintext name column. But app and environment slugs are stored in plaintext, and access patterns (how many secrets exist, which one was read and when) remain visible to the server
- Privacy of the audit log from the server. Audit references are HMAC’d with a server-side key, so the hashing protects a leaked log — not your activity from OpaqueVault itself
The root of trust
Section titled “The root of trust”Your master password is the root of trust. Everything derives from it via Argon2id. OpaqueVault never sees it, never stores it, and never transmits it. If you lose it, there is no recovery path — OpaqueVault cannot decrypt your secrets for you.
Keep a secure backup of your master password. A password manager (ironic, but correct) or a passphrase written down in a physically secure location.
Verifiability
Section titled “Verifiability”OpaqueVault is source-available under the Business Source License 1.1, which converts to Apache 2.0 in 2030. BSL 1.1 is not an OSI-approved open-source license, and the repository is not public today — so independent source audit is a commitment we intend to honour, not something you can act on right now. We would rather say that plainly than invite you to read code you cannot reach.
What does not depend on source access is the shape of the guarantee:
- The API exposes no decrypt endpoint. No documented route accepts a KEK, returns a KEK, or returns a plaintext secret value — the request and response bodies carry ciphertext and wrapped DEKs only.
- Decryption happens exclusively in
ov mcp serve, on your machine, using a KEK derived locally from your master password. - The server never receives your master password or your KEK.
The strength of the claim rests on that key hierarchy rather than on inspection. A server that never receives your KEK cannot decrypt your data, whatever its source code says — and conversely, reading the source would not protect you against a server running different code. Architecture is the durable guarantee; auditability is a check on it.