CLIENT.ENCRYPTED SERVER.BLIND AGENT.NATIVE
v0.22.10-63d4b41-3f8ecb43
// AGENT-NATIVE SECRETS
▸ @wundervault/mcp-server · v1.6.8 · AGPL-3.0

The MCP secret vault

Wundervault's MCP server gives AI agents a zero-knowledge secret vault over the Model Context Protocol. Your agent can run deploys, call APIs, and rsync over SSH with real credentials — and the plaintext never enters the chat, the model context, or our server. Secrets are encrypted client-side with AES-256-GCM and injected into a subprocess or env file by a local daemon at the moment of use.

Install

npm install -g @wundervault/mcp-server

In practice you rarely run even that: create a free account, register an agent on the dashboard, and it hands you one command your agent runs to set everything up itself — install, local daemon, credentials, config. The quickstart walks through it in under 5 minutes.

Claude Code

claude mcp add wundervault \
  -e WUNDERVAULT_AGENT_NAME=<YourAgentName> \
  -- wundervault-mcp

Cursor

Add to ~/.cursor/mcp.json (all projects) or .cursor/mcp.json in a project:

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

The agent's auth token is auto-discovered from ~/.wundervault/agents/<name>.token — don't put it in the config file. Cline and other MCP clients use the same command: wundervault-mcp shape; agents can follow llms-install.md unattended.

The 6 tools

  1. vault_entries_list — list the entries this agent may use. Names and IDs only, never values.
  2. vault_entry_get — retrieve a secret for a stated purpose. The plaintext is processed locally and burned; the agent receives only a confirmation.
  3. vault_entry_inject_env — write a secret straight into a .env file. The value never passes through the model.
  4. vault_exec — run a shell command with the secret injected as an env var; output is scrubbed and shell-escape patterns are rejected before decryption.
  5. vault_rsync — rsync over SSH with a vaulted private key that never touches the agent's context.
  6. vault_entry_forget — drop a stale local reference (server unaffected).

Every retrieval is written to a tamper-evident, HMAC-chained audit log you can review in the dashboard, and access is scoped per agent with immediate revocation.

Don't take the zero-knowledge claim on faith. A secret vault vendor saying "trust us" is exactly what you should be skeptical of. The verify page shows how to check the claim yourself in about 5 minutes — browser DevTools first, then a mitmproxy canary test at your own network boundary — including the full transcript of the test run against this production site.

Try it with no account

Set WUNDERVAULT_MOCK=1 in the server's environment and all 6 tools return clearly-labelled [DEMO MODE] canned responses — no signup, no daemon, no real secrets. Useful for evaluating the tool surface before committing.

Where it's listed

Official MCP Registry · Smithery · Glama · npm · GitHub · Awesome MCP Servers · ClawHub

The client code is open for audit: wundervault-mcp and wundervault-crypto, both AGPL-3.0.

FAQ

What is an MCP secret vault?

A secret vault an AI agent can use through the Model Context Protocol — the open standard for connecting agents to tools. Instead of pasting API keys into a chat or a .env file the agent can read, the agent gets MCP tools that use secrets on its behalf: run a command with the key injected, write it into an env file, rsync with an SSH key. The agent gets the outcome, never the value.

How can an agent use a secret without seeing it?

The decryption happens in a local daemon, outside the model. When the agent calls vault_exec, the daemon decrypts the secret, injects it into the subprocess environment, zeroes the buffer, and scrubs the output before it returns to the agent. The plaintext exists briefly in a local process — never in the agent's context window, the chat transcript, or Wundervault's server.

Does the Wundervault server ever see my secrets?

No — secrets are encrypted in your browser with AES-256-GCM before upload, and the server stores only ciphertext it cannot open. You don't have to take that on faith: the verify page shows how to confirm it at your own network boundary in about 5 minutes, with the transcript of our own mitmproxy test against this production site.

Which agents and MCP clients work with it?

Claude Code, Cursor, Cline, OpenClaw, and any MCP-compatible client — the server speaks standard MCP over stdio. Agents can even install it unattended from llms-install.md.

What if my agent gets prompt-injected?

The blast radius is bounded by design: the agent never holds plaintext it could leak, each agent sees only the entries you granted it, shell-escape patterns in vault_exec are rejected before decryption, writing secrets to arbitrary files is blocked, every retrieval lands in a tamper-evident audit log, and access is revocable per agent, immediately.

What does it cost?

The vault and MCP server are free to use; the client code is open source (AGPL-3.0). Paid team features come later — the product is in its prove-it phase, which is why the verification guide exists.

Deciding how to handle agent credentials in general? See .env files vs. secret managers vs. a zero-knowledge vault.