Wundervault vs. Peta
Your agent needs a production credential, and handing over the plaintext puts your key in a context window, a transcript, and somebody's logs. Several products now stop that. Wundervault is the one that stops it without asking you to trust us instead — your key is derived in your browser, we are sent ciphertext, and the secret is unwrapped on your own machine at the moment it is used.
Peta, from Dunia Labs, solves the same problem a different way: it holds your secret and injects it server-side as the tool call executes. This page is our account of that difference. We are obviously not neutral, so every claim about Peta below is quoted from their own site, documentation and repositories, linked as we go and read on 6 September 2026. If we have something wrong, tell us and we will correct it.
What you get from Wundervault
- A hosted vault that cannot read your secrets. Your key is derived in your client. We receive ciphertext and are never given the key that opens it, so the plaintext is not ours to leak, to lose in a breach, or to be compelled to produce. That is not a promise about our conduct — it is a consequence of where the key lives.
- Nothing new in the path of your agent. Wundervault adds itself as one MCP server. You point it at the credentials that matter and everything else your agent does carries on unchanged. There is no gateway to route traffic through and no control plane to adopt.
- Proof instead of assurances. The client crypto is open source and the verification procedure is a test you run yourself, watching your own traffic. Every vault says it protects your secrets. We will show you the point at which ours stops being able to read them.
- A second lock on the secrets that deserve one. Mark a secret Tier 2 and every use needs a fresh biometric or passphrase check, not just an unlocked vault.
- An audit trail you can hold to account. A tamper-evident HMAC chain, with the stated purpose recorded against each access.
Where the secret is decrypted
This is the whole difference, and it is worth a minute.
Peta's peta-core documentation states: "Secrets stay encrypted at rest (PBKDF2 + AES-GCM) and are injected server-side at execution time. Clients never see raw credentials" (peta-core README). That does what it says — in the documented flow the agent, the model and the transcript never hold the value, and that is a real improvement on a .env file.
The load-bearing word is server-side. To inject a credential as a tool call executes, something in that environment must turn the ciphertext back into your API key — which means the key that does it is there too. The secret is kept from the agent by a system that can, by construction, read it. Who that hands trust to depends on who runs that environment: their documentation lists Kubernetes, Docker and air-gapped deployment, so run it yourself and the answer is you. Run it as a service and the answer is whoever does.
Wundervault removes the question rather than answering it. Decryption happens on your side of the wire, in a daemon on your own machine. There is no environment — ours or yours — that holds both your ciphertext and the key to it. You get the convenience of a hosted vault and keep the property that usually costs you a server to run. What we do hold is the surrounding metadata: entry names, timestamps, the audit trail. The white paper says exactly what that is, and what our design does not stop.
Side by side
| Criterion | Wundervault | Peta |
|---|---|---|
| Does the agent receive plaintext? | No | No |
| Can the vault provider read your secrets? | No — never given the key | The environment running it can decrypt to inject |
| Where decryption happens | On your machine | Server-side, at execution time |
| Sits in the path of agent traffic | No — one MCP server | Yes — MCP gateway and runtime |
| Verify it yourself | Yes — open client crypto, published procedure | Source available under Elastic License 2.0 |
| Step-up approval | Tier-2 secrets, gated by a WebAuthn challenge | Peta Desk, a desktop approval app |
| Audit | Tamper-evident HMAC chain, purpose recorded per access | Per-agent tool-call audit, SIEM-ready export, per peta.io |
| Policy engine | Per-agent scoping and access tiers | RBAC/ABAC in Peta Console, per their docs |
| SSO / SAML | Not today — tell us if you need it | "SSO/SAML support for identity integration", per their docs |
| Self-hosting | Hosted today — ask us about self-hosted deployment | Kubernetes and Docker, air-gapped supported, per their docs |
| Licence | MCP server and client crypto AGPL-3.0; platform proprietary | peta-core Elastic License 2.0; Desk and MCP servers MIT |
Choosing between them
If what worries you is "my agent will paste a key into a transcript", both designs address it, and you should choose on fit.
If it also extends to "and I would rather nobody else could read my secrets either", that narrows quickly. A vault that decrypts inside its own environment can only give you that by making you the one who runs the environment — which means infrastructure to stand up, patch and staff. Wundervault gives you the same property with nothing to run, because the key never reaches us in the first place.
Need it inside your own perimeter, or need SSO across a team? Talk to us — those conversations are worth having and we would rather have them than lose them.
Peta is a product of Dunia Labs. We are not affiliated with them. This page describes their product from their public site, documentation and repositories, last verified 6 September 2026; where we quote them the wording is theirs.