● CLIENT.ENCRYPTED ● SERVER.BLIND ● AGENT.NATIVE
v0.25.5-fd2935c0
// AGENT-NATIVE SECRETS
▸ Comparison

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

Compared from public sources, read 6 September 2026.
Criterion Wundervault Peta
Does the agent receive plaintext?NoNo
Can the vault provider read your secrets?No — never given the keyThe environment running it can decrypt to inject
Where decryption happensOn your machineServer-side, at execution time
Sits in the path of agent trafficNo — one MCP serverYes — MCP gateway and runtime
Verify it yourselfYes — open client crypto, published procedureSource available under Elastic License 2.0
Step-up approvalTier-2 secrets, gated by a WebAuthn challengePeta Desk, a desktop approval app
AuditTamper-evident HMAC chain, purpose recorded per accessPer-agent tool-call audit, SIEM-ready export, per peta.io
Policy enginePer-agent scoping and access tiersRBAC/ABAC in Peta Console, per their docs
SSO / SAMLNot today — tell us if you need it"SSO/SAML support for identity integration", per their docs
Self-hostingHosted today — ask us about self-hosted deploymentKubernetes and Docker, air-gapped supported, per their docs
LicenceMCP server and client crypto AGPL-3.0; platform proprietarypeta-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.