Changelog

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 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.

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.