Wundervault MCP
About
MCP server for Wundervault zero-knowledge secret management. Exposes vault secrets to AI agents via the Model Context Protocol — secrets are decrypted server-side and never returned to the agent in plaintext.
Details
- Author
- wundervault
- Downloads
- 297
- Categories
- Cloud Service, Security, Infrastructure, Developer Tools
Jump to
- Zero-knowledge encryption key lives only in the MCP process.
- Burn-after-reading: plaintext secrets are never returned to the calling agent.
- Exec scrubbing: stdout/stderr are stripped of plaintext when using exec.
- Directive integrity verified via PBKDF2-HMAC-SHA256 with 600k iterations.
- Timing-safe HMAC comparison using crypto.timingSafeEqual.
Setting up with Highlight
This MCP is not yet compatible with Highlight’s one-click setup. However, you can still use it with Highlight by following these steps:
- Download and install Highlight from highlightai.com/download
- Navigate to the plugins tab and select "Add Custom Plugin"
-
Configure the plugin with the settings below
Plugin Name
Wundervault MCPCommand (node, npx, python, etc.)Please refer to the README for specific instructions on how to obtain API keys or other required environment variables.
- Enable "Start Automatically" if you want the plugin to start when Highlight launches
From the repository
Clone the repository, run npm install and npm run build, then configure credentials via CLI flags (--api-key, --enc-key, --url), environment variables, or a credentials JSON file. Use the provided MCP tools (vault_entries_list, vault_entry_get, vault_entry_forget) to list, retrieve, and discard secret references. The vault_entry_get tool supports an optional exec parameter to run a shell command with the decrypted secret; the plaintext is never returned to the agent.
Claude Desktop / Cursor
Paste into your MCP client config file to install this server.
{
"mcpServers": {
"wundervault mcp": {
"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>"
}
}
}
}
}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>"
}
}
}A zero-knowledge secrets vault for AI agents.Every API key you paste into an agent chat or a.envfile ends up in context windows, transcripts, and provider logs. Wundervault's answer: the agent never receives the secret at all. It asks forwork— "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 anyModel Context Protocolclient — 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.
┌──────────────┐ 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.
{ "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>" } } } }
wundervault-mcp --credentials ~/.wundervault/creds.json
New account?wundervault.comhas a 90-second agent onboarding flow that generates this config for you.
- 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 rejectedbeforedecryption.
- Directive integrity:Server-side directive signatures (PBKDF2-HMAC-SHA256, 600k iterations) are verified before any secret is released.
- Timing-safe:HMAC comparison usescrypto.timingSafeEqual.
- Tiered access:Per-entry access tiers are enforced server-side; high-tier secrets require human approval before an agent can use them.
- The platform isopen-core: this MCP server and thebrowser cryptoare AGPL-3.0 so you can audit everything that touches your secrets, but the hosted service itself is not open source.
- A local daemon must run next to the agent; fully air-gapped setups don't fit.
- By design the agent can never read a secret's value — if your workflow needs the model toreason aboutthe secret itself, this is the wrong shape.
List all vault entries available to this agent. Returns entry IDs and secret names — no values.
Input: {} Output: "Vault entries (N):\n [entry_id] secret_name (tier: read)"
Retrieve and decrypt a vault secret. Optionally execute a command with it.
Input: entry_id: string # from vault_entries_list purpose: string # audit log reason exec?: string # optional shell command Output: "Secret retrieved and burned." (plaintext NEVER returned)
sudo -S systemctl restart nginx <<< "$WUNDERVault_SECRET"
Do NOT useecho $WUNDERVault_SECRET | sudo -S— that exposes the secret in process logs.
Execute a shell command with a vault secret injected as an env var — locally or on a remote host over SSH. The secret is injected into the subprocess and the buffer is zeroed immediately after spawn; escape patterns are rejected before decryption.
Input: purpose: string # audit log reason command: string # full shell command (no escape patterns) entry_id?: string # secret to inject (omit for SSH-key-only remote exec) working_dir?: string inject_as?: { env_key, pre_command?, post_command? } # override entry's exec_config remote_host?: { host, user, ssh_key_entry_id? | ssh_key? }
Withremote_host.ssh_key_entry_id, the SSH key is fetched from the vault and used without ever being written to disk.
Write a vault secret directly into a config file (~/.npmrc,~/.netrc,~/.docker/config.json, or a project.env) without the plaintext passing through the agent.
Input: entry_id: string purpose: string file_path: string # allowed config file paths only env_key: string # variable name to set
Sync a local directory to a remote host using rsync over SSH, with the SSH key fetched from the vault (temp keyfile deleted immediately after transfer).
Discard a local reference. No-op on the server.
Input: { entry_id: string } Output: "Reference [id] discarded from local context."
- CLI flags (--api-key,--enc-key,--url)
- Environment variables (WUNDERVault_AGENT_VAULT_API_KEY,WUNDERVault_AGENT_KEY,WUNDERVault_AGENT_VAULT_URL)
- WUNDERVault_CREDENTIALS_FILEenv var (explicit path)
- ~/.wundervault/creds.json
- ~/.config/wundervault/credentials(XDG)
{ "agent_vault_url": "https://wundervault.com", "agent_vault_api_key": "wv_agent_<ID>|<SUFFIX>", "agent_encryption_key": "<BASE64_URL_SAFE_32_BYTES>" }
wundervault-mcp [options] --api-key <key> Agent API key --enc-key <key> Encryption key (base64 URL-safe) --url <url> API base URL (default: https://wundervault.com) --credentials <f> Path to credentials JSON file --help Show help
Anx402payment is just a signature, and a wallet key is a vault secret like any other. Store the key attier 2, have the agent sign the payment payload throughvault_exec, and the key is injected into a local signing subprocess — it never enters the model context, and every use needs the owner's approval first (the agent's denied call carries a request id; approval is scoped to that agent + secret, once or for a 15/60-minute window). We ran this end-to-end on Base Sepolia — the verified run is written up atwundervault.com/agent-wallets. Payment-specific policy (spend caps, payee allowlists) is not built yet: compatible, not productized.
SetWUNDERVAULT_MOCK=1to run the serverwithoutawundervault-agentdaemon or any credentials. In this mode every tool call returns a representative response clearly labelled[DEMO MODE]instead of contacting the vault —no real secret is ever involved. This exists so you can poke at the tool surface without an account, and so MCP directory scanners and CI (e.g.Glama) can start the server, exercise each tool, and validate the build with no live vault. It isoff by defaultand is never enabled in production.
"env": { "WUNDERVAULT_MOCK": "1" } // demo/CI only — returns fake, labelled output
git clone https://github.com/wundervault/wundervault-mcp.git cd wundervault-mcp npm install npm run build # compiles TypeScript to dist/ npm test # run the test suite
Licensed under theGNU Affero General Public License v3.0 or later(AGPL-3.0-or-later). SeeLICENSE.
Wundervault isopen-core: this MCP server and the client are open source; the hosted service atwundervault.comis a commercial offering. For commercial or hosting inquiries, get in touch viawundervault.com/contact.
AISG MCP Gateway — a security & DLP proxy for the Model Context Protocol. Aggregates your MCP servers behind one endpoint and enforces policy on every tool call
Securely access secrets from Doppler's secret management platform using a Doppler API token.
Manage secrets and environment variables with Infisical's official MCP server.
All-in-one website diagnostics: DNS, SSL certs, HTTP headers, security audit (A-F grade), WHOIS, tech stack detection. No API keys needed.
AI-safe secrets manager - inject credentials as env vars, AI never sees plaintext
Cost tracking + security scanning for AI builders
This AWS Labs Model Context Protocol (MCP) server for CloudTrail enables your AI agents to query AWS account activity for security investigations, compliance auditing, and operational troubleshooting.
Analyze CDK projects to identify AWS services used and get pricing information from AWS pricing webpages and API.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Deploy and operate workloads, secrets, and networking across AWS, GCP, Azure, and private clouds.
Sign in to leave a review
Use Google, GitHub, or an email account so ratings stay tied to real people.
No reviews posted yet.
