Setting AI Agent Spending Limits & Wallet Policies

When I first wired an autonomous agent to a funded wallet, I made the mistake almost everyone makes: I put the spending rules in the system prompt. "Never send more than $50," "ask me before anything large." It felt responsible. It was not. After the drainer incidents of 2026, I rebuilt every agent I run around one hard rule — spending limits belong in the wallet, not in the prompt. This guide walks through how to actually set them.

Why prompt-level limits fail

The clearest lesson of 2026 came on May 4, when an attacker drained roughly 3 billion DRB tokens — worth an estimated $150,000 to $200,000 — from an AI-linked wallet on the Base network. The exploit did not break any cryptography. The attacker replied to a post on X with an instruction hidden in Morse code, an AI agent decoded and re-posted it, and an automated trading bot treated that decoded text as an authenticated command and executed the transfer.

The wallet may well have had a prompt saying "never spend more than X." It did not matter. A prompt-level instruction is a suggestion to a language model, and prompt injection — indirect text the agent reads from a webpage, a tweet, an on-chain memo, an NFT it was gifted — routes straight around suggestions. If the only thing between an attacker and your funds is the model's willingness to obey its own instructions, you have no limit at all.

Real spending limits are enforced at the layer that signs transactions. The wallet, its policy engine, or the smart contract account checks every outgoing transaction against rules the model cannot see or edit. When I cap an agent's spend this way, an injected "send everything to 0xBad" simply fails at signing time. That is the entire game: move enforcement below the model.

The four policy primitives

Almost every serious agent wallet exposes the same four controls. Understanding them individually makes the dashboards later obvious.

Control	What it does	Enforced by	Typical use
Spending limit (budget)	Cap on total spend over a window (per run, per day, rolling)	Wallet policy engine	Bound blast radius of a full compromise
Per-transaction cap	Max value of any single transfer	Wallet / smart account	Stop one catastrophic tx
Whitelist (allowlist)	Restrict payees to approved addresses, tokens, chains, or contracts	Policy engine / session key	Prevent transfers to attacker addresses
Session key	Scoped, time-boxed, revocable signing key with baked-in limits	Smart account (ERC-4337 / ERC-7702)	Grant narrow autonomy without exposing the master key

These layer. A good setup is not "pick one" — it is a session key that can only touch whitelisted contracts, spend at most a per-tx cap, and burn through no more than a daily budget before it stops. Any single control can fail; the stack should hold.

Setting spending limits in Coinbase Agentic Wallets

Coinbase launched its Agentic Wallets on February 11, 2026, as MPC-secured wallets purpose-built for agents, with native x402 payment support and a policy engine bundled in. The security model here is deliberately asymmetric, and it is the part worth copying: the human operator configures limits, and the agent can view its limits but cannot change them.

Practical setup, from the wallet UI or SDK:

1. Create the wallet as the operator, not from inside the agent. The account you use to create it holds the policy authority.
2. Set a session cap — the ceiling on total spend across one agent run. This is your primary blast-radius control.
3. Set a per-transaction limit so no single payment can exceed a fixed value even within the session budget.
4. Constrain the payment surface. By default a Coinbase agentic wallet lets the agent pay for x402 services but not transfer funds to arbitrary addresses — keep that restriction on unless you have a concrete reason to widen it.
5. Fund minimally. Limits reduce risk; a low balance eliminates it. Top up as the agent works rather than parking a treasury in a hot agent wallet.

Because the limits live in Coinbase's infrastructure and not the model context, an injected instruction cannot lift the session cap. That is the design working as intended.

Configuring policies in Cobo

Cobo shipped its Agentic Wallet later in the wave, with MPC security and support for 80+ networks, and it leans hardest into structured policy. Beyond per-transaction limits and rolling budgets, Cobo exposes chain allowlists, token allowlists, contract restrictions, and approval flows, mapped internally to what it calls Budgets and Rulebooks.

The distinctive piece is the Pact system: each agent task requires explicit approval of four things — intent, execution plan, applicable policies, and completion conditions — before the agent proceeds. In practice I configure a Cobo agent like this:

• Define a Budget (rolling daily cap) and attach a Rulebook scoping which chains and tokens the agent may use.
• Add contract restrictions so the agent can call, say, one DEX router and one lending pool, nothing else.
• Route anything above a threshold through an approval flow — human-in-the-loop for the transactions that matter.

The value of the Pact model is that "what the agent may touch" is declared up front and enforced on-chain, not inferred from a prompt at runtime.

Building an address whitelist policy

A whitelist is the single highest-leverage control for the drainer threat, because the 2026 attacks all end the same way — funds moving to an address the operator never approved. If the agent physically cannot send to a non-whitelisted address, the injection has nowhere to land.

How I build one:

• Enumerate legitimate destinations first. For most agents this is short: a few DEX routers, a bridge contract, maybe one or two treasury addresses you control. Autonomous "send to any address the model decides" is the pattern to avoid.
• Whitelist contracts and tokens, not just addresses. Restricting the agent to a specific router and specific tokens blocks the classic "approve a malicious contract, then it pulls everything" flow — the exact mechanism behind the DRB drain, where a silent approval unlocked transfer permissions.
• Keep the allowlist editable only by the operator, out of model context, exactly like spending limits.
• Default deny. New destinations require a deliberate human addition. Convenience is not worth reopening the attack surface.

Session keys and per-transaction caps

Session keys are how you grant autonomy without handing over the keys to the kingdom. Enabled broadly by smart-account standards — ERC-4337 accounts and, since the Pectra upgrade, ERC-7702 smart EOAs — a session key is a temporary signing key with limits baked directly into it: an expiry, a spending cap, and an allowlist of contracts it may call.

The master key stays cold. The agent only ever holds a session key that, by construction, can spend at most $100 today, only on whitelisted contracts, and self-expires in 24 hours. Because the constraints are enforced by the smart account at validation time, a compromised agent cannot exceed them — and when the session ends, the authority evaporates with it. Rotate session keys on a short schedule; a stale, over-scoped one is a liability sitting on-chain.

Per-transaction caps pair naturally with this. A daily budget bounds the slow bleed; a per-tx cap bounds the single catastrophic transfer. Set both — they fail differently.

What to do if your agent is compromised

Assume it will happen and rehearse the response. When I suspect an agent is misbehaving or has been injected:

1. Revoke the session key immediately. With smart-account session keys this is one on-chain call and it instantly kills the agent's signing authority — the fastest containment you have.
2. Sweep remaining funds to a safe address you control from the master key.
3. Revoke token approvals. Drainers rely on lingering approve() allowances; use an approval-revocation tool to cancel them so a malicious contract cannot pull later.
4. Freeze budgets and pause approval flows in the dashboard (Coinbase limits, Cobo Rulebooks/Pacts) to stop any queued actions.
5. Read the transaction history to find the injection vector — a webpage, a social post, an on-chain memo — and add that source to your input filters before restarting.
6. Rotate everything and redeploy the agent on a fresh session key with tightened limits.

The whole point of the earlier layers is to make step 1 sufficient. If revoking one session key cannot fully contain the damage, your limits were too loose.

Policy setup checklist

• Spending limits and whitelists configured in the wallet, never in the prompt
• Per-run/daily budget set (blast-radius cap)
• Per-transaction cap set (single-tx cap)
• Payee/contract/token whitelist with default-deny
• Agent uses a scoped, time-boxed session key — master key stays cold
• Limits and allowlists editable only by the human operator
• Human-in-the-loop approval flow for transactions above a threshold
• Agent wallet funded minimally, topped up as needed
• Approval-revocation and fund-sweep procedure documented and tested
• Session keys rotated on a short schedule

Frequently Asked Questions

Can't I just tell the agent its spending limit in the system prompt? No. The 2026 Grok/Bankr incident is the proof: a prompt-level "never spend more than X" is a suggestion the model can be talked out of via prompt injection. Enforce limits at the wallet or smart-account layer, where the model cannot see or override them.

What's the difference between a spending limit and a session key? A spending limit is a budget rule the wallet enforces. A session key is a temporary, scoped signing key that carries limits (cap, expiry, contract allowlist) and can be revoked instantly. Use both — the session key is your fast kill switch, the budget bounds total exposure.

How much should I keep in an agent wallet? As little as the task needs. Limits reduce risk but a small balance eliminates most of it. Keep the treasury in cold storage and top the agent up incrementally rather than pre-funding it.

Coinbase or Cobo for policy controls? Both enforce limits below the model, which is what matters. Coinbase pairs MPC security with a clean session-cap/per-tx model and x402 payments; Cobo offers finer-grained Budgets, Rulebooks, contract allowlists, and its Pact approval framework across 80+ networks. Pick on network coverage and how much structured approval you want.

Conclusion

The uncomfortable takeaway from the drainer incidents of 2026 is that agent autonomy and unrestricted wallet access are incompatible. But the fix is not to abandon agents — it is to stop trusting the prompt and start enforcing rules where transactions are actually signed. Set a per-run budget, a per-transaction cap, a default-deny whitelist, and a scoped session key; configure them in the wallet's policy engine, not the model context; fund minimally; and keep a revoke-and-sweep procedure you have actually rehearsed. Do that, and a successful prompt injection becomes an annoyance instead of a headline.