▸ Use case · verified end-to-end

Agent wallets: x402 payments where the agent never holds the key

Protocols like x402 let an AI agent pay for an API call over HTTP. That makes the wallet key the highest-stakes secret an agent can touch — it's not readable data, it's spendable money. Our answer: the agent asks the vault to sign, a human approves the spend, and the key never enters the model's context. We ran it for real. Here's the run.

The verified run

A throwaway wallet key was generated by the human and stored in Wundervault at tier 2. The agent saw only the public address — never the key, not even at generation.
The agent requested a paid resource → HTTP 402 with x402 payment requirements ($0.01 USDC, Base Sepolia, 60-second validity window).
The agent called vault_exec to sign → denied (403). The attempt landed in the audit log with the agent's stated purpose, and the owner got an approval email.
The human approved that one use from the dashboard (biometric check inline). The vault injected the key into a local signing subprocess, zeroed the buffer, and returned only the signed X-PAYMENT header.
Retry with the header → HTTP 200, paid content returned. Settled on-chain: Base Sepolia tx 0x1c434bbc1cf604a1cfee2d9d9b41c7f3eae66d25e17740f90e3edd601148ad3c, merchant balance up exactly $0.01 USDC.

Independent check afterward: the EIP-712 signer recovered from the signature matched the wallet address exactly, and the key appears nowhere in anything the agent ever saw — you can grep the session for it.

The moment that matters is the 403. The vault refused the agent until the human said yes. Approval is scoped to one (agent, secret) pair — once, or for a 15/60-minute window — and single-use approvals burn after exactly one signature. A prompt-injected agent can't spend what it can't sign.

Why this shape

Payment gateways that hold your wallet key server-side move the risk, they don't remove it. Here the key is encrypted client-side, our server can't read it, and plaintext exists only inside a local signing subprocess for the duration of one command — the same vault_exec pattern agents already use for API keys and SSH.

What we don't have yet

Honest status: compatible, not productized. A wallet key is a vault secret like any other, and the signing flow above works today. What doesn't exist yet is payment-specific policy — spend caps per window, payee allowlists, per-payment audit fields. If agent payments are your use case, tell us — this is exactly the direction the design points.

▸ 5-MINUTE QUICKSTART ▸ THE MCP SECRET VAULT

Choosing how to handle agent credentials in general? See .env files vs. secret managers vs. a zero-knowledge vault.