Why AI Agents Should Never Share Your Payment Credentials

The agentic commerce era has arrived. Mastercard, Visa, and Stripe have all shipped their agent payment frameworks, and millions of consumers will use AI agents to complete purchases by the 2026 holiday season. But beneath the product announcements, two fundamentally different architectures are competing to become the standard.

One approach lets agents borrow your existing payment credentials through scoped tokens. The other gives agents their own dedicated cards with isolated balances. The choice between them determines your blast radius when things go wrong.

Two architectures, different failure modes

The industry has converged on two patterns for enabling AI agents to spend money.

Token delegation issues scoped tokens that let an agent transact using your existing card or account. The agent borrows your payment method, constrained by software rules that define spending limits, merchant categories, and time windows. Mastercard's Agent Pay, Visa's Intelligent Commerce, and Stripe's Shared Payment Tokens all implement variations of this model.

Dedicated credentials give the agent its own card with a pre-funded balance. The agent cannot access your primary payment method or credit line. Spending stops when the card's balance hits zero.

Both approaches use tokenization for security. Both support merchant restrictions and spending rules. The difference is what happens when those rules fail.

Blast radius: the funding isolation question

Consider a shopping agent tasked with buying office supplies. A bug in its logic causes it to misinterpret a quantity field. Instead of ordering 10 boxes of paper, it orders 1,000. The merchant's checkout page accepts the order. The agent, following its normal workflow, confirms the purchase.

With token delegation, that order draws against your credit line. The limit on your underlying card - $10,000, $25,000, whatever you have available - becomes the agent's maximum blast radius. A single malformed request can max out your account before anyone notices.

With a dedicated prepaid card funded with $500, the same bug hits a wall. The order fails. The agent can retry indefinitely, but the card cannot spend more than its balance. The blast radius is fixed by design.

This is not a hypothetical concern. Security researchers have documented how agents misinterpret objectives, operate on compromised instructions, and execute unauthorized actions. When agents depend on each other, a single compromised agent feeds corrupted data to downstream agents, who make flawed decisions that amplify the error across the system at machine speed.

The funding isolation difference

Both token delegation and dedicated cards can have network-enforced spending limits. Stripe's Shared Payment Tokens, for example, support amount caps that the network enforces at authorization time. The difference is not whether limits exist - it is what those limits protect.

A token operates on your underlying credit line. Even with a $500 transaction limit, the token draws from the same $25,000 credit account you use for everything else. A dedicated prepaid card isolates funding by design. The worst case is the card's balance, not your credit line.

This distinction matters because of how agents request tokens.

With Stripe's SPT model, the AI agent itself specifies the token parameters: amount, validity window, merchant scope. A compromised agent - one manipulated by prompt injection or operating on corrupted instructions - could request tokens with higher limits than you intended. The policy constraint is only as good as the agent's integrity when requesting it.

Token delegation has additional failure modes worth considering:

Policy logic can have bugs. A misconfigured rule, an edge case in the merchant category code mapping, or a race condition during concurrent transactions can let unauthorized spending slip through. Software guardrails fail the same way all software fails.

Policy enforcement can have latency. If the policy check times out or the rules engine is unavailable, the system must decide whether to fail open or fail closed. Failing open means approving the transaction without full policy evaluation. Failing closed means blocking legitimate agent activity.

The agent controls the request. Prompt injection attacks that manipulate agent behavior may cause it to request tokens with broader permissions than intended. The policy engine enforces whatever parameters the agent asked for - if those parameters are wrong, enforcement is meaningless.

With a dedicated card, the balance constraint exists before the agent makes any request. A compromised agent cannot request a higher limit because the limit is the card's funding, not a parameter in an API call.

Retry loops and runaway spending

AI agents retry failed operations. This is correct behavior for handling transient errors, but it creates a specific risk with payment transactions.

Consider an agent attempting to purchase a resource that keeps failing due to a temporary issue on the merchant's side. Standard retry logic attempts the purchase again. If the original transaction actually succeeded but returned an ambiguous response, the agent may not know a charge went through. It retries. Now you have duplicate charges.

Scale this to agents running continuously, across multiple workflows, with aggressive retry policies. The spending accumulates faster than human oversight can catch it.

With token delegation, every retry attempt draws against your credit line. The policy engine may eventually catch the pattern and block further transactions, but by then the damage is done. If the policy engine itself has issues, there is no backstop.

With dedicated cards, the balance acts as an automatic circuit breaker. Once the card's funds are exhausted, retry loops have no effect. The agent can attempt transactions indefinitely - they will all be declined at the network level. No software logic required.

Shared credit lines, shared risk

Network tokens generate distinct PANs, which means you can technically distinguish which transactions came from which token. The audit trail exists. But this does not change the fundamental risk: all those transactions draw from the same credit line.

This creates problems beyond reconciliation.

Shared exposure. A token operating on your credit account shares that account's available balance with every other token and your personal spending. An agent that overspends does not just affect its own budget - it reduces available credit for everything else on that account.

Aggregate risk. If you run multiple agents, each with its own token, their combined spending can hit your credit limit faster than any individual policy would suggest. Each agent may stay within its own rules while the aggregate exceeds what you intended.

Disputes are complex. When a chargeback or fraud dispute involves a token transaction, it affects your primary account. Even if the transaction is distinguishable by PAN, the financial impact lands on the same credit line you use for everything else.

Dedicated cards eliminate these problems by isolating funding at the account level, not just the token level. Each card has its own balance, its own statement, and its own independent risk profile.

The chargeback question

Liability rules for agentic commerce remain unsettled. When an agent makes a purchase the consumer did not consciously authorize, current frameworks provide limited guidance.

Card networks have not established clear precedent. The Fair Credit Billing Act limits consumer liability for unauthorized credit card use, but whether an agent's misinterpretation constitutes "unauthorized use" is untested. Courts will eventually decide, but merchants and consumers bear the risk while the legal framework catches up.

Token delegation makes this ambiguity worse because the transaction occurred on the consumer's primary account using their existing credential. Demonstrating that the agent acted outside its intended scope requires evidence that may be difficult to produce.

Dedicated credentials create at least one clean boundary: the transaction occurred on an account explicitly created for agent activity. The intent to authorize agent spending is documented by the account's existence.

When to use which architecture

Token delegation is not categorically wrong. It has legitimate use cases.

For low-stakes, supervised agent activity with tight human oversight, token delegation offers faster onboarding because users do not need to fund a separate account. If the agent is only making small purchases that a human reviews before execution, the risk profile may be acceptable.

For autonomous agents operating continuously or handling meaningful transaction volumes, dedicated credentials provide a safety margin that policy engines alone cannot match.

The question to ask: if this agent enters an infinite loop or gets compromised, how much money could it spend before something stops it?

If the answer is "my entire credit line," token delegation is transferring risk to you that you may not intend to accept.

Building for the failure case

The payment industry is optimizing for the success case: seamless, invisible transactions that happen without human intervention. That is the right user experience goal.

But architecture decisions should be made for the failure case. Autonomous systems will misbehave. Retry loops will happen. Policy engines will have bugs. Prompt injections will be attempted.

The question is not whether you can set spending limits - both architectures support that. The question is what happens when limits fail, when agents are compromised, or when errors compound faster than oversight can catch them.

With token delegation, the worst case is your credit line. With dedicated cards, the worst case is the card's balance. Funding isolation is the difference between a contained incident and a financial catastrophe. That is the architecture that lets you deploy autonomous commerce with confidence.