@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_VAULT_URL": "https://wundervault.com",
        "WUNDERVault_AGENT_VAULT_API_KEY": "wv_agent_<AGENT_ID>|<KEY_SUFFIX>",
        "WUNDERVault_AGENT_KEY": "<BASE64_ENCRYPTION_KEY>"
      }
    }
  }
}

Or using a credentials file:

wundervault-mcp --credentials ~/.wundervault/creds.json

New account? wundervault.com has a 90-second agent onboarding flow that generates this config for you.

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

... View full README on GitHub