How Programmable Wallets Can Limit Autonomous Spending

• A programmable wallet is a wallet whose spending rules are enforced in code at the signing layer, not by the software asking for the money. The agent cannot talk its way past a limit it does not control.
• The core controls are per-transaction caps, rolling session and period caps, counterparty allowlists, contract and function scoping, expiry windows, velocity limits, and a kill switch.
• Two architectures dominate in 2026: smart-account session keys (ERC-4337 plus ERC-7715 permission grants) and custodial or MPC wallets with a server-side policy engine, such as Coinbase’s Agentic Wallets, launched 11 February 2026.
• Limits contain damage; they do not prevent compromise. The May 2026 Grok/Bankr incident drained roughly $174,000 not by breaking cryptography but by exploiting a permission rule that granted elevated status to any wallet holding a particular NFT.
• For EU firms, agent spending controls are becoming an audit artefact. The MiCA transitional period closed on 1 July 2026, the AMLR names crypto-asset service providers as obliged entities from July 2027 ahead of AMLA direct supervision in 2028, and Travel Rule data obligations attach to transfers regardless of whether a human or a model initiated them.

What “Autonomous Spending” Actually Means

Autonomous spending is any payment initiated and settled by software without a human approving that specific transaction. The human sets the objective and the budget; the agent decides the individual purchases.

This is narrower than it sounds. A trading bot executing a pre-signed strategy is not autonomous in the relevant sense, its action space was fixed in advance. An agent that reads a webpage, decides it needs a paid data feed, pays for it, and then buys three more is. The distinguishing feature is that the set of possible payments was not enumerable when the human granted authority.

That is exactly what breaks conventional wallet security. Traditional wallet UX assumes a human reads a transaction and clicks approve. Remove the human and every protection that depended on that click disappears at once. The industry’s answer has been to move the check from the human eye to the wallet itself.

Buy bitcoin and stocks. Signup to Coinbase today

Three things made this urgent. Stablecoin rails made micropayments viable, so an agent can pay $0.003 for an API call without the fee exceeding the purchase. The x402 protocol, which revives the dormant HTTP 402 “Payment Required” status code so a server can quote a price and a client can settle it inside the same request, gave machines a native way to pay for resources. And in 2026 the major wallet providers shipped infrastructure specifically for agents.

Why Unlimited Agent Spend Is a Real Risk

The 4 May 2026 Grok wallet incident is the clearest case study, because nothing about it required breaking a cryptographic primitive.

An attacker sent a “Bankr Club Membership” NFT to a wallet linked to Grok’s account on X. In Bankr’s permission model, simply holding that NFT conferred “Executive” status, which lifted the wallet’s standard transfer limits and swap restrictions. The attacker then replied to Grok asking it to translate a Morse code message. Grok decoded it publicly. The decoded text was an instruction to send three billion DRB tokens to a specified address. Bankr’s automation treated the model’s public output as an authenticated instruction and signed the transfer, roughly $174,000 at the time. Around 80% was later returned.

Three failures stacked. A permission rule granted privilege based on an asset anyone could send unsolicited. A model treated attacker-supplied text as instruction rather than data, the canonical prompt injection failure. And an execution layer treated model output as authorisation. Any one control would have blunted it: a transfer cap that could not be raised by an inbound token, an allowlist that rejected an unknown destination, or a human-approval threshold above a set value.

This is not an isolated pattern. Security researchers tracking agent deployments through 2026 have flagged prompt injection as the leading attack class against agent wallets, with tool-use abuse and unauthorised signing following. The attack surface is the instruction channel, and the instruction channel is a language model that cannot reliably distinguish a user’s intent from text it encountered while working.

The conclusion is uncomfortable but correct: you cannot secure an agent by making it smarter about what it should spend. You secure it by making the spending decision unavailable to it.

What Is a Programmable Wallet?

A programmable wallet is a wallet whose authorisation logic is expressed as machine-enforced rules that sit between the request to sign and the act of signing.

Contrast this with an externally owned account, a standard private-key wallet. An EOA has exactly one rule: whoever holds the key can move everything. There is no notion of “up to 50 USDC per day” because there is no code path between key and signature where such a rule could live. Give an agent an EOA private key and you have given it your entire balance, permanently, with no ability to narrow, revoke or observe.

Programmable wallets insert a policy layer. When the agent requests a transfer, the request is evaluated against declared rules before any key material is used. Rules that pass produce a signature; rules that fail produce a rejection the agent cannot appeal.

The future of finance is here. Trade crypto and more

The critical design property is independent evaluation. The policy engine decides based on the transaction itself, destination, amount, asset, contract, calldata, not on what the agent claims it is for. A prompt-injected agent will produce a confident, well-argued rationale for a malicious transfer. The policy engine never sees that rationale.

Account abstraction means the account is a smart contract rather than a keypair, so it can implement arbitrary validation logic. ERC-4337 is the Ethereum standard that made this work without changing the protocol itself. Session key is a short-lived, narrowly scoped signing key that can act on the account’s behalf within limits, while the master key stays offline. MPC (multi-party computation) splits a key into shares held by separate parties, so no single party, including the agent, can sign alone.

The Seven Controls That Actually Constrain Spend

Every credible agent wallet product in 2026 assembles some subset of the same primitives. Understanding them individually is more useful than comparing vendor feature lists.

1. Per-transaction cap: A hard ceiling on any single transfer. Cheap to implement and the highest-value control, because most catastrophic losses are one large transaction rather than many small ones.
2. Session and period caps: A rolling budget, i.e. 200 USDC per session, 1,000 USDC per day,  that survives across transactions. This stops the death-by-a-thousand-cuts failure where an agent stuck in a loop makes ten thousand legitimate-looking micropayments.
3. Counterparty allowlists: The wallet may only send to listed addresses. Extremely effective against exfiltration, since an attacker’s address is by definition not on it. The cost is flexibility, agents paying arbitrary merchants must fall back to denylists and screening.
4. Contract and function scoping: Narrower than an address allowlist: permission to call this contract, this function, with these parameter bounds. A grant might allow transfer on USDC but not approve, closing the common drainer pattern of an unlimited allowance to a malicious spender.
5. Time bounds and expiry: A permission that lapses in 24 hours limits the blast radius of a leaked session key to 24 hours. Permissions that never expire accumulate into standing authority that turns a minor compromise into a major one.
6. Velocity and rate limits: Caps on transaction count per interval, independent of value. These catch runaway loops and drain attempts that stay under per-transaction thresholds.
7. Escalation thresholds and kill switches: Above a defined value, route to a human rather than reject. Separately, an owner-held ability to revoke all outstanding grants at once, the control most often designed last and needed most urgently.

Practical Framework Layers by Risk Tier

A tiered spending-limit framework for AI agent wallets.

The point of the tiering is that most agent activity is Tier 1, where the value at risk per action is trivially small and full autonomy is safe. Problems arise when teams grant Tier 3 authority because a Tier 1 workflow occasionally needs it.

How the Limits Get Enforced: Two Architectures

The controls above are a wish list until something enforces them. In 2026 there are two mainstream enforcement models, and the difference determines your trust assumptions.

Smart-Account Session Keys: Onchain Enforcement

Here the account is a smart contract. The owner authorises a session key with an encoded scope, and the contract rejects anything outside it. Enforcement is onchain and does not depend on any server behaving correctly.

ERC-7715 standardises the request side. It introduces a JSON-RPC method, wallet_grantPermissions, through which an application asks a wallet for a scoped, time-bounded delegation, spend up to a stated amount, against a stated contract, until a stated expiry. Once granted, the application acts inside that envelope without a per-transaction popup while the wallet enforces the boundaries. ERC-7715 does not strictly require ERC-4337, but it fits most naturally inside a smart account, where session keys can be authorised without exposing the master key.

New Scam Prevention Course. Never make a rushed crypto decision again.

These permission systems support attenuation: a grant can be narrowed before being passed to a sub-component. An orchestrator holding a 500 USDC weekly permission can hand a sub-agent a 10 USDC daily slice that cannot be widened. If the sub-agent is compromised, the loss is bounded by the narrowest grant in the chain.

Trade-offs: enforcement is trust-minimised and publicly verifiable, but rules are only as expressive as the contract’s validation logic, changes cost gas, and cross-chain coordination is manual.

Mpc or Custodial Wallets With a Policy Engine: Offchain Enforcement

Here the key is split or held in secure infrastructure, an HSM or trusted execution environment, and a policy engine evaluates every signing request before a signature is produced. Coinbase’s Agentic Wallets, launched 11 February 2026, are the reference implementation: each agent gets an MPC-secured wallet with programmable session caps and per-transaction limits, gasless settlement on Base, and native x402 support, with policies expressed as declarative rules, address filters, allowlists, value caps, message guards, enforced every time the wallet signs.

The security argument is that the agent never holds a private key at all. It holds an API credential that lets it request a signature. Compromise the agent and you inherit its request rights, which are already bounded, rather than its key.

Trade-offs: policies can be arbitrarily expressive and updated instantly across chains, and screening (sanctions, risk scoring) can be integrated inline. But enforcement depends on the provider’s infrastructure being correct and available, and you are trusting an operator rather than a contract.

Onchain vs offchain enforcement of agent spending limits.

Neither is strictly better. Mature deployments frequently use both: onchain caps as a floor that no server misconfiguration can lift, plus a policy engine for screening and dynamic rules.

Where Limits Meet Real Payment Rails

x402 and Machine-To-Machine Payments

x402, released by Coinbase in May 2025, is the protocol most closely associated with agent spending, and it is worth being precise about what it does and does not control. A server replies to a request with a 402 and a price quote; the client returns a signed payment payload in an HTTP header, typically USDC; a facilitator verifies and settles it onchain and the resource is served. It handles the mechanics of paying. It does not decide whether the payment should happen.

In crypto, one bad click is final. Learn to verify before you lose.

That decision belongs to the wallet. If the policy layer rejects the payment, over the per-call cap, unfamiliar recipient, daily budget exhausted, the flow simply fails and the agent must handle it. This is the correct separation: the payment protocol should be dumb, and the authorisation layer should be where the judgment lives.

The characteristic x402 risk is not a single large payment but volume. A pricing bug, a retry loop, or a hostile server quoting escalating prices can generate thousands of individually trivial payments. Per-transaction caps are useless here. Period caps and velocity limits are the controls that matter.

Card Rails and the Agentic Commerce Protocols

Not all agent spending is onchain, and the card networks have built parallel constraint systems worth understanding for comparison.

Google’s Agent Payments Protocol (AP2), released in September 2025 with a broad partner set including Mastercard, American Express, PayPal and Coinbase, is an open, payment-method-agnostic framework built on W3C Verifiable Credentials. Its central idea is the signed mandate. Intent, Cart and Payment mandates that cryptographically record what the user authorised, what the agent assembled, and what was ultimately charged. That mandate is effectively a portable, verifiable spending limit.

Mastercard Agent Pay, announced 29 April 2025 with Microsoft, IBM and Braintree, issues Agentic Tokens as an extension of the Mastercard Digital Enablement Service. Visa’s Trusted Agent Protocol, announced September 2025, introduces a Visa-issued Verified Agent ID plus a consent record signed by the consumer’s issuing bank. Both are network-specific schemes that can plug into AP2 as funding instruments.

The structural similarity to onchain permissions is striking. Both worlds converged on the same answer: a signed, scoped, verifiable grant of limited authority, checked by a party that is not the agent.

Where Do Programmable Limits Fail?

Limits bound losses. They do not prevent compromise, and treating them as prevention is the most common mistake.

• The instruction channel is upstream of the wallet. Prompt injection compromises what the agent wants to do. A wallet enforcing a 100 USDC daily cap on a fully compromised agent loses 100 USDC per day, indefinitely, and every transaction is technically authorised. Limits convert a catastrophic loss into a recurring one. It is genuinely valuable, but not a fix.
• Permission logic is itself an attack surface. The Grok/Bankr case is the definitive example: the limits worked as written, and the rule that granted elevated permissions to any NFT holder was the vulnerability. Any rule that raises privilege based on an attacker-influenceable condition, token balance, NFT ownership, an inbound transfer, is a bypass waiting to be found.
• Allowlisted counterparties can turn hostile. An allowlist proves you meant to transact with an address. It says nothing about whether that address is still safe, upgradeable contracts and compromised vendors are both allowlist-resident.
• Denominations drift. A cap expressed in token units rather than fiat value can become far larger than intended after a price move.
• Delegation chains dilute intent. Multi-agent systems pass permissions between components, and every hop is a chance to widen scope through misconfiguration. Attenuation must be enforced, not assumed.
• Gas and fees sit outside most caps. Value caps govern the transfer amount, not execution cost. An agent looping on failing transactions can burn real value while never breaching a spend limit.
• The kill switch may not work under load. Revocation requiring an onchain transaction competes for blockspace precisely when everyone else is also trying to exit. Test it under adverse conditions, not on a quiet afternoon.

The Compliance Layer: Why Limits Are Becoming an Audit Artefact

For any regulated entity, agent spending controls are drifting from an engineering preference toward a documented control expected by supervisors.

• MiCA: The EU’s transitional period ended on 1 July 2026. From that point, providing crypto-asset services in the EU without CASP authorisation breaches EU law, and authorised CASPs are expected to have fully implemented AML/CFT processes, due diligence, transaction monitoring and Travel Rule handling. A firm whose agents can initiate transfers needs those transfers inside the same monitoring perimeter as human-initiated ones, and needs to be able to show it.
• AMLR and AMLA: The EU’s Anti-Money Laundering Authority is in its build-out phase: it is issuing Level 2 and Level 3 measures through 2026-2027, the Anti-Money Laundering Regulation applies directly across all 27 member states from 10 July 2027, and AMLA begins direct supervision of a first cohort of high-risk cross-border entities in January 2028, a cohort selected during 2026 under a common risk methodology. Crypto-asset service providers are named as obliged entities under the AMLR for the first time and are explicitly a supervisory priority. The practical effect is a rising bar on evidence: not “we have limits” but per-agent policy definitions, versioned policy history, and immutable logs of every allowed and denied signing request.
• Travel Rule: Originator and beneficiary data obligations attach to qualifying transfers by their nature, not by who or what pressed send. High-frequency agent micropayments do not escape the requirement. They make the data problem harder, which argues for keeping agent payments on rails where counterparty data is captured by design.

EU AI Act and an important 2026 correction 

Many compliance plans were written around 2 August 2026 as the date high-risk obligations would bite. That changed. The Digital Omnibus on AI was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, deferring compliance for standalone Annex III high-risk systems to 2 December 2027, and to 2 August 2028 for high-risk AI embedded in products covered by EU product-safety law. Crucially, the postponement did not move the Article 50 transparency rules or the Article 4 AI literacy duty, which continue on their original timeline. Firms should treat the deferral as more runway to build human oversight and logging rather than a signal to stop.

Buy bitcoin and stocks. Signup to Coinbase today

A useful practical note that regulators and standard-setters keep repeating: automated screening is not a decision market but an input. Know-Your-Transaction tooling should inform the policy engine, but it does not replace customer due diligence, governance, or a named human who is accountable when an agent spends money it should not have.

A Checklist Before You Give an Agent a Wallet

1. Fund to the loss you accept. Keep working balances small and top up as an agent cannot lose what is not in the account.
2. Set a per-transaction cap first, then add period and velocity caps. One bounds value, the other bounds loops.
3. Scope contracts and functions, not just addresses. Exclude unlimited approve unless there is a specific reason.
4. Expire everything. No permanent grants; 24 hours is a reasonable default for micropayment agents.
5. Never raise privilege from attacker-influenceable state. No inbound asset, token balance or received message should widen a permission.
6. Denominate caps in stable value and re-evaluate on a schedule.
7. Route above-threshold transactions to a human who has the authority and context to refuse.
8. Log every decision (allowed and denied). Denials are your earliest compromise signal.
9. Test the kill switch under congestion, and rehearse who invokes it.
10. Keep agent transfers inside the same AML monitoring perimeter as human-initiated ones.
11. Assume the agent will be injected and ask what the worst 30 days look like under the limits you set.

Final Thoughts on Programmable Wallets

The instinct to make agents trustworthy is misplaced. Language models can be manipulated by anything they read, and no amount of instruction hardening changes that. What can be changed is how much a manipulated agent is able to move.

Programmable wallets do exactly that. They take the spending decision out of the agent’s reach and hand it to a layer that does not read arguments, does not get persuaded, and does not have a bad day. Caps, allowlists, scopes, expiries and kill switches are unglamorous, but they are the difference between an incident and a catastrophe. Increasingly, they are also becoming the difference between a defensible compliance posture and an indefensible one.

Give agents the smallest authority that lets them do the job, make it expire, and log everything. That is the whole discipline.