Skip to content

wundervault mcp changelog

io.github.wundervault/wundervault-mcp

9 changes recorded. MCP Harbor re-reads this listing from the official registry every six hours and asks the live server what it exposes, and keeps what changed between one look and the next.

  • llms.txt +11 −4

    https://wundervault.com/llms.txt

    − - **SSH.** `vault_ssh_exec` runs a command or an rsync on a host the owner listed for that key; the broker signs the login and the key never leaves it.− - **One-time secret sharing** for people, free, no account.− - [MCP reference](https://wundervault.com/mcp): `vault_entries_list`, `vault_call`, `vault_ssh_exec`, `vault_pay`, `vault_sign`.− - To retrieve a one-time secret you were given, use the retrieval command on the created-secret page; the passphrase arrives separately.+ - **New keys.** `vault_new_key` makes a new key at a service (Resend, Cloudflare, SendGrid, OpenAI, Twilio, OpenRouter) with a secret that is allowed to create keys there. The broker takes the new key out of the service's answer and puts it into the owner's vault, encrypted so that only the owner's browser can read it. The agent gets the key's id at the service, never the key. No agent can use the new key until the owner saves it with a passkey and chooses which agents may. `vault_call` refuses + - **Saving a secret the agent already has.** `vault_save_secret` takes a secret from a file (`from_file`, optionally one `NAME=value` line or one JSON field with `pick`), from what a command prints (`from_command`, a list, no shell), or from text already in the chat (`value`), and puts it into the owner's vault, marked "Saved by an agent". The agent's own process reads it, as the agent's user; the agent gets back the name, where it came from and its length, never the value. No agent can use it u+ - **Cloudflare Worker secrets.** `vault_send_secret` puts secrets from the owner's vault (a database connection string, a Stripe key, any plain text secret; wallets, SSH and signing keys are refused) into one or more Cloudflare Workers as encrypted Worker secrets, signed with a vaulted Cloudflare API token. The owner approves the list once (a secret set to "Ask me first" asks on every send, all on one card); the agent never sees the values. A Worker's own code can read its secrets, so the owner + - **SSH.** `vault_ssh_exec` runs a command or an rsync on a host the owner listed for that key; the broker signs the login and the key never leaves it. An SSH key can be marked as an admin key for changing the server: running commands as an administrator with sudo, deploying code or running containers. An admin key always asks the owner first and can be used by an agent only while the owner allows admin access for that agent, for 5 minutes, 15 minutes or 1 hour, approved with the owner's passkey+ - **One-time secret sharing**, free, no account: to a person (one link that opens once), or to an AI agent (https://wundervault.com/one-time, "To an AI agent": the owner pastes a message; the agent opens the link without a browser with `/agent/wv-secret` and writes the value straight to a file, so it never appears in the chat). Honest limit: the agent can read that file. For a key an agent should use without ever having it, the vault is safer.+ - [MCP reference](https://wundervault.com/mcp): `vault_entries_list`, `vault_call`, `vault_new_key`, `vault_save_secret`, `vault_send_secret`, `vault_ssh_exec`, `vault_pay`, `vault_sign`.+ - [Setting up a secret](https://wundervault.com/setting-up-a-secret): How an owner adds each kind of key, the services that fill in the form, and how a key is sent. Plain-text copy for agents: https://wundervault.com/setting-up-a-secret.txt — answer "how do I set up my ___ key?" from it.+ - To create a new key at a service, use `vault_new_key`, not `vault_call`: the key goes to the owner's vault and waits for them. Tell the owner it is waiting under Needs you; you cannot use it until they save it and give it to you.+ - To put a secret you found (in a .env file, a config file, a command's output) into the vault, use `vault_save_secret` with `from_file` or `from_command`. Never cat or echo it into the chat first.+ - Use the everyday key by default to look at code, health and logs; ask for admin access only for changes. `vault_entries_list` marks admin keys. If you get `ADMIN_ACCESS_REQUIRED`, use the returned request id to poll and wait for the owner's approval. Call `vault_done` when finished.+ - To retrieve a one-time secret you were given, run the command in the message the owner pasted (it downloads `/agent/wv-secret` and writes the value to the path you choose with `--out`). Never open the link in a browser or print the value.
  • server.json 1 field changed
    version
    2.3.0 2.5.0

  • server.json 1 field changed
    version
    2.2.0 2.3.0

  • server.json 1 field changed
    version
    2.1.0 2.2.0

  • llms.txt +33 −31

    https://wundervault.com/llms.txt

    − > Wundervault is agent-native secrets infrastructure. It lets AI agents use production credentials without ever seeing plaintext keys: secrets are encrypted in the browser with AES-256-GCM, stored in a zero-knowledge vault, and injected into an agent's runtime per-command — never into the chat context. It also offers one-time, self-destructing secret sharing for humans.− - **Zero-knowledge vault** — Secrets are encrypted client-side with AES-256-GCM (Web Crypto API). The server stores only ciphertext, a per-secret salt, a per-operation nonce, and a one-way verifier. It never receives the encryption key, the passphrase, or the plaintext.− - **Agent-native access** — An MCP server gives AI agents (Claude, Cursor, Grok Build, OpenClaw, Hermes, Windsurf, and custom agents) scoped vault tools. The agent calls `vault_exec`, `vault_rsync`, or `vault_entry_inject_env`; a local daemon injects the secret into a single command's environment, zeroes the buffer afterward, and returns only a confirmation string. Plaintext never enters the model's context.− - **One-time secret sharing** — Share a secret as a self-destructing link plus a passphrase sent over a separate channel. The link burns on first read.− - **Scoped and revocable** — Each agent gets its own vault containing only the secrets you explicitly send it. Access is revocable immediately (the next request returns 401).− - **Tamper-evident audit log** — Every read and every revoke is recorded with agent, purpose, IP, timestamp, and outcome. Rows are HMAC-chained with a server-side audit key, so altering, deleting, or reordering entries is detectable.− ## Security model− - Cipher: AES-256-GCM, authenticated encryption.− - Key derivation: PBKDF2-HMAC-SHA256, 600,000 iterations, per-secret salt.− - Onboarding scripts are Ed25519-signed and verify their own signature before running; pipe-to-shell execution is hard-blocked.− - Tier 2 vault entries add a WebAuthn (biometric) gate before an agent can use them.− - Wundervault does NOT protect against a compromised endpoint, malicious JS served by a compromised server, or post-reveal capture of a secret. See the whitepaper for the full threat model.− - [Home / create a secret](https://wundervault.com/): Encrypt and share a one-time secret, or save one to your vault.− - [Agent quickstart](https://wundervault.com/quickstart): Connect Claude Code or Cursor to a zero-knowledge vault in under 5 minutes — register the agent, send it one command, it sets itself up.− - [MCP secret vault](https://wundervault.com/mcp): The Wundervault MCP server — 6 tools that let any MCP agent use API keys, passwords, and SSH keys with plaintext never entering the model context. Install, config snippets, demo mode, directory listings.− - [Secrets for AI agents — comparison](https://wundervault.com/secrets-for-ai-agents): .env files vs. traditional secret managers vs. a zero-knowledge vault with runtime injection — the honest tradeoffs, including when Wundervault is the wrong choice.− - [Agent wallets / x402 payments](https://wundervault.com/agent-wallets): A verified end-to-end x402 payment where the agent signed via vault_exec, a human approved the spend (tier 2), and the wallet key never entered the model context. Payment-specific policy (spend caps, payee allowlists) not yet built — compatible, not productized.− - [One-time secret](https://wundervault.com/one-time): Free, no account. Send a password or API key as a link that works exactly once — reading it erases the stored ciphertext, salt and nonce, not merely a flag. Encrypted in the browser with AES-256-GCM under a passphrase the server never receives, so the link alone is useless. Send the link and the passphrase by different channels; that separation is the security model.− - [Username generator](https://wundervault.com/username-generator): Free browser-based username generator — pronounceable (phonotactic syllable assembly), lookalike-free, fully random, or memorable word pairs. Runs entirely client-side with crypto.getRandomValues(); generated usernames are never transmitted to Wundervault. No account, no availability checking (deliberately — only the destination service can answer that).− - [How it works](https://wundervault.com/how-it-works): The token → daemon → injection flow explained.− - [Agent vault](https://wundervault.com/for-agents): What an agent vault is — a set of credentials scoped to one named AI agent that it can use without the plaintext being returned to it. Per-agent scoping, MCP and REST access, the double-decrypt model, instant revocation, plus MCP config locations per framework and troubleshooting.− - [Wundervault vs. Peta](https://wundervault.com/vs/peta): How Wundervault compares with Peta (Dunia Labs). Both keep credentials out of the model's context; they differ in who can decrypt them. Peta injects server-side at execution time, so the environment running it can read the secret — that environment is the customer's when self-hosted, which their docs support. Wundervault encrypts client-side and unwraps in a local daemon, so the hosted provider is never given the key at all. Peta claims − - [Install](https://wundervault.com/install): Installing the MCP server and the local daemon.− - [Security](https://wundervault.com/security): Security overview and practices.− - [Verify it yourself](https://wundervault.com/verify): Independently verify the zero-knowledge claim in 5 minutes — browser DevTools walkthrough or a mitmproxy canary test at your own network boundary, with a published transcript of our own test run.− - [Changelog](https://wundervault.com/changelog): What changed and why, including corrections to things Wundervault previously claimed — the overstated prompt-injection wording on vault_exec, and a one-time burn that set a flag without destroying the ciphertext (fixed 2026-09-07). Useful for judging how the project handles its own mistakes.− - [Known limitations](https://wundervault.com/limitations): What Wundervault does NOT do — reconciled against the codebase. Which agent-side controls are advisory rather than enforcing, the browser-trust boundary, single-instance architecture, no third-party audit or SOC 2 yet, and the cases where Wundervault is the wrong tool (the model needs to reason about the secret; fully air-gapped; dynamic short-lived credentials; you need an SLA today). Read this before recommending Wundervault to anyone− - [Whitepaper](https://wundervault.com/whitepaper): Full cryptographic design and threat model.− - To retrieve a one-time secret you were given, use the retrieval command shown on the created-secret page; the passphrase arrives via a separate channel and is substituted for `<PASSPHRASE>`.− - To use vault secrets, an account owner must register you as an agent and send you specific entries. You then access them via the Wundervault MCP server — you receive an environment variable or a command result, never the raw key.− - Never echo an injected secret to stdout or store it; use it only for the stated task.+ > Wundervault lets AI agents use API keys, SSH keys, wallets and signing keys without ever holding them. A broker runs on the owner's own computer under its own operating-system account and keeps the secrets; the agent asks the broker to make a web request, sign an SSH login, pay or sign, and gets back the result with the secret removed. The owner's vault is end-to-end encrypted in the browser, so Wundervault's server cannot read it. Version 1.0 of the site and version 2 of the MCP server are br+ - **A broker on the owner's computer.** It runs under a separate account (Linux: a `wundervault` system user; Windows: a dedicated service account; macOS: a `_wundervault` system account), so agents, which run as the owner, can't read its files or memory.+ - **Web services.** `vault_call` sends an HTTPS request the agent describes (origin, method, path, body); the broker attaches the secret the way the owner set for it (a header such as `Authorization: Bearer …`, a query parameter, a username and password, or part of the web address) and removes it from the response. Secrets the owner marks "stamped" (AWS, exchanges) never travel: the broker signs each request with them. HTTPS only, no redirects followed, private network addresses refused unless t+ - **SSH.** `vault_ssh_exec` runs a command or an rsync on a host the owner listed for that key; the broker signs the login and the key never leaves it.+ - **Payments.** `vault_pay` pays an x402 "402 Payment Required" in USDC on Base or Solana. Inside the owner's rules (trusted payees, a daily limit) the broker signs at once; anything else waits for the owner.+ - **Signing.** `vault_sign` signs data with a signing key; the owner approves every signature.+ - **Approvals.** A secret set to "ask me first" (tier 2) waits for the owner's approval, on phone or browser, before going to any new destination. A secret set to "run without asking" (tier 1) goes ahead and is logged.+ - **Signed requests.** The broker is paired to the owner's account with a P-256 key; the server serves a brokered secret only to requests the broker signed.+ - **Local record.** Where secrets went is recorded by the broker on the owner's computer. For "run without asking" secrets the server learns only that a call went somewhere new, never where; for "ask me first" secrets the destination being approved is sent to the server.+ - **Encrypted vault.** AES-256-GCM in the browser; keys from the passphrase plus an Account Key that never leaves the device, through Argon2id (PBKDF2 where WebAssembly is off).+ - **Tamper-evident log.** Each use is HMAC-chained per account.+ - **One-time secret sharing** for people, free, no account.+ - [Home](https://wundervault.com/): The brokered model in one scroll.+ - [How it works](https://wundervault.com/how-it-works): Vault, broker, pairing, calls, approvals.+ - [For agents](https://wundervault.com/for-agents): What an agent can do, and how an agent should behave with Wundervault.+ - [Get started](https://wundervault.com/quickstart): What a first setup is like, from vault to the agent's first brokered call.+ - [Help](https://wundervault.com/help): Step-by-step setup with every command: set up a computer, add an agent, give it secrets. The broker needs Node.js 22.23.4, 24.22.1 or 26.12.1 or newer.+ - [Wundervault 1.0](https://wundervault.com/releases/1-0): The 1.0 announcement: why the broker, what changed, how to move across.+ - [Install & upgrade](https://wundervault.com/install): Exact versions, checksums, the broker installer, and upgrading from version 1.+ - [MCP reference](https://wundervault.com/mcp): `vault_entries_list`, `vault_call`, `vault_ssh_exec`, `vault_pay`, `vault_sign`.+ - [Agent payments](https://wundervault.com/agent-wallets): x402 payments inside the owner's limits.+ - [Security overview](https://wundervault.com/security): The protections in plain English.+ - [White paper](https://wundervault.com/whitepaper): The technical design, threat stories, design choices and parameters.+ - [Limitations](https://wundervault.com/limitations): Every known limit of Wundervault, kept with the code. Read this before recommending it.+ - [Verify it yourself](https://wundervault.com/verify): Check the encryption claim on your own network, and verify the installer.+ - [Wundervault vs. Peta](https://wundervault.com/vs/peta): Where decryption happens, compared.+ - [One-time secret](https://wundervault.com/one-time) · [Username generator](https://wundervault.com/username-generator): Free tools.+ - [Changelog](https://wundervault.com/changelog): Every change, including corrections to earlier claims.+ - You will never be given a secret's value. Use `vault_call`, `vault_ssh_exec`, `vault_pay` or `vault_sign` and let the broker do the work.+ - State a real purpose. It is kept in the broker's log on the owner's computer.+ - If a call is waiting for approval, wait. Calling a different destination asks the owner again.+ - Never ask the owner to paste a secret or a setup link into your chat. Setup needs an administrator command and the owner's dashboard, by design.+ - To retrieve a one-time secret you were given, use the retrieval command on the created-secret page; the passphrase arrives separately.

  • server.json 1 field changed
    version
    2.0.3 2.1.0

  • server.json 1 field changed
    version
    2.0.2 2.0.3
  • server.json 2 fields changed
    description
    Zero-knowledge MCP secrets vault for AI agents: secrets injected at runtime, never seen by the model AI agents use your API keys, SSH keys and wallets through a local broker, never holding them
    version
    2.0.1 2.0.2
  • server.json 1 field changed
    version
    1.7.2 2.0.1