AI agents need accounts, not cards
The instinct is to hand an AI agent a card, because cards are how software spends money today. But a card is a credit primitive built for human retail purchases, with its controls on the merchant's side. Agent-initiated B2B payment needs an account primitive: a funded balance the agent cannot exceed, counterparties vetted before they can be paid, screening on every instruction, and an audit record the account produces natively.
What a card actually grants an agent
A card number is an authorization credential against a credit line. Hand it to an agent and you have granted open-ended spending up to a limit, constrained by controls designed for a different problem. Card controls live on the acceptance side: merchant category codes, per-merchant locks, decline rules keyed to where the payment is being made. They answer the question the card networks were built to answer — is this merchant allowed to take this payment — for a person holding the card at a point of sale.
That control surface points the wrong way for an autonomous sender. The questions that matter for agent-initiated B2B payment are about the recipient and the instruction: who is this counterparty, has anyone vetted them, should this specific transfer happen. A card has no concept of a vetted counterparty — any merchant that can accept the network can be paid. Its dispute machinery, the chargeback, was built to protect a consumer from a merchant, not to explain to an auditor why software sent money. And the credential is the whole control: anything holding the number can do everything the card can do.
Virtual cards narrow the blast radius — single-use numbers, per-card limits, merchant locks — and they are good at the job they were designed for, which is taming human card spend inside a company. They do not change the primitive. The controls still key on the merchant, the spend is still credit, and the record is still a statement line, not a case. A stablecoin card changes the funding asset, not the primitive either: it exists so a stablecoin balance can be spent where cards are accepted, which is a retail acceptance problem, not an agent control problem.
The account primitive
An account inverts each of those properties, and the inversion is what makes the controls deterministic rather than advisory.
The balance is the ceiling. An agent paying from a funded account can spend what the account holds and nothing more. That is not a rule the application enforces or a limit a prompt describes — it is a property of the account. Fund it with what the agent should spend and the worst case is defined before the agent runs.
The counterparties are a vetted set, not an open network. On Infinite (infinite.net), an agent pays only counterparties the network has already verified; a new recipient goes through review before it can be paid at all. The card asks whether the merchant can accept. The account asks whether this recipient, specifically, should be paid — and it asks before funds move.
A card asks whether the merchant can take the payment. An account asks whether the counterparty should receive it.
The instruction is the unit of control. Every payment instruction runs counterparty screening and transaction monitoring — the same checks whether the instruction came from a person or an API key. And the record assembles itself at the account layer: who initiated, what was screened, the route, settlement confirmation, sub-ledgered per transfer. A managed account produces the case file as a byproduct of the payment, which is what lets a compliance team defend a payment no human initiated.
The companion question — whether an agent-initiated payment can carry a full compliance record at all — is the argument of Agents can move money. Can they explain it? This essay is about the layer underneath: those controls have somewhere to live only if the primitive is an account.
What neither cards nor raw wallets give
The crypto-native answer swaps the card for a wallet: give the agent a key and fund the address. A wallet does fix the credit problem — it spends only what it holds — but it fails the counterparty problem in the opposite direction from the card. A card pays any merchant on the network; a raw wallet pays any address on the chain. No vetting, no screening before the transfer, no path to a human when an instruction looks wrong, and the record is a chain transaction — an amount and an address — not a case anyone can review.
What agent payment actually needs sits between the two: the funded-balance discipline of a wallet with the counterparty controls of a regulated account. Concretely, that means recipients screened before they can be paid, screening on every instruction with flagged instructions routed to a named human before funds move, and a record that reads as who, what was checked, and why it was allowed. Agent-initiated payments on Infinite run exactly this way: same network, same checks, same standards as a payment a person initiates.
Where this is heading
The account becomes the unit of agent deployment. Each agent gets its own: the balance is its budget, the vetted counterparty set is its scope, the sub-ledger is its history. Treasury funds agents the way it funds cost centers — a balance sized to the mandate, replenished on evidence of correct behavior — and revoking an agent means closing an account, not hunting down every place a card number landed.
That structure generalizes in a way cards never will. A card assumes a merchant; most B2B money movement has none — supplier payments, payouts, treasury rebalancing, settlement between platforms. An agent with an account can do all of it, on any rail the account reaches, under one set of controls. Cards were a good answer to how a person pays a store. The agent question is how software pays a counterparty and proves it should have — and that has been the account's question all along.
Frequently asked questions
Why shouldn't an AI agent pay with a corporate card?
Because the card's controls point the wrong way. Card rules key on the merchant — category codes, per-merchant locks — and the spend is a credit line the credential can draw until a limit. An autonomous sender needs recipient-side controls: counterparties vetted before payment, screening per instruction, and a funded balance as the structural ceiling.
Is a crypto wallet enough for an agent to make payments?
A raw wallet fixes overspend — it can only spend what it holds — but it will pay any address, with no counterparty vetting, no screening before the transfer, and no human review when an instruction is flagged. Agent payments need the wallet's funding discipline combined with account-layer counterparty controls.
What should an agent's payment account provide?
Four things: a funded balance that caps spend structurally, counterparties vetted before they can be paid, screening and monitoring on every instruction identical to human-initiated payments, and a native per-payment record — initiator, screening state, route, settlement — that a compliance team can defend.