Labsco
MCP SERVER · OFFICIAL PROJECT

wundervault

by wundervault

Let an agent use your API keys and SSH keys without ever receiving them — the secret is injected into a subprocess and the output scrubbed.

Identity, Access, Secrets & EncryptionOfficial source
Summary
The agent gets the work done and never gets the key.

Everything follows from one inversion: the tool surface offers actions, not values, so a leaked transcript, a prompt injection or a stray log line has nothing to leak. The limits are stated plainly by the project — a local daemon must run alongside the agent, so air-gapped setups do not fit, and if your workflow needs the model to reason about the secret itself, this is the wrong shape.

What it is

A secrets vault built for agents. Instead of handing the model a key, the agent asks for work — run this deploy, sync this directory — and a local daemon decrypts the secret, injects it into the subprocess environment, zeroes the buffer after spawn and scrubs the plaintext out of stdout and stderr before anything returns.

What you get
  • vault_entries_list — the entries this agent can reach, as IDs and secret names with no values
  • vault_entry_get — decrypt a secret and optionally run a command with it; the agent gets back "Secret retrieved and burned", never the plaintext
  • vault_exec — run a shell command locally or over SSH with the secret injected as an environment variable; escape patterns such as $(), backticks, sh -c, eval and file redirects are rejected before decryption
  • vault_entry_inject_env — write a secret straight into an allowed config file (~/.npmrc, ~/.netrc, ~/.docker/config.json or a project .env) without the plaintext passing through the agent
  • vault_rsync — sync a directory to a remote host with the SSH key fetched from the vault and the temporary keyfile deleted after transfer
  • vault_entry_forget — discard a local reference; a no-op on the server
Requirements

A Wundervault account and the local agent daemon running next to your MCP client — register the agent, then set WUNDERVAULT_AGENT_NAME to its registered name; WUNDERVAULT_AGENT_TOKEN is optional and defaults to a token file under ~/.wundervault. Install with npm install -g @wundervault/mcp-server and the client runs wundervault-mcp. Secrets are encrypted client-side with AES-256-GCM before upload, so the hosted service stores ciphertext only. High-tier entries require human approval before an agent can use them.

Setup effort

One command plus a key — npm install -g @wundervault/mcp-server, then supply credentials