Wundervault MCP server

@wundervault/mcp-server

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

┌──────────────┐  MCP (stdio)  ┌───────────────────┐  ciphertext only  ┌───────────────────┐
│   AI agent   │──────────────▶│  wundervault-mcp  │◀─────────────────▶│  wundervault.com  │
│ (Claude, …)  │◀──────────────│  + local daemon   │                   │ stores encrypted  │
└──────────────┘ "burned" ack  │  decrypts HERE    │                   │ blobs, no keys    │
                               └─────────┬─────────┘                   └───────────────────┘
                                         │  secret → subprocess env
                                         │  (buffer zeroed after spawn)
                                         ▼
                               ┌───────────────────┐
                               │   your command    │ stdout/stderr scrubbed
                               │ (deploy, API, …)  │ before the agent sees it
                               └───────────────────┘

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

npm install -g @wundervault/mcp-server

Quick Start

{
  "mcpServers": {
    "wundervault": {
      "command": "wundervault-mcp",
      "env": {
        "WUNDERVAULT_AGENT_NAME": "<agent-name>"
      }
    }
  }
}

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

Shortened. The full README is on GitHub.