Agent Wallet Threat Model: Keys, Sessions, Budgets, and Receipts
An agent wallet connects payment authority to prompts, browser state, tool calls, account sessions, and receipts. Each connection needs a limit.
The agent drafts. It never signs. The safer architecture from the article: intent and signing authority are separated, with limits enforced before payment.
Data behind this diagram
| Failure | Effect | Caught by |
|---|---|---|
| PROMPT INJECTION | asks the agent to pay the wrong party | policy check + approval |
| MERCHANT SESSION LEAK | identity crosses unrelated tasks | one wallet per task compartment |
| WALLET ADDRESS REUSE | links agent tasks on a public ledger | one wallet per task compartment |
| BROAD API KEY | creates spend surfaces without review | hard maximum before the workflow starts |
Privacy frame: agent payments are authority systems. The useful question is not whether a protocol is modern. The useful question is who can spend, who approves, who settles, who stores logs, and how quickly the user can revoke it.
Primary sources
- AP2 v0.2 specification
- Coinbase x402 docs
- Stripe machine payments docs
- OWASP prompt injection guidance
- Ethereum privacy documentation
Main assets
Money is only one asset. An agent payment can expose account identity, purchase intent, wallet history, receipts, API keys, merchant sessions, and the prompts that explain why the payment happened.
Separate payment intent from signing authority. AP2 does this with checkout and payment mandates that other roles verify. The same boundary can be simpler: let the agent prepare a request, then let deterministic code or a person approve it.
Main failure modes
The worst design puts seed material, browser automation, untrusted web content, and open-ended spending authority in one runtime. OWASP warns that indirect prompt injection can arrive through websites or files and trigger unauthorized tool use or commands.
A second failure is receipt sprawl. If receipts, prompts, files, and identity documents land in one store, the payment trail becomes a map of the user.
- Prompt injection asks the agent to pay the wrong party.
- A merchant session leaks identity across unrelated tasks.
- Wallet address reuse links agent tasks on a public ledger.
- A broad API key lets the agent create spend surfaces without review.
Safer architecture
Use a separate wallet, card, or balance for each task compartment. Keep signing authority outside the browsing and prompt runtime. Put a deterministic policy check between the agent request and the payment tool.
Require human approval for high-risk payments. For repeat low-value work, enforce amount, merchant, frequency, instrument, and expiry limits. AP2 autonomous mandates use signed constraints; x402 instead lets a client construct and send payment data during an HTTP request. Neither protocol removes the need to limit the wallet that the client can use.
Minimum controls
- No seed phrases in the agent runtime.
- One wallet, card, or balance per task compartment.
- Hard maximum amount before the workflow starts.
- Human approval above a tiny threshold.
- Receipt logs without prompts, private files, or secrets.
Use the Agent Money matrix and the agent-money directory filter to compare current providers.
Frequently Asked Questions
Should an AI agent hold wallet keys?
Usually no. The safer pattern is for the agent to draft a payment request and for a separate wallet, policy engine, or human to approve and sign.
What should an agent payment wallet log?
Log merchant, amount, task, instrument, approval result, and receipt reference. Avoid storing prompts, private files, seed material, bank data, or unrelated identity data in the same log.