What we shipped.

Now we can't read anything in your vault

Your privacy matters more to us than anything else we build. We have never been able to read your secrets. With this update, we can't read anything else you keep in your vault either: not what your secrets are called, not which services they're for, not how your agents use them.

• Your vault locks. Once every computer you use is on the new broker, the names of your secrets and how each one is used are kept in a form only your browser and your broker can open. A new vault locks as soon as you set it up. An existing one locks the next time you sign in after your computers are updated.

Easier to use

• Update your computers from the vault. No more commands to type. After one last update by hand, choose Computers → Update now and confirm with your passkey. The broker checks that the update is signed by us before it installs it. If the new version doesn't work, it goes back to the old one by itself.
• Adding a secret is quicker. Type the name of the service, paste the key, and save. The vault knows how 27 common services expect their keys, so you don't have to set that up. A new guide walks through any service that isn't on the list.
• Keys with an ID and a secret, such as Amazon Web Services keys, can sign each request without your agent seeing either part.

More private

• Requests waiting for your approval are sealed too. The website shows you your agent's reason so you can decide. Once your vault is locked, only your browser can read it, and the website deletes it once you've decided. Your computer keeps the reason in its own log.
• Emails don't name your keys unless you turn on “Name my keys in emails” in Settings.
• New sign-ups confirm their email with a code. The code only works in the browser you signed up in. If an account's email was never confirmed, it is asked for a code at its next sign-in.
• Help has a health check that spots secrets worth tidying up, and a report you can send us if something goes wrong. It never includes your secrets.
• Pages load faster.

Most of this needs version 2.2.0 of the Wundervault MCP. How to update.

Fixed the same day (1.1.1): filing one secret from the tidy-up suggestions no longer hides the other suggestions, Computers shows a broker's new version as soon as it has updated, and the update steps give every command.

Post to X through your vault, and a safer broker reinstall

• Your agents can post to X, and use other services that sign each request with OAuth 1.0a, such as Tumblr and Flickr. Save the four values X gives you as one secret, {"api_key": "…", "api_secret": "…", "access_token": "…", "access_token_secret": "…"}, and set it to Signed requests. Your agent never sees them: the broker signs every post itself, and you approve it once for X. The vault recognises the four values when you paste them. If you saved X keys before 1.0, open that secret and switch it to Signed requests.
• Reinstalling the broker is safer: the installer can't be steered into changing files outside the broker's own folder. When sudo on your computer is exposed, it now prints four commands that fix it without opening an editor as an administrator; Help explains them. On Linux, removing the broker waits until it has really stopped.
• Sharing a wundervault.com link shows a new picture, on every page.

Signing for X and the installer changes are in version 2.1.0 of the Wundervault MCP. How to update.

Update steps in one place, and the vault points to them

The vault's “update available” notice said to run npm install -g. Since version 2 that isn't enough on Linux and macOS: it needs sudo, and the broker installer has to run again so the broker restarts on the new copy. The notice, the update email and the version check your agents read now point to Install › Updating, which the changelog's MCP tab shows too.

A safer broker install, and the changelog in two tabs

• Version 2.0.3 of the Wundervault MCP closes a way an agent could have run a program as an administrator while you installed, updated or removed the broker. On a Mac the installer looked up system tools in folders your agents can write. On Linux and macOS, update with sudo npm install -g @wundervault/mcp-server@latest, then run the broker installer again. Windows, or still on version 1: how to update. If the installer now stops and names a folder, it says how to fix that.
• Setup and Help show the pairing and log commands with full paths, as the installer prints them: sudo /usr/bin/node /usr/bin/wundervault-agent --pair on Linux. With sudo, a bare name could be found in a folder your agents can write.
• The changelog has two tabs: the website, and the MCP server that runs on your computer.

Approvals in seconds, and a smoother setup

The first update after 1.0, from watching the first week of setups closely.

• Approvals show up within seconds in an open vault, so your agent's request is in front of you while it waits. After you answer, Approvals shows what happened next: when the agent used your approval, or that it will the next time it tries.
• When an approval doesn't come in time, your agent says so plainly: nothing was sent, the request is still open in your vault, and the same call goes through once you approve it.
• Computers have their own screen in the vault, and Pair a computer closes when the pairing is done and shows the new computer.
• Setting up on Linux: the steps now say sudo npm install -g, the broker installer always installs the copy it came with, and it ends with the next steps in order.
• Moving an agent from version 1: quit and reopen its app after installing version 2. If an old copy is still running, the message now says that in plain words and how to fix it.
• Tools are back in the top menu (one-time secrets and the username generator), and Help is in the footer. The message you paste into an agent now shows the setting for Claude Code as well as OpenClaw.

The installer and message changes are in version 2.0.1 of the Wundervault MCP. How to update.

Wundervault 1.0: your agents use your secrets without holding them

Before 1.0, the Wundervault program on your computer fetched a secret from your vault when an agent needed it, unlocked it there, and used it for the agent: it put the secret into the command the agent asked to run, or into a settings file. The secret stayed out of the agent's chat, so an agent doing its job never handled it. But that program ran in the same account as your agents, so an agent set on getting a secret could still reach it, for example by running a command that printed it. The protection counted on agents behaving, and as agents grow more capable, and can be tricked by what they read, we don't think that's enough.

From 1.0 a small program on your own computer, the broker, keeps your secrets in an account of its own that your agents can't enter. It makes each call for your agent and hands back the answer with the secret removed, so even an agent that misbehaves has no secret to take. It works the same way on Linux, Windows and macOS. Read the announcement.

What your agents can do. Five tools, none of which returns a secret: call a web service (the secret is sent the way you set for it: a header, a query parameter, a username and password, part of the web address, or a signature for services such as AWS), run a command or copy files over SSH, pay for a service with x402 inside the limits you set, sign data you approve, and list the secrets they may use. Each agent needs version 2 of the Wundervault MCP. How to upgrade.

Sign in with a passkey. One touch signs you in and, where your device supports it, opens your vault. Once your account has a passkey, its password is switched off. Approving a secret set to "Asks me first" takes your passkey every time. Lost every passkey? A recovery code gets you back in after 3 days, and we tell you at once so you can stop it if it isn't you.

A new vault screen. Your secrets come first, each with what it is, how it is sent, whether it asks you first, which agents have it and when it was last used. Every secret has its own page. You can pause every agent, one agent or one secret; give an agent a secret until a date; put back an earlier value for 30 days; tag secrets; and bring secrets in from a .env file, 1Password or Bitwarden. Help, Settings and this page are inside the vault, and approvals work on a phone.

Stronger protection for your vault. New vaults are protected with Argon2id, and existing vaults move to it the next time you unlock. Your Account Key, the part that never leaves your device, is shown in Settings so you can bring it to a new device.

A record that stays with you. Where a "Runs without asking" secret went, and why, is kept in a signed log on your computer, checked against a copy of its fingerprint we hold. We see that a secret was used, by which agent and when; not where it went.

We keep less. For "Asks me first" secrets we keep the agent's reason only until you decide, and the destination only until the approval is used up. Deleting your account removes everything that is yours at once, and from our backups within 60 days, and it stays deleted even if a backup is restored.

Also in 1.0. A recovery code restores your vault on a new device, or changes nothing. Making new recovery codes, exporting your vault, removing a passkey and choosing how long activity is kept all work again. Changing your email confirms the new address first; changing your password signs out your other devices. Only the owner of an inbox can unsubscribe it from the newsletter. Pages stay quick when traffic spikes, and sign-up refuses throwaway inboxes.

New names. What you keep in your vault is now called a secret, and the Account Secret is now the Account Key. It is the same value: a copy you saved before 1.0 still works.

Gone in 1.0. Agents on version 1 of the MCP can't use your secrets until they upgrade. The one-time link for showing a secret to a person is retired: sharing passwords with people is a password manager's job. Some things version 1 could do with a secret, such as putting it into any command, are not in 1.0 yet; they are under Coming next.

slopmill joins the Projects shelf

The newsletter page now links to slopmill, the open-source writing tool Wundervault Weekly is written in: you write the parts you care about, and it drafts the rest in your own voice.

The site learns about a new MCP release on its own

The version shown on /install and /mcp now comes from npm directly, instead of two constants that had to be hand-edited together on every release and repeatedly were not — /install offered 1.7.0 for an hour after 1.7.1 was announced. Publishing a release no longer needs a site deploy to match it. Cached for an hour and refreshed in the background, so no page waits on npm, and never able to advertise something older than the site shipped with.

You are now told when a newer MCP is out

The dashboard's update banner could never appear: it was tied to agents being “outdated,” which only happens when a minimum version is enforced, and one deliberately is not. There are now two levels — red when an agent will stop working, amber when it is merely behind and you can update whenever it suits. There is also an optional email, once per release, under Settings → Notifications.

The newsletter page stopped looking half-finished

On the newsletter page, the latest-issue card floated in the middle of its column while the signup block beside it ran the full height, leaving a ragged gap above and below at every width over 880px. Measured at 1280px the card was 335px against the signup block's 726px. The card now fills its column and the two end level, with the read link pinned to the bottom edge. Re-measured at 1280, 1024, 900 and 390px, with no horizontal overflow on a phone.

Also cleared the “New” badges from the Fader and Forum project cards, which had been new for several months. The two badges that remain are the ones that expire on their own.

A secret now goes exactly where you said it should

Each vault entry names how its secret reaches a command — over stdin, through an askpass helper, or as an environment variable. That choice is now enforced against the agent asking. Previously the calling agent could name its own channel and the vault would honour it, so a secret you had scoped to stdin could be requested as an environment variable, where anything else running as you can read it. Your setting was advisory; it is now a ceiling, and an agent that asks for something weaker is told its request was refused.

Placing a secret in a config file now resolves the real destination first. The check used to look at the file's name and then write to the path it was handed. A file called .env that was really a pointer somewhere else — a symlink, or a second name for another file — took the secret with it. The destination is now resolved and checked before anything is written, the write goes through a fresh file that is renamed into place rather than overwriting in place, and a target that has picked up another name in the meantime is refused. A failed write can no longer leave your config file truncated either.

Environment variable names are validated. A name supplied by an agent was placed directly into the script sent to a remote host, so a name containing shell punctuation could run commands there. Names are now held to what an environment variable may actually be called, checked before any secret is fetched.

We also closed a case where an unrecognised delivery setting — a typo in the dashboard, say — fell through to the environment variable channel instead of stopping. Unrecognised values are now refused outright.

Most of this began with an independent audit of the MCP server, which we asked for and publish the result of. It found no malicious code and confirmed the cryptography; the findings above are what came out of working through it, including two that surfaced while fixing the rest. The boundary we have always described on /limitations — that a command holding your secret can still choose to send it somewhere — is unchanged, and still the thing to scope your entries around.

Direct injection now covers the files it can actually write

vault_entry_inject_env writes a KEY=value line. That is right for .env, .env.local, .env.production and ~/.npmrc, and wrong for the two other paths it used to accept: ~/.netrc has its own grammar, and ~/.docker/config.json is JSON, so a KEY=value line left it invalid. Both are now refused by name with the reason, instead of quietly damaging the file.

For those two, use vault_exec with the tool that owns the format — npm config set, docker login — and the secret is delivered to the command rather than written by us. Both will come back as direct injection once they have writers that understand their formats: JSON-aware for the Docker config, and machine/login/password for .netrc.

The installer you can diff against GitHub matches again

We publish the installer on GitHub so you can compare it against the copy wundervault.com serves before running either — and we tell you to run neither if they differ. The served copy had moved ahead of the mirror, so that check was failing for anyone who ran it. The mirror is current, its signature verifies against it, and our build now fails if the two ever drift apart again.

Separately, the documentation has caught up with how agents are actually configured: credentials come from the local daemon, and the README no longer lists command-line options that were removed when that changed.

Search your activity log, and read it on a phone

A filter now sits above the activity log, the same as the one over your secrets. Type any part of an agent, a secret, an action, a purpose or an IP address and the list narrows as you type, with a count of what is showing. Nothing is sent anywhere to search.

On a phone the log used to be a seven-column table you had to drag sideways, and only the first two columns were visible — the purpose, outcome, IP and time sat off the edge of the screen. Each entry is now a card that names its own fields, so all of it is readable without scrolling anywhere.

Tier badges line up everywhere, and a failed refresh says so

The T1 and T2 badges moved to the left of the name in your agent vaults, matching MY SECRETS, so they line up down the column in both places. An agent vault could also show a tier 2 secret as tier 1; it now reads the real tier.

If the activity log fails to refresh, it keeps what it is showing and tells you the refresh failed. It used to replace your history with “no access history yet” — the opposite of the truth on the one page that exists to tell you what happened.

Your activity log now shows only your account

Most rows in the activity log are tied to a specific secret, and those were always scoped correctly. A few kinds are not — deleting a secret, registering or revoking an agent, locking or unlocking tier 2 — because the row has to outlive the thing it describes. Those rows were matched too broadly and could appear in another account’s log, carrying the secret’s name and the account’s email address.

They are now matched by account. Older rows recorded before we stored an owner are hidden from everyone rather than shown to anyone. No secret value was ever involved — values are encrypted in your browser and the server cannot read them — and no other part of the vault was affected.

Clearer activity log, and a tier filter

Your own actions used to show a blank agent and a blank secret. They now read You, name the secret — including after you delete it — and record the IP the change came from. Each agent’s own history is back on its tab, and the CSV export works again.

In MY SECRETS, tier badges moved to the left so they line up down the column, and the old tier legend is now a working T1 / T2 filter next to the search box. The expanded panel puts show, copy, edit, delete and close on one row.

One place to read, change and re-tier a secret

Opening a secret now expands it in place, under the row, instead of covering the page. Read it, copy it, rename it, replace its value or move it between tiers from the same panel — no separate screen for looking and another for changing.

Opening one decrypts nothing. Renaming a secret or changing its tier never puts the value in your browser at all; only SHOW and COPY VALUE fetch it. Changing a value asks for the new one in an empty field rather than handing you the old one to edit, so a stray keystroke cannot corrupt a credential you cannot see. Raising a secret to tier 2 is immediate; lowering one asks you to confirm who it is, and names the agents that will stop needing your approval.

Find a secret by name, and sort the list

A filter and a sort now sit above your secrets: type part of a name to narrow the list, or order it by newest, oldest, last updated, or alphabetically. Both work entirely in your browser — nothing is sent anywhere to search, and nothing is decrypted to sort.

The dashboard keeps itself current

Send a secret to an agent and open that agent’s vault: it is there. The activity log updates itself as things happen — when you make a change, and when one of your agents reads a secret — rather than waiting to be asked. The page-wide refresh button is gone, because nothing needs it now. The log keeps its own refresh for when you want to check on the spot.

One-time secrets create reliably again

Creating a one-time secret on /one-time now works end to end. When the tool moved off the home page onto its own page it was left pointing at a different copy of our browser crypto than the one that page loads, so the encrypt step had nothing to call. Both pages now share one implementation, on the same scheme they always used — PBKDF2 at 600,000 iterations, AES-GCM, and a one-way verifier — so every link issued before today still opens exactly as it did.

Saving from the home page keeps what you typed

Saving a secret to a vault needs an account, and you can now log in without leaving the page: the prompt signs you in where you stand and finishes the save for you, so nothing is retyped. Previously logging in meant navigating away, which took your draft with it. Your secret stays in the browser throughout and is never written to storage — it is encrypted in place and sent only when the save completes.

Agent Context is retired, and its storage is gone with it

Agent Context let an agent keep encrypted context files in the vault. We stopped developing it in August and have now removed it completely: its endpoints, its data model and its table are gone, the companion @wundervault/mcp-context package is deprecated on npm, and stored bundles have been deleted. The vault MCP server, @wundervault/mcp-server, is unaffected — it never used any of this. /limitations describes what changed.

Tier 2 is now a per-request approval, and every page says so

Tier 2 used to work as one unlock: prove yourself in the dashboard and agents could reach Tier 2 secrets for as long as the session lasted. It works better now. An agent asking for a Tier 2 secret is blocked and handed a request id it can poll, you get an email, and you approve that agent, for that secret — once, for 15 minutes, or for 60 minutes — behind a biometric or passphrase check. An open window shows a live countdown and can be revoked mid-flight, and every request, decision and revocation is written to your audit log.

Those three choices existed only on the buttons themselves. They were on no page and not in the email that asks you to decide, so this release puts them everywhere they belong — including the dashboard's own tier picker, which still described the older one-unlock model at the exact moment you choose a tier.

Two other pages still carried that older description, and the white paper carried a paragraph about a Tier 2 session lock that belonged to a design we did not ship. Both are gone. Documentation that lags a change is how someone ends up scoping their setup around the wrong model, and the whole point of writing our boundaries down is that they describe what the code actually does.

Your access log now expires, and you set the clock

Settings → Data offers 30, 60, 90 days or a year, and 30 is the new default. Routine agent activity — a secret read, a command run, and the purpose the agent wrote — is deleted once it falls outside your window. Security events are kept 365 days whatever you choose: Tier 2 decisions, revocations, and anything blocked are rare, small, and exactly what you need to read after something goes wrong.

Our privacy policy has always described a retention window for access logs. It is now enforced in two places — when you open your log, and by a nightly sweep that also covers accounts nobody has opened, which are the ones a retention policy is really for — and the new default of 30 days is stricter than the 90 it replaces.

Deleting rows from a signed log is the hard part, because removing a row from the middle is supposed to be detectable. Retention only ever removes the oldest rows of a chain, each chain now carries a signed record of how far it runs, and the fields deciding which chain a row belongs to are signed too — so trimming either end contradicts a signature that cannot be recomputed without our audit key. The prune is itself written into your log. Two gaps we did not close are on the limitations page rather than glossed over.

Rate limits and audit records now identify the real caller

Wundervault sits behind Cloudflare and a reverse proxy, so the address the application sees by default is the proxy's, not yours. Three of our rate limiters and the access log were reading that default. In practice it meant the agent API shared one rate-limit budget across everyone, and the IP shown beside an agent's activity was the proxy every time.

All four now read the true client address through a single implementation that validates and normalises what it is given rather than taking a header's word for it. Limits apply per caller as intended, and the address in your audit log is the one that actually made the request — which is the only version of that column worth showing you.

Where to send a vulnerability, and what we do if we are breached

/disclosure says both. Reports go through a tagged contact form and get a human acknowledgement within three working days; good-faith research is safe from us; there is no bounty, and pretending otherwise would waste your time.

If we are ever breached we post on @wundervault1 and email every account holder — both — within 72 hours of confirming it, without waiting for a complete picture. Uptime is now monitored from outside our own infrastructure and published, bad days included. We cannot offer an uptime guarantee, so we offer the record instead.

Secrets are hidden while you type them, not just while you read them

The create field, the edit box, the home page and the one-time tool all mask what you type, with a SHOW button when you need to check it. A secret used to be hidden once saved but sat in plain view while you were entering or editing it — the same exposure, with more of it on screen.

A burned secret now actually loses its contents

We told you a one-time secret was “permanently destroyed on read.” It was not. Burning set a flag and left the encrypted blob in the row — for every secret ever burned, going back to the first one in May.

What this did not mean: your secrets were never exposed in plaintext. They are encrypted in your browser before they reach us, under a key derived from a passphrase we never receive, so a database dump still contained only ciphertext. What it did mean is that “destroyed” was not true. Someone holding both the database and your passphrase could still have decrypted a secret marked destroyed.

Reading a one-time secret now erases the ciphertext, salt and nonce in the same operation that marks it burned, and deleting one by hand does the same. Secrets burned before today have been cleared.

Fixing it turned up a second problem worth naming: if two people opened the same one-time link at the same moment, both could receive it. A one-time secret could be delivered twice. Now only the first one gets it, and there is a test that fails if that ever regresses.

Vault values stay hidden until you ask

Opening a secret used to print it straight onto the screen. Now you get a row of dots and a REVEAL button — and COPY works either way, because you rarely need to look at a credential to use it. Nobody behind you reads your production key because you clicked the wrong row.

If you have set a reveal timeout in settings, it now counts from when you reveal a value rather than from when you open it, so the clock only runs while something is actually on screen.

The selected tab stopped looking like the unselected one

On the unlock screen, the create panel and the homepage, the tab you had selected was tinted green while the panel below it stayed plain — which made the other tab, matching the panel, look like the active one. Several people read these backwards, and they were right to.

The open tab now shares the panel's background and flows into it; the closed one sits recessed. Screen readers had the same problem for the same reason and now announce which option is active, with arrow-key navigation between them.

One-time secrets have their own page

The one-time secret tool now lives at its own address under TOOLS, alongside the username generator, instead of being one half of a toggle on the home page.

Grok Build works with Wundervault

xAI's terminal agent takes MCP servers configured for Claude Code unchanged, so our server works with it as-is. It is listed in the setup instructions with the others. Run grok mcp add and it picks the vault up.

Agent onboarding briefly shipped broken

A deploy signed our installer with the wrong key, producing a script that refuses to run its own verification. Any agent onboarded in that window would have failed at the signature check — while the site returned a normal page and no error appeared anywhere.

It is repaired, and the signing step now refuses to write a signature the script itself would reject, so a deploy can decline to ship a broken installer but can no longer create one. Two tests pin it.

We were overclaiming about prompt injection

Our docs said blocking shell-escape patterns “eliminates prompt injection as a path to arbitrary execution with secret privileges.” The blocking is real, but that sentence was not.

vault_exec exists to run the commands your agent asks for. An injected instruction that produces an ordinary-looking command — one that quietly sends a key to someone else's server in a request header — matches no blocklist, because nothing inspects intent and nothing blocks outbound network access. Calling that “eliminated” invites you to plan as though there were a sandbox underneath. There is not. Treat vault_exec as a shell on your machine with a credential attached, and scope your entries accordingly.

The onboarding message stopped reading like a phishing lure

An agent being onboarded told us: “Your pasted command had no --dry-run — as given it would have run for real. I added the flag.” It was right. We described the safe option in prose and then handed over the run-for-real command, so reading-before-consenting only worked for an agent careful enough to rewrite what we gave it. It is now two numbered steps, and the second runs the file you just read rather than fetching it again.

We also removed a claim we could not honour — that our public key ships in the npm package. It does not, and a careful agent would have gone looking, found nothing, and trusted us less. Instead, the installer is now mirrored in the public GitHub repo, and /verify shows you how to diff the two. That is not a root of trust either, and the page says so.

The right account controls on first load

Every page used to render signed-out and then correct itself, so for about a quarter of a second a signed-in user was shown “log in” and “start free”. The account state is decided on the server now, so the first thing painted is right. The reference pages also moved into a Docs menu instead of a flat row of links.

Username generator

A free generator at /username-generator — pronounceable, lookalike-free, random, or word pairs. It runs entirely in your browser; nothing it makes is ever sent to us. No account needed.

Revoked agent setup links stop working immediately

A setup link for an agent you had already revoked kept handing out credentials. It does not any more. Onboarding also stopped reporting a healthy setup as unreachable, and the approval and execution settings now save.

Newsletter by RSS

The newsletter has a feed, with full articles and audio where an issue has it, so you can read it without handing over an email address.

Rate limits that actually applied

Two problems. The whole /auth section — log in, the six-digit email codes, password reset — had no rate limiting at all, so those codes could be guessed at speed.

Worse, the limits that did exist elsewhere had never once triggered in production. They counted requests per IP address, but behind Cloudflare every request arrives from a different edge address, so each one landed in a fresh bucket and no limit was ever reached. They now count the real client address, and a wrong six-digit code burns an attempt on the account rather than on whatever address happened to send it — five wrong guesses invalidates the code.

Signups opened

Accounts no longer need an invite code.

The vault key stopped depending on your passphrase

Your vault key is now a random key of its own, and the server keeps only a hash of a value derived from your passphrase — no key material, so there is nothing on our side that could decrypt your vault even in principle. Existing vaults migrated themselves on the next unlock, with nothing for anyone to do.

A second tier for the secrets that matter most

Mark a secret Tier 2 and it needs a fresh biometric or passphrase check every time it is used, rather than riding on an unlocked vault. Agents can be required to clear that gate too.

A real settings page

Change your email or password, manage biometric devices and recovery codes, and delete your account, in one place.

Email verification required

New accounts verify their address before they get a session. Accounts that already existed were left signed in and treated as verified.

Your last update by hand: from now on, update from the vault

We want Wundervault to be easy to keep up to date. Until now, every update meant typing commands as an administrator. From this version on, you choose Update now in the vault, confirm with your passkey, and the broker does the rest.

• Update now. The broker installs updates you start from the vault. It checks the release is signed with our release key and that every file matches. It installs beside the old version, and goes back to the old version by itself if the new one doesn't start properly. Its files live in a protected folder: /opt/wundervault on Linux and macOS, C:\Program Files\Wundervault on Windows.
• Sealed setups. The broker reads how each secret is used from a sealed copy that only it and your browser can open, and refuses one that has been changed.
• ID-and-secret keys can sign requests (AWS-style signatures and exchange keys) without the agent seeing either part.
• Fixed: signed requests to an address with a port number, such as example.com:8443, were signed wrongly and refused.
• Fixed on Windows: a program could crash the broker by dropping its connection at the wrong moment.

This is the last update you install by hand: how to update. After it, use Update now in the vault.

Signed requests for X, and a safer reinstall

• X and other OAuth 1.0a services: a secret holding the four values X gives you, set to Signed requests, is used by asking for {"builtin": "oauth1"}. The broker adds a fresh one-time code and the time to every request and signs it, so you approve once per address. None of the four values reaches your agent. HMAC-SHA256 and a realm cover NetSuite.
• Those four values are never sent as one token. A secret holding them that is still set to “Bearer token” is refused with a note to switch it, instead of being sent whole.
• Reinstalling keeps the administrator's writes in the administrator's folders. Keys are made where only the administrator can reach and moved into place in one step, so a link left in the broker's folder is refused, never followed. On a Mac, /var/lib/wundervault now belongs to the administrator.
• An exposed sudo is fixed without an editor: four commands, each tool by its full path, checked before sudo reads them.
• On Linux, --uninstall waits for the broker to stop, and removes nothing while it is still running.

Update: how to update. Then run the broker installer again, as the steps say.

The broker installer can't be made to run an agent's program

Installing the broker is the one step you run as an administrator. The installer used to find the system tools it runs, such as launchctl and id, in the folders your own account searches. On a Mac the first of those is usually Homebrew's, which your account, and so every agent, can write. A program an agent put there could have run with full control of the computer the next time you installed, updated or removed the broker. We found this in our own review.

• The installers use only the system's own tools, and start with nothing carried over from your terminal, so nothing set beforehand changes what they run.
• Node, the broker and every file of its package must be changeable only by an administrator, and so must every folder above them. If one isn't, the installer stops, names it, and says how to fix it.
• They tell you when sudo itself is exposed: if the folders sudo searches include one others can change, every sudo command you type could run a planted program. The installer names the folder and prints the one line that fixes it.
• Every sudo command the broker prints names node and the broker by their full paths, for example sudo /usr/bin/node /usr/bin/wundervault-agent --pair.

Update now: how to update. If the installer then stops and names a folder, it says how to fix that.

The broker's log looks like Wundervault, and works on a Mac

• The log page is in the site's design, with Light, Dark and Auto, and says its check result in words: “Checks out”, “Problem found” or “Not confirmed”. It still loads nothing and can't reach the network.
• It opens on macOS. It stopped before showing the page there.
• Hidden direction characters show as codes, so text an agent wrote can't display as something other than what was recorded.
• A request that changes something and loses its connection says it may already have happened, so it isn't sent twice by mistake.
• The macOS uninstaller waits for the broker to stop instead of giving up while it closes.

Plain approval messages, and installers that install their own copy

• When an approval doesn't come in time, your agent is told plainly: you haven't answered yet, you declined, or the request expired. Each says nothing was sent.
• The broker installers install the copy they came with, not an older one found first.
• The installers end with the next steps, in order: pair this computer, then move agents from version 1 if it had any.

Version 2: agents use your secrets without holding them

The release that came with Wundervault 1.0. A broker on your computer, under its own account, holds your secrets and makes each call for your agents, so they never receive the secret itself. What changed · Upgrading from version 1.

MCP server 1.7.1: one agent per credential, enforced by the operating system

The vault allows one connected agent per credential at a time. That rule is now held by the operating system rather than by a lock file — the kernel grants it to one process and reclaims it the moment that process dies, however it dies. A file could be deleted while its owner was still connected; this cannot be.

When a second session finds the credential taken it now stays connected and tells you so, naming the process that holds it and how to take it back. It used to disconnect during startup, which every MCP client could only report as “Connection closed” — the same message you would see for a crash or a bad install. Update with npm install -g @wundervault/mcp-server@latest. Until every copy on a machine is updated, older ones still coordinate the previous way.

Since 2026-10-27, @latest is version 2, which is not a one-line update from version 1: upgrading from version 1.

The MCP server is open source

Published as @wundervault/mcp-server on npm under AGPL-3.0. The code that touches your secrets is the part most worth reading, so it is readable.