As AI agents take on procurement tasks such as subscribing to SaaS tools, topping up cloud infrastructure credits, and placing e-commerce orders, finance teams face a control problem: how to let an autonomous system spend money without granting it open-ended access to corporate funds. One-time cards have emerged as a practical answer. A one-time (or single-use) card is a virtual payment credential generated for a specific transaction or merchant, with a fixed spending ceiling and a limited lifespan. Once the intended purchase is settled, the card number expires and cannot be reused.
The mechanism resembles the single-use virtual card numbers that banks and spend-management platforms have offered since the 2010s, but the use case has shifted. Instead of a human analyst generating a card for a vendor payment, an AI agent requests a card programmatically, and an approval workflow decides whether to issue it. Providers such as Oobit have extended this model with programmable Visa cards for AI agents, funded from a stablecoin treasury and governed by server-side limits on spend caps and merchant categories.
A typical approval flow proceeds in four steps. First, the agent proposes a purchase: it submits the merchant, amount, currency, and a structured reason for the spend, such as a SaaS renewal or an ad budget top-up. Second, a policy engine evaluates the request against pre-configured rules: is the merchant in an allowed category, is the amount under the per-transaction cap, is there remaining budget in the relevant ledger. Third, depending on policy, the request is either issued automatically or routed to a human approver via chat, email, or a spend console. Fourth, if approved, a virtual card is generated, the transaction executes, and the card is retired.
Because the controls are enforced server-side rather than in the agent's own prompt or code, a compromised or misbehaving agent cannot bypass them. Every approval and decline is logged, producing an audit trail that maps each card transaction back to the agent, the request that triggered it, and the rule set that permitted it.
The main benefits are bounded exposure and observability. A one-time card number leaked in a data breach or misused by a vendor is worthless after settlement, and hard caps mean an agent cannot overspend even when its request is approved. Finance teams also gain cleaner reconciliation: each card maps to a discrete purchase rather than a shared corporate card statement.
Limitations remain. One-time cards do not handle recurring billing well, since merchants storing the card for renewals will find it declined after first use; some platforms address this with merchant-locked multi-use cards as a middle ground. Authorization holds (common with hotels, car rentals, and some cloud providers) can consume the card's full balance temporarily. And approval latency matters: an agent that must wait hours for human sign-off may lose time-sensitive advantages, so most deployments pair strict human review for large purchases with automatic issuance below a defined threshold.
Organizations deploying agent-driven procurement generally start with a narrow scope: one or two spending categories, low per-transaction caps, and mandatory human approval above a modest ceiling. They then expand autonomy as the audit data demonstrates reliability. Key design questions include whether cards should be single-transaction or merchant-locked, how approvals integrate with existing messaging tools, and how the card platform's logs map onto the organization's expense ledger. Whatever the platform, the core principle is consistent: approval should attach to a specific, bounded payment credential rather than to broad access to company funds.