Peta vs. Wundervault

Peta and Wundervault are solving the same problem: an AI agent needs a production credential, and handing over the plaintext puts your key in a context window, a transcript, and somebody's logs. Neither product does that. The difference is where the secret gets decrypted — inside the vault's own execution environment, or on your machine — and that choice decides who you end up having to trust.

We're one of the two parties here, so don't take our word for any of it. The claims about Peta below are drawn from their own site, documentation and repositories, linked as we go and all read on 6 September 2026. If we've got something wrong, or it changes, tell us and we'll fix it.

How does Peta's MCP vault compare with Wundervault's agent vault?

Both give an agent the use of a credential without giving it the credential. Peta keeps the key on its server and injects it into the tool call as it executes — in their words, "real API keys stay encrypted in the Vault and behind the MCP gateway" (peta.io). Wundervault encrypts the secret in your client before it is ever uploaded and injects it from a daemon on your own machine, so ciphertext is all our server ever receives.

In their documented flows both keep the credential from coming back to the model as tool output. The difference is what else has to be trusted for that to hold — and it's worth a minute of your time.

Where the secret is decrypted

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 is a real improvement on a .env file, and it does what it says: in the documented flow the agent, the model, and the transcript never hold the value.

Read that closely, though, because the load-bearing word is server-side. To inject a credential at execution time, something in that environment has to turn the ciphertext back into your API key, which means the key that does it is there too. Your secrets are kept from the agent by a system that can, by construction, read them. Who that hands trust to depends entirely on who runs it. Self-host Peta — their docs list Kubernetes, Docker and air-gapped deployment — and the answer is you, which is a perfectly good answer. Use it as a hosted service and the answer is somebody else, along with their access controls and their staff.

Wundervault gets you the hosted convenience without the trust. Your key is derived in your client, we receive ciphertext, and injection happens in a daemon on your own machine. We are never given a key that opens your secrets, so the plaintext is not ours to leak, to lose in a breach, or to be compelled to produce. That isn't a promise about how we behave; it's a consequence of where the key lives. And you can check it rather than trust it: the client crypto is open source, and the /verify procedure walks you through watching your own traffic. What we do hold is the surrounding metadata — entry names, timestamps, the audit trail — and the white paper says exactly what that is.

Side by side

When Peta is the better choice

Genuinely, and for more cases than we'd like:

1. You want to govern MCP tool calls, not just credentials. Peta's gateway can apply policy to the traffic routed through it, with RBAC/ABAC configured in their Console. Wundervault has no opinion about a tool call that doesn't involve a secret.
2. You need to run it yourself. Their documentation lists Kubernetes and Docker deployment and air-gapped support. Wundervault is a hosted service; if your policy is that nothing leaves your infrastructure, we are the wrong answer and they are a real one.
3. You need the enterprise surface now. SSO/SAML, RBAC/ABAC, SIEM-ready log export, OAuth token brokerage, a desktop approval app. Peta has built these; we have not.

When we're the better choice

1. You want a hosted vault whose provider can't read your secrets. If the provider must never hold the plaintext or the key that produces it, decryption has to happen on your side of the wire. That's an architectural property rather than a feature toggle — a hosted service cannot add it without moving decryption out of its own boundary.
2. You want the credential layer without adopting a control plane. Wundervault adds itself as an MCP server: you configure it and move the credentials that matter. Everything else your agent does carries on exactly as it did, with no gateway sitting in the path of its traffic.
3. You'd rather verify than take a vendor's word. The client crypto is open source and the verification procedure is a test you run yourself. Every vault says it protects your secrets; we'll show you where ours can't read them.

What we'd say if you asked us privately

These are overlapping products approaching the problem from different ends, and the choice turns on your threat model more than on a feature count. If the worry is "my agent will leak a key into a transcript", both designs address it and you should pick on fit and breadth — which may well point at Peta, particularly if you need SSO, policy across a team, or your own infrastructure. If it extends to "and I don't want to have to trust the vault operator either", you have two honest routes: run Peta yourself and become the operator, or use Wundervault and have a hosted one that was never given the key. Which of those you want depends on whether you'd rather own infrastructure or own nothing at all.

We also publish what Wundervault doesn't do and the attacks our design doesn't stop, so this can be weighed against something other than our own marketing.

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.