Agentic Payments: We Gave Agents Wallets Before We Gave Them Limits

A developer in 2026 can give an AI agent a funded wallet in an afternoon. Circle’s Agent Stack, which launched on May 11, hands an agent a USDC balance it can hold and move through a command-line tool. Amazon’s Bedrock AgentCore Payments, in preview since early May, lets an agent connect a Coinbase or Stripe wallet and pay for API calls while the agent runs. Underneath both sits x402, a settlement handshake where a server quotes a price in an HTTP header, the agent signs an authorization instead of submitting a transaction, and a facilitator settles it on-chain. And there is no card, no account, or no human in the loop. The plumbing for autonomous spending is now a managed product, and it is standardizing fast enough that wiring it in is no longer the hard part.

The plumbing for stopping that spending is a cap and a list—set a daily limit, approve a few addresses, and block the rest. That is close to the full extent of what today’s agent wallets offer once the agent is actually holding money, and it is where the real problem lives. Moving money, as it has turned out, is the easy half. Delegating bounded, revocable authority to software that operates unsupervised is the half that has not shipped.

The Problem Is Delegation, Not Agentic Payments

Any team putting an agent on a payment rail this quarter inherits the same question, whether they notice it or not: how much authority does it get, and how can they take it back? A procurement agent that buys compute, a DeFi automation that rebalances a position, an agent that pays per request for data it needs mid-task all face it. Funding them is trivial now. Constraining them is a design problem nobody has a clean answer to.

The reason it is hard is that the agent-specific loss surface is behavioral and not cryptographic. The agent failures reaching production this year have largely not involved broken signatures or stolen keys. They have involved agents doing exactly what an attacker told them to do. Prompt injection, where a malicious instruction rides in through a web page, an API response, or a document the agent reads, sits at the center of the 2026 agentic security picture that OWASP and others have documented.

Consider the clearest case so far. In May 2026, a wallet auto-provisioned to xAI’s Grok by the Bankr agent platform was drained of roughly $155,000 to $200,000 in tokens. The attack broke no cryptography. It gifted the wallet an NFT that switched on the agent’s full transfer capability, then posted a message, obfuscated in Morse code, that Grok repeated in public. Bankr’s system read that repeated text as an instruction to move funds and executed it. Most of the money was later recovered, but the mechanism is the lesson. The agent held more authority than the moment required, and a parsed message stood in for a signature. A stronger signature scheme does nothing against that. The gap here is authorization.

Why Caps and Allowlists Reach Their Limit

The controls builders reach for today all come from a world of scoped, human-approved transactions, and each bounds one dimension of the problem while leaving another open.

Per-transaction signing, where a human approves each payment, is the safest option but the least useful. It works, and it dissolves the entire point of an autonomous agent. Autonomy is gone the moment a person has to sign.

Spending caps and velocity limits bound the worst-case amount. A daily ceiling means a compromised agent can lose the ceiling and no more. That is real protection on the wrong axis. A cap constrains how much an agent spends, not what it spends on. An agent tricked into paying the wrong recipient, in full compliance with a $5,000 daily limit, has done exactly what the limit permits.

Session keys, borrowed from ERC-4337 account abstraction, are the most sophisticated version, and they inherit the same assumption. A session key is a temporary, scope-limited signing key the wallet contract authorizes once, so the agent can act repeatedly without re-prompting and without touching the master key. That model was built for a person granting a dApp permission to call a specific contract for up to 500 USDC for 24 hours. It depends on knowing the valid actions in advance. An open-ended agent task has no knowable set of counterparties or calls to enumerate at the time of signing. Builders are left choosing between a key scoped loosely enough to let the agent work, which widens the blast radius, and one scoped tightly enough to be safe, which strangles the autonomy they were paying for.

Custody design softens the edges without closing the gap. Circle’s Agent Wallets keep key shares in a 2-of-2 MPC arrangement the agent never holds, so a compromised agent cannot exfiltrate the key and drain everything. Coinbase has argued that agents should not hold private keys at all. Both are correct, and neither addresses within-authority misuse, which is the failure at hand.

Where Does Authorization Live?

The more useful way to frame the emerging work is as a question of placement. Authority has to be enforced somewhere, and the industry has not agreed on where.

It can sit at the contract level, as session keys and on-chain caps do. The enforcement is trust-minimized, so there is no off-chain component that could be compromised. However, such a model is rigid as it inherits the pre-declared scope problem.

It can also sit at an intent entry-point. ERC-7521, a draft proposal for generalized intents, points to an appealing shift. Instead of authorizing specific calls, an agent signs off on a desired outcome, and a solver figures out the execution. Scoping by intent fits agents better than scoping by call. The proposal is early and unproven for arbitrary agent behavior, and the solver model introduces its own trust surface, so this is a direction rather than an available tool.

Or it can sit in the runtime, off-chain, as a policy engine that inspects each proposed transaction against encoded rules before anything is signed. This is where AWS placed its session-level limits, and where a growing set of proposals want to go further. Thirdweb has described an Ethereum spend-mandate concept that treats bounded authority as a first-class, revocable object with a cap, an expiry, and a way to pull it back. That last property matters more than it sounds. Almost nothing in the current stack lets you revoke an agent’s authority cleanly while it is mid-execution, and mid-execution is exactly when you discover you need to.

The tradeoff across these placements is consistent. On-chain enforcement is trustworthy but inflexible. Runtime enforcement is expressive, but it reintroduces a component you have to trust, and it adds latency and cost to a settlement path that x402 was designed to make near-instant and sub-cent. A policy engine that inspects every transaction runs counter to the high-frequency, fractional-value flows these rails were built to enable. No option is both maximally flexible and trust-minimized, and the choice is being made implicitly, by whichever product a team happens to adopt.

The Constraint Layer Is Wide Open

This gap itself is the opportunity, and it is an infrastructure opportunity more than an application one. The spending rails are becoming a commoditized layer. The constraint layer is open.

The openings here are specific. One is a policy engine that sits between an agent and its wallet and evaluates every transaction before signing. Another is authorization middleware that translates a task-level instruction into enforceable limits, paired with revocation and kill-switch infrastructure for agents already running. Around all of it sits an observability layer: transaction pre-flight and simulation, so that an intended action can be inspected before it settles, and a spend audit that ties every payment back to a specific delegated authority and the human who granted it. The x402 facilitator, which executes an agent’s signed authorization, is a natural policy chokepoint that few have built on yet.

And why is none of this shipped already? Because the useful version is hard in a specific way. A numeric cap is trivial to enforce, since a machine only compares two numbers. A semantic bound is not. “Buy compute for this job, from a reputable provider, at a fair price” is the kind of constraint that would actually stop the Grok-style failure. Encoding it as a deterministic check that runs before every signature forces the enforcement layer to evaluate intent and context that even the agent only judges probabilistically. Turning a fuzzy instruction into a rule a wallet or facilitator can enforce, fast enough to sit in a payment path, is the unsolved engineering problem underneath every product category above. It also has no standard. A team building it today commits to a vendor-specific model, because portable authorization across rails does not exist. For an infrastructure builder, an unstandardized layer that every agent application will eventually need is a defensible place to be early.

The Wager Every Deployment Makes

The honest counterargument to all of this is that current controls may be closer to sufficient than this framing suggests. Keep the agent’s key out of its reach, fund the wallet conservatively, cap it low, and the worst-case is a bounded, funded loss rather than a treasury loss. On that view, blast radius is a tuning problem, and a richer authorization primitive is a solution looking for a standard, dragging latency and a new trusted component behind it.

That case is not wrong, only incomplete. Conservative caps genuinely reduce exposure. What they do not address is an agent that spends its permitted budget on the wrong thing, which is precisely what prompt injection produces. Whether closing that gap needs a new primitive or just disciplined use of the ones we have is an open question, and it is the one worth watching.

What has to happen for the constraint layer to catch up to the spending layer is fairly specific. Authorization has to become expressible in terms of intent and semantics, not just amount. It has to be revocable mid-task. And it has to port across rails, so an agent’s bounds are a property of the agent rather than of whichever wallet product it was handed. Until then, giving an agent a wallet remains a straightforward act with an unresolved second half, and every deployment is a wager on how much authority to grant to software that will do precisely what it is told.