Giving an AI agent a wallet feels like handing your car keys to something that occasionally hallucinates a left turn into a lake. The instinct to hesitate is correct. An agent that can spend funds is a new and attractive attack surface, and the failure modes are not theoretical. But the reason it is now reasonable to let an agent hold or move money is not that the models got trustworthy. It is that the security design around them matured to the point where the model's judgment stops being the thing that protects your treasury.
On 29 July 2026, MoonPay shipped PayBox, a non-custodial vault that lets an AI assistant execute crypto transactions using MPC key management and passkey approval. It is worth studying because it demonstrates the core principle in production: the agent proposes, and a separate, deterministic layer decides. This post lays out the threat model plainly, then the controls that contain it, layer by layer. It is written for founders and CTOs deciding whether to build an agent wallet, and who to trust with it.
The threat model, stated plainly
Before any control makes sense, name what you are defending against. Agent wallet security has four core threats, and every good design maps back to them.
- A compromised or hallucinating agent. The model decides, incorrectly, to send funds somewhere it should not. No malice, just a wrong output that happens to move money.
- A prompt-injection attack. Hostile text arrives inside the agent's context, from a scraped web page, an email, a tool result, or a document, and instructs the agent to drain the wallet or change a recipient. The agent, being helpful, complies.
- A leaked or stolen key. The signing key is exposed through a bug, a bad dependency, a compromised server, or an insider. Whoever holds it can sign anything.
- A malicious or buggy destination. The agent interacts with a contract designed to steal, or one that behaves unexpectedly and drains more than intended.
The mistake most teams make is trying to fix all four with a smarter prompt. You cannot prompt your way out of a security problem. The fix is architectural.
The controls, layer by layer
Defense in depth means no single failure loses the funds. Each layer assumes the one above it failed.
Non-custodial key management (MPC and TSS). Start where theft starts: the key. Multi-party computation and threshold signature schemes split the signing key into shares held by different parties, so no single machine ever holds a complete key. There is no single file to steal and no seed phrase in an environment variable, and a threshold of shares must cooperate to sign. This removes the single point of theft that makes a leaked key catastrophic.
Smart-contract wallets with account abstraction. Instead of a plain externally owned account, the wallet is a smart contract that enforces its own rules on-chain. Account abstraction lets you encode spending logic, approval requirements, and recovery into the account itself, where an attacker cannot bypass it with a merely valid signature. The rules live at the contract level, tamper resistant and independent of your backend.
Session keys with tight scopes. Rather than give the agent broad authority, issue a session key: a temporary, narrowly scoped credential that can only do specific things, for a specific window, up to a specific amount. A session key might allow swaps on one protocol, under a cap, expiring in an hour. If it leaks, the blast radius is bounded by its scope, not your whole balance.
Per-transaction and per-period spending limits. Cap the size of any single transaction, and cap the total over a rolling window: per hour, per day, per week. A hallucination or a hijack can then move only a bounded amount before it hits a wall. Limits are enforced by deterministic code, never by the model, because they must be predictable.
Allowlists and denylists. Constrain where funds can go. An allowlist of approved destination addresses and contracts means the agent can only transact with pre-vetted counterparties, while a denylist blocks known-bad addresses. For many products, an allowlist alone eliminates the entire "drained to an attacker's wallet" class of failure, because the attacker's address was never on the list.
Transaction simulation before signing. Before anything is signed, build the transaction and simulate it against current chain state. Simulation reveals the actual effect: the real recipient, token, amount, and balance change. It catches a wrong recipient, an unexpected token approval, a bad slippage figure, or a contract that would pull more than intended. This is the single most underrated defense against both hallucinated and injected transactions, because it checks reality, not intent.
Human-in-the-loop approval for high-value actions. Above a threshold, or for anything unusual, pause and require a human to confirm with a passkey (Face ID, Touch ID, or a hardware key). The agent handles the routine, in-policy flow autonomously; a person authorizes the consequential moves. PayBox uses exactly this passkey-gated pattern.
Rate limits and a circuit breaker. Cap the frequency of actions, and add a kill switch. If activity spikes abnormally, if the loss over a window crosses a threshold, or if something looks wrong, the circuit breaker halts all signing instantly and one command freezes the wallet while you investigate. Every serious system needs an off switch a human can reach fast.
Multisig for treasury. Operational funds and treasury funds should not live together. Keep the bulk of the value in a multisig that requires multiple independent human signers to move, entirely outside the agent's reach. The agent works from a small, refillable operating balance, so even a total compromise cannot touch the treasury.
Full audit logging. Record every intent, policy decision, simulation result, signature, and settlement. When something goes wrong, and eventually it will, you need a complete, tamper-evident trail to understand what happened and to prove what did not. Logging is also how you detect slow, low-value abuse that stays under your limits.
Prompt injection is a policy problem, not a model problem
The defense against prompt injection deserves its own statement, because it is the threat founders worry about most. You do not defend against it by asking the model to ignore malicious instructions. You defend against it by making the model's output non-authoritative. The agent's proposal is just a request, and a deterministic policy engine, plain code with no language model in it, decides whether that request is allowed against your limits, allowlists, and thresholds. If injected text tells the agent to send everything to a new address, the agent may well try. The policy engine sees an unlisted destination over the cap and refuses. The intelligence proposes. The guardrails dispose.
Controls mapped to the risk each mitigates
| Control | Primary risk it mitigates |
|---|---|
| MPC and TSS key management | Leaked or stolen key; single point of theft |
| Smart-contract wallet with account abstraction | On-chain rule bypass; unenforced limits |
| Session keys with tight scopes | Over-broad delegation; leaked-credential blast radius |
| Per-transaction and per-period limits | Compromised or hallucinating agent draining funds |
| Allowlists and denylists | Funds sent to an attacker or malicious contract |
| Transaction simulation before signing | Wrong recipient, token, or amount; malicious destination |
| Human-in-the-loop passkey approval | High-value mistakes and hijacked large transfers |
| Rate limits and circuit breaker | Rapid automated draining; runaway agent loops |
| Multisig treasury separation | Total agent compromise reaching core funds |
| Full audit logging | Undetected abuse; no forensic or compliance trail |
Defense in depth: a build checklist
- Split the signing key with MPC or TSS so no machine holds a whole key.
- Deploy the wallet as a smart-contract account that enforces rules on-chain.
- Issue scoped, time-boxed session keys instead of broad authority.
- Set per-transaction and per-period spending caps in deterministic code.
- Restrict destinations and contracts with an allowlist, and block a denylist.
- Simulate every transaction and verify its real effect before signing.
- Route high-value or unusual actions to human passkey approval.
- Enforce rate limits and wire a one-command circuit breaker.
- Keep treasury in a separate multisig, outside the agent's reach.
- Log every intent, decision, and signature to an audit trail.
How we build this at Anointed Coder
Anointed Coder builds secure agent wallets and, just as importantly, the policy layer around them. Our blockchain development team handles the on-chain side: smart-contract wallets, account abstraction, session keys, and MPC signing. Our DeFi development work covers the transaction building, simulation, allowlists, and settlement logic that keep an agent inside its scope while it interacts with live protocols. The deterministic policy engine that neutralizes prompt injection is code we write and own with you, never a prompt we hope holds.
We work in milestones, so you fund the next phase only after reviewing the last one. You get a weekly staging deployment to test against, and you own the complete source code with no lock-in. A hardened agent wallet with a real policy layer, simulation, and human approval typically runs from a few weeks to a couple of months and lands in the low-to-mid five figures, depending on the chains, the custody model, and how much treasury and compliance tooling you need. We scope it honestly before you commit.
If you are weighing whether an agent should hold funds at all, these three reads go deeper: how to build an AI crypto wallet, the anatomy of AI agent payment systems, and building web3 agents that transact. For the agent reasoning itself, our AI and LLM development team builds the model side to feed clean, structured intents into the policy engine.
To scope a build, contact us or reach out on WhatsApp, and we will map your threat model to the controls above before writing a line of code.
Recap: an agent wallet is safe not because the model is trustworthy, but because the model's output is never authoritative. Non-custodial keys remove the single point of theft. Spending limits, allowlists, and delegated session keys bound what any single failure can cost, simulation and passkey approval catch mistakes before they settle, and a deterministic policy engine, not a prompt, is what stops prompt injection. Build all of it, and letting an agent spend money stops being a gamble and becomes an engineered, auditable system.