▸ Don't trust us — check

Verify our zero-knowledge claim

We claim your secrets are encrypted on your device before anything is transmitted, and that our server couldn't read them if it wanted to. You don't have to take that on faith. This page shows you how to catch us lying — in 60 seconds with tools already in your browser, or in full skeptic mode at your own network boundary. No access to our source code required.

The claim under test: when you create a secret, the only content-related data that leaves your device is {ciphertext, salt, nonce, verifier} — an encrypted blob, two random values, and a one-way hash. The plaintext never leaves. The passphrase never leaves. If you can find either one in your outbound traffic, the claim is false and you should tell us (and then the world).

Level 1 — 60 seconds, no install

Your browser's developer tools show you every request the page makes, before HTTPS wraps it. That's all you need.

Open DevTools: press F12 (or Cmd+Option+I on a Mac) on the homepage, and select the Network tab.
Plant a canary: in the secret box, type something unique and searchable, e.g. MY-CANARY-PLAINTEXT-1234, and create the secret.
Inspect what was sent: in the Network list, click the secrets request (POST /api/v1/secrets) and open its Payload (Chrome/Edge) or Request (Firefox/Safari) tab.
Look for your canary: it isn't there. The request contains exactly eight fields — ciphertext, salt, nonce, verifier, directive, directive_signature, time_to_live_seconds, max_views — and nothing else. There is no plaintext field and no passphrase field to search. The passphrase shown to you after creation was generated locally and never appears in any request.

Why this is real evidence: DevTools records the request body exactly as the page handed it to the browser. If we were sending your plaintext, it would be sitting right there in the payload viewer.

Level 2 — full skeptic mode: watch the wire

DevTools trusts the browser to report what the page did. If you want to verify at the network boundary — every byte that actually left your machine, from any client — use an intercepting proxy that you control, such as mitmproxy (free, open source). You install your own certificate authority on your own machine, so the proxy can open the HTTPS tunnel and show you the true application payloads. You trust your CA, not us.

Install and start the proxy: mitmdump -w flows.bin --listen-port 8080
Route a browser through it and trust the mitmproxy CA (visit mitm.it through the proxy for per-OS instructions).
Plant the canary: create a secret at wundervault.com containing MY-CANARY-PLAINTEXT-1234. Copy the passphrase it shows you.
Stop the proxy and search everything that left:
grep -a "MY-CANARY-PLAINTEXT-1234" flows.bin → no matches.
grep -a "<the passphrase you copied>" flows.bin → no matches.
Inspect the create request (mitmweb --rfile flows.bin): the body carries an opaque base64 blob and random salt/nonce — the encryption demonstrably happened before the request existed.

We ran it ourselves — here's the transcript

Performed 2026-07-10 against production (v0.22.7), with mitmproxy 12.2.3 intercepting a Chromium session. Every request the homepage made during a secret creation, followed by the create request's complete field list:

canary planted: WV-CANARY-PLAINTEXT-20260710-DO-NOT-ENCRYPT-ME

requests intercepted (complete list):
  GET  https://wundervault.com/
  GET  https://wundervault.com/static/fonts/fonts.css
  GET  https://wundervault.com/auth/me
  GET  https://wundervault.com/static/fonts/530d036ba64a.woff2
  GET  https://wundervault.com/static/demo/my-secrets-light.png
  GET  https://wundervault.com/static/demo/agent-claude-code-light.png
  POST https://wundervault.com/api/v1/secrets
    fields: [ciphertext, salt, nonce, verifier, directive,
             directive_signature, time_to_live_seconds, max_views]
    ciphertext = 6ziG8k/85JEu2P7zSdeQqw5XFlo9Hzq8SVt7pGKXrhs…
    salt       = QdFfon/iJN24AHQZN98ChA==
    nonce      = 02iaQU/pfwbASgKa
    verifier   = LhNLlhtl/nknTUkwDkB8g12L++29C7VRQKEt0CRa2OE=

grep canary in all intercepted bytes ......... 0 matches
grep passphrase in all intercepted bytes ..... 0 matches

What this proves — and what it doesn't

This test proves that plaintext didn't leave your machine while you were watching. It does not rule out a server that behaves differently when unobserved — say, shipping altered JavaScript to targeted users on a targeted day. That deeper assurance is what third-party audits are for, and it's why we've made the two mitigations we can make today:

The code that touches your secrets is open source (AGPL-3.0) — the MCP server / local daemon and the browser crypto — so the client side is auditable, permanently, by anyone.
We publish what our protections don't do — see the security architecture and the Known Limitations section of the white paper. A security product that only tells you the good news is advertising, not engineering.

Run the test whenever you like — it's your network boundary. That's the point.

Want the full technical breakdown? Read the Security White Paper →