Wundervault is built so your agents use your secrets without ever holding them, and so we can't read your vault. Every security product makes trade-offs around its core. Here are ours, and what you can do about them. If something here turns out to be wrong, we correct it and say so in the changelog.
Reconciled against website 1.0 and MCP server 2.0.
Built for one job
Wundervault lets your agents use secrets without holding them. That focus shapes what it is.
- Your agents use secrets; they never read them. Agents never receive a secret's value. That is the point. If an agent has to read, parse or change a credential itself, keep that credential outside Wundervault.
- Hosted, with your side open source. The vault is a hosted service, with no offline or self-hosted build. The code that touches your secrets on your side, the broker and the browser encryption, is published under AGPL-3.0; the hosted server is proprietary. Need it on your own servers? Tell us.
- Independent audit and certifications: not yet. There is no SOC 2, no HIPAA certification and no completed third-party security audit today. If your team needs one, tell us; it shapes what we build next.
- Brokers the secrets you already have. Wundervault uses the secrets you give it. It does not mint short-lived database or cloud credentials for each task.
Limits shared across the industry
None of these is unique to Wundervault: any vault that runs on your computer or in your browser lives with them. Here is what keeps each one small.
- An administrator on your computer is inside the wall. Root on Linux, an administrator on Windows, and anything they run can read the broker's store. On Windows, a remote SSH session as an administrator has full administrator rights. Keep administrator access for the people who need it.
- Software that can read your browser can read your vault. A malicious browser extension or malware on your computer can see what you type and what you unlock. Unlock your vault only on a computer you trust.
- Your browser runs the code we serve. A compromised server could serve code that captures your passphrase. The browser encryption is open source, and our verification guide shows how to check what is actually sent.
- A revealed one-time secret can be copied. A recipient can screenshot it before it burns.
- Restores go back to the last backup. We back up on a schedule, so a failure between backups can lose recent changes.
Brokered secrets: where the lines are
The broker is what keeps secrets away from your agents. These are the lines it draws, and how to set them where you want.
Approvals and destinations
- "Run without asking" secrets go where your agent sends them. The agent chooses the destination; that is what lets it work without you. A tricked agent could send such a secret to a server someone else controls, because the request carries the secret. Every call is logged on your machine, and you can be emailed the first time a secret goes somewhere new. For secrets that matter, choose "ask me first".
- "Ask me first" approves a destination, not an intention. You approve an exact destination, method and path, once or for a window. Within that window, calls with the same destination, method and path go ahead without asking again, whatever they contain; a different destination, method or path asks again.
- Your agent gets the service's answer, minus your secret. The broker removes your secret from the answer, as it was sent. A service that sends it back in another form, such as encoded, could get it past. Everything else the service returns is your agent's, including data the secret can read and any new credential the call creates, such as a token minted by a "create API token" request.
- An SSH key can do whatever its server account can. The host list limits where your agent connects, not what it does there. Give each secret its own limited account on the server.
- Six ways to send a secret today, and three not yet. The broker sends a secret as a bearer token, in a header you name, as a query parameter, as a username and password, or as part of the web address, or it signs each request with the secret (AWS, SnapTrade, most exchanges). A token exchange (OAuth), a client certificate, or requests signed with a key pair (such as Coinbase's newer API keys) don't work through it yet.
Payments and signing
- The broker checks who gets paid and how much. It enforces the payee and the amount: payees you trust, up to your limit, or your approval. It can't prove which merchant sent a payment request.
- Your browser seals every payment and signing approval. Approving a payment, a signature or a new way to stamp needs your vault unlocked, because your browser seals the approval with the agent's key. A server that only says "approved" can't spend your money.
- A signing key signs whatever you approve. Text up to 64 KB is shown to you in full. For anything else you see its size and fingerprint, not its content.
- Daily wallet limits are counted per computer. Each computer running your broker counts its own last 24 hours, so two computers with a $5 limit can spend $10 between them. Wiping the broker's files on a computer resets its count.
- Wallets pay in USDC on Base and Solana. Other tokens and networks, and payment methods that need a separate approval step on the blockchain, are refused.
- The broker refuses outdated wallet rules, once it has seen some. It rejects a wallet's rules if they are older than ones it has already seen. A new computer has seen none, so it accepts the first settings it is given.
On your computer
- On Linux, the system adds a second lock. There the broker's service is also locked down by the system: no special privileges, a read-only view of the rest of the machine. Windows and macOS have no equivalent we can use, so there the broker's separate account is nearly the whole defence.
- On Linux, the broker's store key is sealed to the machine's TPM, where it has one. On Windows and macOS it is a random key in a file only the broker's account can read: a copy of the disk plus administrator rights opens it. Turn on BitLocker or FileVault.
- Agents on one user account share the broker. Your agents run as you, so the operating system can't tell them apart. Any of them can use any other's access to the broker. A separate account per agent is on our list.
- Argon2id vaults need WebAssembly. A vault on Argon2id can't be opened where WebAssembly is turned off; iPhone Lockdown Mode is the common case. The page says so instead of reporting a wrong passphrase, and vaults created on such a browser use PBKDF2 instead. You can still approve web-service requests there with your passkey; approving a payment or a signature needs the vault unlocked, which won't work there.
Agent access
- Treat a secret your agents could read before version 2 as seen. Moving to the broker protects secrets from now on. It can't recall a value already read. The dashboard lists those secrets; replacing them at the service that issued them is the only fix.
- Agent credentials last until you revoke or repair the agent. A leaked agent credential is refused for brokered secrets unless it comes from your paired broker, but it stays valid until you revoke or repair the agent.
- Revoking an agent stops its next request. It can't undo a call already made.
What our server sees
- Your secrets are encrypted on your device. Vault contents, one-time secrets and agent vaults are encrypted before they reach us. We can't decrypt them.
- We see names and timing. We see your email address, the names of your secrets and agents, when a secret was used and by which agent, and, for "ask me first" secrets, the destination you are asked to approve. We don't see where a "run without asking" secret was sent.
- A payment or signature waiting for you is held until you decide or it expires. While it waits, our server holds what you'll be shown: the payee and amount, or what is being signed. Both are erased when you decide or the request expires. A nightly backup taken in between keeps a copy.
Logs
- The activity log is tamper-evident. Each entry is chained to the one before it with a key held on our server. That makes it tamper-evident, not tamper-proof: someone holding that key could rewrite history consistently.
- Entries written before 8 September 2026 have lighter coverage. An edit to one is detected; a deletion at either end of the log is not. They age out within a year.
- Catching the deletion of a whole log needs an outside copy. Deleting an account's whole log is not detectable from our database alone; catching it needs a copy held somewhere we don't control. We don't keep one yet; it is on our list.
- The signature covers the order of entries, not their times. The order is signed; an individual entry's time could be changed.
- You choose how long routine activity is kept. 30 days by default, or 60, 90 or 365. Approvals, revocations and refusals are kept 365 days.
- The log on your computer is checked against our copy, not kept from administrators. Someone with administrator rights can edit it and sign it again. They can't make it match the fingerprints we hold, so the change shows and we email you. Lines written in the minute before such a change, or while the computer was offline, aren't in our copy yet, and a broker that is stopped can't report anything: the vault page shows when each computer last checked in. Alerts are emailed at most once a day for each computer.
Your account and the service
- Your Account Secret lives in your browser. It is one of the two secrets that open your vault, and it is never sent to us. A new device, or clearing your browser's data, needs your recovery code.
- People sign in; agents get their own credentials. You sign in with email and passphrase, optionally Face ID or Touch ID. There are no separate API keys for people.
- Watched around the clock, with a public record. Availability is monitored from outside our infrastructure, and the record is public, bad days included. Wundervault runs in one region, without a contractual uptime commitment yet.
- Rate limits are per network address. People behind one shared connection share a limit.
On our list
Discussed, not built yet. Listed here so nothing is mistaken for a feature you have today.
- A third-party security audit
- A signed, native broker for macOS and Windows, with system-level sandboxing
- A separate account per agent, so agents can't share broker access
- Agent credentials that expire, or are bound to one device
- A copy of each log's fingerprint kept outside our database
- Spending limits enforced by the blockchain itself, so even a broken broker can't overspend
- Card payments, and Google's AP2 spending permissions — coming soon