Agents That Spend Money
Agents that spend money are software agents authorised to make payments through a constrained delegation, not by receiving a user’s card, wallet seed, or full account credential. The payment authority is expressed as a verifiable grant with limits such as merchant, amount, expiry, currency, approval state, or allowed purchase type.
The problem is that an autonomous agent may need to complete a purchase, pay for API access, or settle a service fee, but the usual payment credentials are too powerful to hand over. A card number or wallet key can often be reused outside the original task. An LLM’s prompt is also not a control surface: it can be confused, injected, or induced to act outside the user’s intent.
The safer design is to give the agent a delegated payment grant. Think of it as a signed, policy-bearing authorisation that says what may be paid, to whom, under what conditions, and for how long. When the agent presents that grant at checkout or to a service endpoint, the payment system checks the requested transaction against the grant. If the request does not match, payment fails independently of what the agent says.
This trades flexibility for enforceability. A tightly scoped grant prevents broad misuse, but it also means the system must model intent, limits, merchant identity, expiry, approvals, and refund behaviour precisely enough for machines to verify. Too narrow and normal flows break; too broad and the grant starts to resemble a reusable credential. The honest boundary is not universal, because it depends on risk, product type, and user tolerance for friction.
Engineers meet this in agentic commerce and machine-to-machine payment flows. Agentic Commerce Protocol, usually ACP, focuses on structured shopping flows such as intent, merchant interaction, checkout, and payment authorisation. x402-style protocols focus on web or API services requesting payment as part of access, reviving the HTTP 402 idea. Both are competing to define how machine-readable payment requests and bounded authorisations should be represented.
Common questions
- Is this just giving an AI agent a virtual card?
- No. A virtual card is still a payment instrument, even if it has controls. A delegated grant is closer to a scoped authorisation: it describes a permitted transaction or class of transactions and can be verified against the attempted payment. The agent carries authority for a bounded intent, not general purchasing power.
- Why is a grant safer than relying on the agent’s instructions?
- Because the enforcement happens in the payment layer, not inside the model’s text output. Prompts can express policy, but they do not reliably prevent misuse, prompt injection, or accidental overpayment. A grant gives the verifier concrete fields to check, such as merchant, amount, expiry, approval status, or item category.
- What is the difference between ACP and x402-style machine payments?
- ACP is aimed at structured agentic commerce, where an agent discovers a merchant flow, expresses intent, reaches checkout, and receives bounded payment authorisation. x402-style protocols are more about machine-to-machine access, where a web or API service can request payment as part of the request flow. They overlap, but optimise for different payment contexts.