● CLIENT.ENCRYPTED ● SERVER.BLIND ● AGENT.NATIVE
v0.21.9-a0b8e388
// AGENT-NATIVE SECRETS
▣   AGENT-NATIVE SECRETS INFRASTRUCTURE

Give AI agents
production access without exposing secrets.

Wundervault injects credentials into the agent’s runtime — never into the chat. Claude, Cursor, OpenClaw, Hermes, and your own agents can deploy, call APIs, and query databases without ever seeing plaintext keys.

▸ START FREE ▸ LEARN MORE
● CLAUDE CODE ● OPENCLAW ● HERMES ● CURSOR ● ANY AGENT VIA HTTP / MCP
▣ NEW.SECRET
■ SECRET
aes-256-gcm · pbkdf2 0 / 65,536
■ EXPIRES
↺ burns on first read

Or share a one-time secret — a link + passphrase that self-destructs after a single read.

01▸ THE STATUS QUO

Your agent has root. Your .env file is a hostage situation.

Most teams hand AI agents the same long-lived credentials a human uses — pasted into chat, stored in .env, never rotated. One bad prompt, one leaked log, and the keys are out.

✗ THE .ENV STATUS QUOtoday, everywhere
.env filessit on disk in plaintext✗
API keyspasted into chat, logged forever✗
Agentsget long-lived root credentials✗
No auditwho ran what · with what · when?✗
No scopeone leak = total compromise✗
✓ THE WUNDERVAULT WAYstarting today
Encrypted at restAES-256-GCM · client-side keys✓
Injected at runtimeagent sees an env var, not a key✓
Scoped per agentClaude can deploy; Cursor cannot✓
Append-only audit logevery read · every revoke · recorded✓
Revocable in 1spull a token; the door closes immediately✓
02▸ HOW IT WORKS

One token. One scope. One short life.

The agent asks. The MCP server injects. The credential never crosses the model boundary.

AI AGENT
claude · cursor · openclaw · hermes
▸
WV MCP SERVER
local · uses your scoped agent key · vault_exec
▸
WUNDERVAULT VAULT
remote · server-blind · stores only ciphertext
▸
SECRET INJECTION
decrypted locally · into one command
▸
YOUR SERVICE
npm · aws · github · ssh · pg
▸
✗   PLAINTEXT NEVER ENTERS THE CHAT CONTEXT   ✗
03▸ REAL WORKFLOWS

What this actually looks like.

Three agents, three jobs, three different keys — each agent gets only the scope its work requires.

● PUBLISH AGENT → NPM PUBLISH · TOKEN INJECTED PER-COMMAND
vault_exec(entry_id: NpmToken, command: "npm publish --access public")
✓ ALLOWED
NpmToken
✗ BLOCKED
StripeLiveKey
ProdDbPassword
✓ Published v1.6.2 · NPM_TOKEN injected into one command only
● OPS AGENT → QUERY PROD OVER SSH
vault_exec(entry_id: ProdDbPassword, remote_host: prod, command: "curl -u admin:$DB_PASSWORD …")
✓ ALLOWED
ProdDbPassword
ProdSshKey
✗ BLOCKED
StripeLiveKey
NpmToken
✓ 14 rows returned · $() / backticks hard-blocked before decrypt
● DEPLOY AGENT → RSYNC TO PROD
vault_rsync(ssh_key_entry_id: ProdSshKey, local_path: ./dist/, remote_host: prod, remote_path: /var/www/html)
✓ ALLOWED
ProdSshKey
✗ BLOCKED
ProdDbPassword
StripeLiveKey
✓ Synced · key written to tempfile, deleted after transfer
04▸ WHAT THE SERVER SEES

Ciphertext, a salt, a nonce, and a one-way verifier. That’s the whole row.

Encryption happens in your browser via the Web Crypto API. The server stores only AES-256-GCM ciphertext plus the values needed to authorize retrieval — it cannot derive the key, the passphrase, or the plaintext.

▸ DATABASE ROWnothing readable
CIPHERTEXTAES-256-GCM · ≈ 48 bytes
SALT16 bytes · per-secret
NONCE12 bytes · per-op
VERIFIERSHA-256(content key) · one-way
TTLburn @ now+24h
KEYNEVER — derived locally from passphrase
PLAINTEXTNEVER — never leaves your device
▸ CRYPTO PRIMITIVES
cipherAES-256-GCM · authenticated encryption · Web Crypto API
kdfPBKDF2-HMAC-SHA256 · 600,000 iterations · per-secret salt
nonce12-byte random · never reused · crypto.getRandomValues
signingEd25519 · onboard script verifies its own signature
transportTLS · HSTS · strict CSP · preload list
key.storageAccount Secret · 128-bit in browser localStorage · never sent
auditappend-only log · agent · purpose · IP · timestamp · outcome
05▸ INSTALL · 90 SECONDS

Install, onboard, wire the MCP config. Then your agent has scoped vault tools.

The onboard script verifies its own Ed25519 signature before running and hard-blocks pipe execution. Credentials are registered with a local daemon and stored in an encrypted profile file — no plaintext on disk.

$ npm install -g @wundervault/mcp-server
$ curl -fsSL https://wundervault.com/onboard -o onboard.py
$ python3 onboard.py "$SETUP_URL"
✓ onboard.py signature verified · Ed25519
✓ credentials registered with local daemon
# add wundervault to mcpServers in ~/.claude.json
$ claude → vault_exec(entry_id: NpmToken, command: "npm publish")
✓ secret injected into agent runtime
✓ action audited · append-only log
✗ plaintext never exposed
▸ WHAT JUST HAPPENEDstep-by-step
  1. You registered the agent in the dashboard and clicked 📨 SEND on the secrets it should see.
  2. The onboard script verified its Ed25519 signature, exchanged credentials, and burned the one-time setup URL.
  3. Your agent called vault_exec. The MCP server hard-blocked shell escapes before decrypting.
  4. The MCP server injected the secret as a named env var — stripped sensitive parent-env keys, zeroed the buffer after spawn, scrubbed output.
  5. The model received only a confirmation string. Plaintext never touched the conversation.
Tier 2 entries add a WebAuthn gate — the agent gets 403 until you biometric-unlock in the dashboard. Session auto-locks after 3 uses or 5 min idle.
06▸ THREAT MODEL · WHITEPAPER §1, §9

What this fixes — and what it doesn’t.

Calibrated from the security whitepaper. §1 names the threat classes Wundervault is designed against; §9 names the limits inherent to browser-based crypto, endpoint trust, and revocation semantics.

✓ WUNDERVAULT PROTECTS AGAINST
✓passive DB compromise — dumps are ciphertext + salt + nonce only
✓network interception — TLS + client-side encryption before transit
✓credential brute force — PBKDF2-HMAC-SHA256 · 600,000 iterations
✓agent credential theft — setup link is single-use, HMAC-only on server
✓prompt injection → shell exec — $() / backticks / eval blocked before decrypt
✓cross-agent secret sharing — each agent has its own scoped vault
✓over-permissioned agents — only secrets you explicitly send are visible
✓long-lived tokens after staff turnover — revocation is immediate (401 next request)
✗ WUNDERVAULT WILL NOT PROTECT AGAINST
✗active server compromise serving malicious JS — browser-crypto trust limit (SRI helps)
✗endpoint compromise of your device — malware, keyloggers, screen capture
✗post-reveal capture — screenshots / copies / photos after a secret is shown
✗agent context persistence — revocation is forward-looking, not retroactive
✗SSH keys stored outside the vault — use ssh_key_entry_id to keep keys inside
✗intentionally authorized destructive actions — the agent is doing what you asked
✗metadata — secret existence, TTL, and access timestamps are visible to the server

Log in to continue

Create a free account or log in to save secrets to your zero-knowledge vault.

Don't have an account? Create one free