Agentic Payment

Boundaries, not trust

Letting an AI agent spend money was never hard because initiating a payment is hard. It is hard because of how much can be lost when something goes wrong. Three constraints make "trust the agent" unworkable.

Prompt injection is the norm, not the exception. Web pages, emails, documents and tool results an agent reads can all carry instructions aimed at it, so any design that relies on the agent policing itself can be talked out of that policy by a well-crafted paragraph. A security boundary cannot rest on the self-restraint of the thing being attacked — decades of security engineering say so, and agents are no exception.

Machine frequency: a person who makes a mistake stops to think, while an agent repeats the same mistake hundreds of times in seconds. "Detect afterwards and intervene manually" is a process designed around human tempo and simply cannot keep up. And a key is total authority: one leaked wallet key or API credential means unlimited amounts and unlimited attempts. Credential leakage is an incident in human systems; in agent systems it is an event you must assume will happen.

The workable model puts the boundary in the payment infrastructure rather than in the agent’s discipline: a human approves a policy once — budget, expiry, merchant allowlist, chain and asset — the agent executes freely inside it, and every request is policy-checked server-side. The agent can be creative. The money cannot.

Prepaid is the boundary

Cards issued to agents are prepaid, which makes the ceiling on risk a number you chose: the balance on the card. Even if an agent is fully compromised — injection succeeds, its task definition is tampered with, its credentials leak — the maximum loss is that balance, and it never reaches the company’s main accounts. Expiry or exceeding the budget freezes the card automatically, with nobody needing to be present to decide.

This differs fundamentally from handing an agent a corporate card and watching it. There, the ceiling is the credit limit; here, it is the amount you funded last week. One requires you to be permanently online. The other lets you go home.

Treat an agent’s payment channel like a deploy key

Engineering teams have long known how to manage machine identity: one key per service, least privilege, revocable at any time, blast radius confined to a single service when something goes wrong. An agent’s payment channel deserves the same discipline.

• One card per workload, never shared — sharing means you cannot tell which agent did it.
• Boundaries kept tight: budget, expiry, merchant category and allowlist — constrain everything that can be constrained.
• Freezable at any moment, through the API or the console, with no manual process in between.
• Blast radius equals one agent — never the treasury.

A refusal is a signal

Most payment systems only record successful transactions carefully. For agents that is the wrong instinct: refused requests are your most valuable security signal. An agent that suddenly starts trying payees outside the allowlist, or repeatedly bumps against its limit in a short window, is telling you one of two things — it has been manipulated, or its task definition is wrong. You want to know either as early as possible.

So refusals are logged as richly as approvals: when, which agent, intended payee, amount, and which policy stopped it. That surfaces anomalies before they cost anything, rather than at month-end reconciliation.

Three alternatives, and what each gets wrong

The distinction comes down to one sentence: the boundary has to be enforced somewhere the agent cannot reach.