wundervault/wundervault-mcp

**A zero-knowledge secrets vault for AI agents.** Every API key you paste into an agent chat or a .env file ends up in context windows, transcripts, and provider logs. Wundervault's answer: the agent never receives the secret at all. It asks for *work* — "run this deploy with the key injected" — and a local daemon decrypts the secret, injects it into the subprocess environment, zeroes the buffer, and scrubs the output before the agent sees any of it.
This repo is the MCP server that exposes that workflow to any Model Context Protocol client — Claude Code, Cursor, Cline, and others.
**Don't trust the claim — test it:** the zero-knowledge property is independently verifiable at your own network boundary in about 5 minutes (browser DevTools or a mitmproxy canary test). Guide + our own test transcript: wundervault.com/verify.
How it works
Secrets are encrypted client-side (AES-256-GCM via Web Crypto) before upload. The hosted service only ever stores ciphertext — it cannot derive the key, the passphrase, or the plaintext.
Install
Quick Start
Keys are never placed in the MCP config. The server names its agent, then asks the
local wundervault-agent daemon for that agent's credentials over a unix socket.
onboard.py registers the agent and starts the daemon.
New account? wundervault.com has a 90-second agent onboarding flow that generates this config for you.
Supported platforms
**Linux is the verified platform.** macOS works for secret delivery; Windows does not.
Delivery is POSIX-only by construction: the sudo recipe pipes through /bin/sh, and
the git / ssh-passphrase recipes need mkfifo and setsid. On Windows those
mechanisms return a clear "not supported" error rather than failing somewhere deep
inside.
The single-instance lock has two implementations: a kernel-held abstract socket on
Linux, and loopback ports elsewhere. Only the Linux one is covered by tests — see
HANDOFF-lock-on-non-linux.md for what is unverified on macOS and why. CI runs both
platforms; the lock suite runs on Linux.
Security Model
- **Zero-knowledge:** The encryption key lives only in the MCP server process. The Wundervault server never sees it.
- **Burn-after-reading:** Plaintext secrets are never returned to the calling agent. After decryption, the agent receives only "Secret retrieved and burned.".
- **Exec scrubbing:** Command stdout/stderr are scrubbed of the plaintext before being returned; shell-escape patterns ($(), backticks, sh -c, eval) and file redirects of secrets are rejected *before* decryption.
- **Directive integrity:** Server-side directive signatures (PBKDF2-HMAC-SHA256, 600k iterations) are verified before any secret is released.
- **Timing-safe:** HMAC comparison uses crypto.timingSafeEqual.
- **Tiered access:** Per-entry access tiers are enforced server-side; high-tier secrets require human approval before an agent can use them.
Honest limitations
- The platform is **open-core**: this MCP server and the browser crypto are AGPL-3.0 so you can audit everything that touches your secrets, but the hosted service itself is not open source.