Why this checklist exists

In 2026, the dominant threat model for AI agent wallets is no longer "someone steals the private key". It is "an adversarial prompt convinces the agent to spend its budget on something the operator never authorized". The wallet's job is to make sure that even when the agent is wrong, the operator's exposure is bounded.

This 23-control checklist is what we run during production audits. It is built from incident post-mortems, security reviews of teams shipping agent payments at scale, and a few specific failures that became cautionary tales. Run it on your own integration. Re-run it quarterly. The threats evolve faster than most static security policies.

If you have not yet read the agent wallet security guide or the agent spend policy primer, those are useful priors. The controls below assume you understand the basic shape of a non-custodial agent wallet with API-side policy enforcement.

Section A: key management (controls 1 to 5)

Control 1: Each agent has its own wallet, not a shared one. The single biggest failure mode in production is workspace-shared keys. One compromised agent compromises every transaction that wallet ever makes again. Per-agent wallets bound the blast radius of any single agent's compromise to that agent.

How to verify: list your wallets, compare count to agent count. If the ratio is less than one wallet per agent, fix this before any other control.

Control 2: Private keys are stored in a key management service. Acceptable: AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault, hardware HSMs. Never acceptable: environment variables, code repositories, S3 buckets, plain databases, Slack messages, "we have a script that loads it".

How to verify: grep your repos for anything that looks like a private key. Check your config secrets for the same. There should be zero matches outside the KMS bindings.

Control 3: Key access requires a signed payment intent, not raw signing. The signing service should accept structured payment intents (counterparty, amount, purpose), evaluate the spend policy, and sign only if approved. A signing service that signs arbitrary bytes from anyone with the API token is a bypass of every policy you wrote.

Control 4: Keys are rotatable without losing wallet identity. The wallet address survives key rotation. This is what makes non-custodial smart contract wallets (account abstraction) safer than externally-owned accounts for production: rotating the signer does not change the address.

How to verify: walk through a key rotation in test. Confirm the wallet address is unchanged and historical transactions still reference it.

Control 5: Recovery is wired before deployment, not after compromise. The recovery path - guardian addresses, multi-sig recovery, social recovery, whatever you choose - is part of the initial wallet setup. Trying to add it after a compromise is asking to lose funds during the implementation window.

Section B: spend policy and limits (controls 6 to 11)

Control 6: Spend policy is enforced at the wallet API, not in the agent's planner. This is the single most important control on the list. Enforcement in the agent's prompt, system message, or planner means any prompt injection that bypasses the planner also bypasses the budget. Enforcement at the API means the policy is outside the agent's manipulable scope. See agent spend policy for the long form.

How to verify: try to make your agent spend over its policy via a crafted prompt. The wallet should refuse before the planner even sees a chance to think about it. If your agent spends, your policy is in the wrong place.

Control 7: Per-call and per-day limits are both set. A per-call limit alone can be defeated by an agent in a tight loop. A per-day limit alone fails to bound a single catastrophic transaction. Both, together, are the floor.

Control 8: Counterparty allowlist (or denylist) is enforced. The wallet should know which addresses are acceptable destinations. For high-stakes agents, an allowlist of pre-vetted counterparties is the right primitive. For lower-stakes agents, a denylist of known-bad addresses plus a small per-call ceiling is acceptable.

Control 9: Time-of-day windows constrain when the agent can transact. Most production agents do not need to pay between 03:00 and 06:00 local time. Constraining the window narrows the attack surface during low-attention hours. It also gives you a natural break to roll out policy updates.

Control 10: Policy changes are auditable and require operator authentication. Every change to a wallet's policy generates an audit log entry attributed to the human who made it. Changes from inside the agent are not allowed. Changes from outside the workspace are not allowed. Only authenticated operators of the workspace can change policy.

Control 11: Limit breaches are surfaced to operators in real time. A wallet rejecting a payment because it exceeded the spend policy is a signal worth attention. Three rejections in five minutes is a flag. Either the agent is stuck in a loop or someone is testing whether your policy holds. Surface the signal early.

Section C: prompt injection resilience (controls 12 to 15)

Control 12: The agent's tools are scoped to what the agent needs. A research agent that has a transfer_funds tool is a security failure waiting to happen. Tool scope is the first line of defense against prompt injection: an agent without the tool cannot be manipulated into using the tool. Audit your tool surface ruthlessly.

Control 13: Tool calls that involve money require structured arguments, not free text. A tool that takes {recipient: string, amount: number} is harder to manipulate than a tool that takes {instruction: string}. The wallet API itself should reject any payment intent missing structured fields. Free-form payment instructions are a prompt-injection on-ramp.

Control 14: The agent cannot read its own spend policy. Agents that can read the policy can craft payments that game it (large counter-policy transactions hidden in many small ones, for example). The agent should know it has a budget. It should not know the exact shape of the budget. Read-only "remaining budget today" is acceptable.

Control 15: Failed payment attempts are not retried autonomously. A spend policy rejection should pause the agent's transaction loop and surface a structured failure. Auto-retry on policy failure is how a single adversarial prompt becomes a denial-of-service against your wallet API. The agent should ask, not insist.

Section D: identity and counterparty trust (controls 16 to 18)

Control 16: The agent has a verified payment identity. A wallet alone is anonymous. A wallet plus a verified identity is something counterparties trust. Identity verification (domain, email, GitHub, KYB on the operator entity) is what unlocks larger payment ceilings with verified merchants.

Control 17: Counterparty verification is tiered. Unverified counterparties get a low per-call ceiling. Domain-verified ones get a higher ceiling. Repeat-transaction counterparties with good history get higher still. Trust is graded; the spend policy reflects the gradient.

Control 18: Dispute paths are documented and operational. When a transaction goes wrong - merchant did not deliver, agent paid the wrong address, double-charge - the path to dispute is documented and someone is on-call to walk through it. Disputes are off-chain; they need a human-driven process behind them.

Section E: monitoring and incident response (controls 19 to 23)

Control 19: Audit logs are queryable in under five minutes. Cold storage is not enough. During an incident, you need to answer "what did this agent do in the last hour" in under five minutes. If your log query takes longer, your audit logs are not audit logs - they are archived data.

Control 20: An anomaly alert fires on unusual transaction patterns. Definitions of "unusual" that catch real incidents: per-day spend exceeding 2x the rolling 30-day average; a new counterparty receiving more than $1; a per-call spend more than 5x the median; transactions outside the time window. Tune these from your own baseline; the specific thresholds matter less than that they exist.

Control 21: A runbook exists for a leaked API key. Revoke the key. Rotate. Audit transactions in the leak window. Decide whether the agent's wallet itself needs to be paused or revoked. Inform the operator. File the post-mortem within 72 hours. Most teams write this for the first time during the actual incident, which is the worst possible time. Write it during a quiet afternoon, run a tabletop exercise, then file it where the on-call rotation can find it.

Control 22: A runbook exists for a compromised agent. The agent's prompt is poisoned, it is spending in patterns it should not, the wallet is rejecting many payment intents. Pause the agent (per-agent wallet pause), investigate, decide between targeted fix and full revocation. Document what the agent did during the compromise window so the next incident is easier.

Control 23: Post-mortems are filed for every incident, even small ones. The fastest teams in production payments are the ones with the most systematically closed post-mortem action items. The point of the post-mortem is not blame; it is to learn. Every incident, however small, produces actionable lessons if you ask the right questions.

How to run this audit

The first time through this checklist will be slow. Plan for a half-day for a thorough first pass. Most teams find 4-8 controls that need work. Prioritize controls 1, 2, 3, 6 (per-agent wallets, KMS, signed intents, API-side policy) - those are the foundation controls; the others are reinforcements.

Re-run the checklist quarterly. Add controls as your threat model evolves. Subtract controls that have become irrelevant (we have removed several over the years as the supporting infrastructure has matured).

If you want a sanity check against an outside team, our security engineering group offers production audits. Reach out at [email protected] and we can scope the work.

The single most important fact

If you take one thing from this checklist, take this: the spend policy at the wallet API is the only safety primitive that survives prompt injection. Everything else on the list is defense in depth around that single fact.

Teams that get the wallet-API policy right and screw up everything else generally survive their first big incident. Teams that have a beautifully scoped tool surface but enforce the policy in the agent's system message lose money the first time someone tries hard.

Get control 6 right. Then work down the list.

What to do next

If you ran the audit and want to bring your stack up to the floor, the cleanest path is:

1. Move private keys behind a KMS (control 2).
2. Provision per-agent wallets through a workspace (control 1). Sign up free and you get this by default.
3. Set the spend policy at the wallet API (control 6). Copy from 12 production-ready spend policy templates.
4. Wire audit log access into a dashboard humans look at (control 19).
5. Write the leaked-key runbook and run the tabletop drill (control 21).

Five controls covered. Eighteen to go. Most teams ship the first five in a sprint and work the remaining eighteen as a quarterly hardening track. That is the right pace.