Single-Use vs Delegated Cards for AI Agents

Short answer: A single-use virtual card is funded for one purchase and closes itself once that charge settles, so a compromised or looping agent cannot reuse it. A delegated card lets an agent reuse one payment method for repeated spend inside a mandate you set, which is more convenient but has a larger blast radius. Use single-use cards for one-off, high-risk or untrusted purchases where you want the tightest containment, and use a delegated card for recurring, predictable spend such as a subscription or an ongoing vendor, where the agent needs the same credential more than once. Either way, the card should sit behind hard spend limits and a per-agent identity, because the card type controls reuse, not the total amount at risk.

Last updated July 2026.

What a single-use card is

A single-use virtual card is a card number generated for exactly one transaction. It carries its own limit, and once the charge is authorized and settles, the card closes and cannot be used again. For an AI agent, that property is the whole point. If the agent is tricked by a poisoned web page, gets stuck in a retry loop, or leaks the number, there is nothing left to exploit: the card is already spent and dead. Single-use cards give you the smallest possible blast radius per purchase, because the credential's usefulness expires the moment the intended purchase completes. The mechanics of issuing one to an agent are covered in our walkthrough on how to give an agent a virtual card.

The tradeoff is friction. Every purchase needs a fresh card, so the model or your orchestration has to request one each time. That is fine when issuing is a fast API or MCP call the agent can make itself, and it is a poor fit if creating a card is a manual dashboard step. Single-use is the right default for anything one-off or anything you do not fully trust.

What a delegated card is

A delegated card lets an agent reuse a person's or an organization's payment method for more than one charge, inside a mandate that says what it may spend on and up to how much. Instead of a new number per purchase, the agent holds a credential it can present repeatedly until the mandate's limit, merchant scope or expiry is reached. This is closer to how a human uses a corporate card: the same card, many transactions, bounded by policy.

Delegation is the right model when the same agent needs to pay the same kind of thing over and over: renewing a subscription, topping up an API balance, paying a known vendor each month. Forcing a new single-use card for every one of those is needless overhead. The cost is exposure: a reusable credential that is stolen or misused can run more than one charge before you catch it, so a delegated card leans harder on the surrounding limits and monitoring to stay safe.

Single-use vs delegated: the tradeoff at a glance

The card type controls reuse, not the amount at risk

It is tempting to treat single-use as "safe" and delegated as "risky," but that framing misses the real lever. What caps your downside is the spend policy behind the card, not the card's reuse rule. A single-use card with a 5,000 dollar limit handed to a looping agent still loses 5,000 dollars once. A delegated card with a 50 dollar per-transaction cap, a merchant allowlist and a hard monthly budget is tightly contained even though it is reusable. So the decision is two separate choices: pick single-use or delegated based on whether the spend is one-off or recurring, and set the limits based on how much you can afford to lose. Get both right and the card type becomes a convenience decision rather than a security one. Our guide on how to set spend limits on an AI agent covers the limit side in detail.

Why per-agent identity matters either way

Whichever card type you choose, the credential should be bound to a specific agent identity rather than pooled under one account. When each card, single-use or delegated, names the agent that holds it and the human who owns that agent, every charge is attributable. That is what lets you cut off one misbehaving agent without touching the others, and what makes the month-end books close cleanly instead of turning into a chase for unexplained lines. Consumer virtual card tools can issue single-use and merchant-locked cards well, but they attach spend to one account holder rather than to per-agent identities; that difference is the reason a team running many agents needs agent-first infrastructure, which is the gap our Privacy.com alternative page walks through.

Reconciliation: single-use is cleaner, delegated needs detail

Single-use cards have a quiet accounting benefit: one card equals one charge, so matching a transaction to its purpose is trivial. Delegated cards carry many charges, so you need per-transaction metadata, the agent, the intent and the policy verdict, to code each line correctly. In both cases you will eventually pull the card activity into your books, and it helps to be able to export the card statement straight into QuickBooks rather than keying charges in by hand. The cleaner the attribution upstream, the less reconciliation work lands on the controller at period end.

How to choose in practice

1. Is the spend one-off or from an untrusted source? Use a single-use card and let the agent request one per purchase over the API.
2. Is it recurring against a known merchant, like a subscription or API top-up? Use a delegated card with a mandate scoped to that merchant.
3. Either way, set a hard per-transaction limit, a total budget and a merchant scope, so the amount at risk is capped independent of the card type.
4. Bind the card to the specific agent's identity so every charge is attributable and revocable on its own.
5. Require human approval above a threshold for the larger purchases, on whichever card type carries them.

For a broader look at how the platforms in this space handle issuing, see our roundup of the best agent payment platforms.

Frequently asked questions

What is a single-use virtual card?

A single-use virtual card is a card number generated for one transaction that closes itself once the charge settles, so it cannot be reused. For AI agents it gives the smallest blast radius per purchase: if the number leaks or the agent loops, the card is already spent and dead. The tradeoff is that every purchase needs a fresh card, which is only practical when issuing is a fast API or MCP call.

What is a delegated card for an AI agent?

A delegated card lets an agent reuse one payment method for repeated charges inside a mandate that bounds what it may buy and how much. It suits recurring, predictable spend such as a subscription or a known vendor, where forcing a new card per purchase would be needless friction. Because the credential is reusable, it relies more heavily on the surrounding spend limits and monitoring to stay contained.

Are single-use cards safer than delegated cards?

Single-use cards have a smaller blast radius because there is nothing to exploit after the one purchase, but the real safety comes from the spend policy behind the card, not the reuse rule. A single-use card with a high limit still loses that amount once, while a delegated card with tight per-transaction and total limits is well contained. Choose the card type for one-off versus recurring spend, and set the limits for how much you can afford to lose.

Which is better for AI agents, single-use or delegated cards?

Neither is universally better; they solve different jobs. Use single-use cards for one-off, high-risk or untrusted purchases where you want the tightest containment and clean one-to-one reconciliation. Use a delegated card for recurring spend against a known merchant, where the agent needs the same credential repeatedly. In both cases, put hard limits and a per-agent identity behind the card.

Agentspay issues both scoped single-use cards and mandate-bound delegated credentials by API, each tied to a specific agent identity, sitting behind hard spend limits, human approval above a threshold, and an immutable audit trail.