AI Agent Cards: Where Spending Limits Actually Get Enforced

AI agents can check out now. Is your card still unprotected?

On September 17, Alchemy wired Mastercard Agent Pay into its AgentCard platform. One command line, and your AI agent gets a full financial identity: an email address, a phone number, a stablecoin wallet, and a one-time-use Mastercard credential. This is not a concept demo. It is a live product with open signup and no waitlist. Visa joined AgentCard in June, which means both card networks now treat "issuing cards to agents" as a real business line in 2026.

On the surface it looks like what virtual card users already do every day: open a limited card, pay for a ChatGPT plan, fund ad campaigns. But if you take AgentCard's rules apart, the way it handles limits is far stricter than most crypto-funded card platforms. There is homework worth copying here, and a warning worth sitting with.

AgentCard's limit structure is a five-layer onion

Going by AgentCard's public FAQ, its controls stack on top of each other, and every layer binds independently:

• Each request generates a one-time card number where the requested amount is the hard ceiling. Ask for 25 dollars and 25 dollars is all that can ever be captured.
• A single one-time card number maxes out at 150 dollars.
• Account-level limits default to 100 dollars and can be adjusted.
• Normal direct accounts carry a hard 200-dollar daily ceiling that the CLI cannot raise.
• Mastercard holders go through Agent Pay and receive a network token instead of a card number for each purchase. The token is scoped to one merchant and one amount, and you confirm it with a passkey in the browser.

Translate that structure into plain speech: even if an agent gets hijacked by a malicious instruction hidden in a web page, or simply loops on a buggy retry, the damage is squeezed inside one card, one transaction, one amount. Cards expire after seven days of non-use, and unused holds release back to your payment method within a week.

Now compare that with the typical crypto-funded card platform. Most platforms treat "card balance" as the limit. Load 100 dollars, and 100 dollars is the worst case if the card leaks. Nothing wrong with that. The problem is that balance and per-transaction exposure are usually the same thing. A card loaded with 500 dollars running an automation script has 500 dollars of exposure the moment that script picks up an injection. AgentCard's core idea is to cut your funded amount apart from your per-task risk. That is exactly the layer virtual card users lack when they build their own automations.

Where the limit is enforced decides whether it is a real lock or a paper one

Here is a standard people skip too often: where is the limit written down? A budget in a prompt ("do not spend more than 50 dollars") is a paper lock. Misread it or inject it, and it is gone. An app approval step is a human lock. Safe, but useless for unattended jobs. Only a limit enforced at the authorization layer, where the issuer or the card network declines an over-budget transaction before money moves, is a real lock. It does not matter what the agent intends. The money cannot go.

Mastercard named this logic when it launched Agent Pay in April 2025: Agentic Tokens. Banks generate tokens that bundle the cardholder's authorization with the transaction details, and the network verifies whether the agent stayed inside sanctioned boundaries. On September 10, 2026, Ant International, Mastercard, and Visa went further and published the Know Your Agent framework, a cross-network scheme that identifies certified agents, traces operators, monitors transactions continuously, and revokes credentials on demand. Strip away the jargon and the networks are doing one thing: rebuilding the infrastructure that used to block bots into a system that issues passes to good bots.

The takeaway for virtual card users is blunt. When you attach a card to a script, an agent, or any automation, ask one question first: at which layer does an over-budget transaction get declined? If the answer is "the script behaves itself," the architecture needs to change.

Rolling your own: four rules to run today

Network frameworks are nice, but what most people can actually use today is the virtual card already in their wallet. When you provision cards for AI tasks, I would follow four rules, all borrowed from AgentCard's onion model:

Rule one, one task, one card. Never point your main card at an automation. Open a separate card for each agent task so the card balance equals the maximum loss. Subscription-management platforms like SubViao and purpose-split platforms like Kimoox fit this naturally. One card for AI subscriptions, another for ad spend. When something breaks, only one card burns.

Rule two, fund to the need. A 25-dollar task gets 25 dollars. Do not preload 100 for convenience. For authorization-hold-heavy work like ad platform billing, leave a margin for the hold and nothing more. A small balance is not embarrassing. A small blast radius is the whole point.

Rule three, prefer disposable. One-off purchases should use one-time card numbers that die after first use. Only fall back to multi-use cards when the charge genuinely recurs, and set a monthly cap on those. Check subscription charges regularly so convenience never quietly becomes permanent authorization.

Rule four, never stop at a budget in the prompt. A prompt budget is advice to the agent, not a control. The real lock lives on the card: a hard limit, an expiry date, merchant category restrictions. Your lock must sit somewhere the agent cannot touch.

Risk checklist: the traps in agent spending

Before you hand a card to an agent, a few practical questions deserve honest answers.

Prompt injection is the big one. Agents read web pages, emails, and tool outputs, and any of those can carry hidden instructions. An injected agent holding a capped card causes bounded damage. An injected agent holding your primary card number causes unbounded damage, because that number sits in the context window, in logs, and in tool traces the host platform keeps. So the first iron rule: the agent never sees your primary card number.

Duplicate purchases come second. A buggy retry loop buys the same item three times. One-time card numbers absorb most of this, since the card dies after the first capture. Multi-use cards on recurring tasks need idempotency checks on the task side.

Refunds and disputes are the fuzziest. The agent bought the wrong thing. Who eats it? Agent Pay tokens carry proof of what the user authorized, which should help in a dispute, but no platform's process has been stress-tested at scale yet. Juniper Research, in its April 2026 report, named trust as the number-one barrier to agentic commerce. Not immature tech. Nobody wants to be first to put money in. The same report projects a 1.5-trillion-dollar market by 2030, on the condition that trust gets solved first.

Two hurdles for Chinese users: KYC and availability

Overseas products like AgentCard are not friendly to mainland China users. A one-time identity check is required before the first purchase, a regulatory step with no workaround, and it assumes foreign identity documents. The Mastercard Agent Pay path requires that you already hold a Mastercard, and the Visa Intelligent Commerce path supports only a small subset of Visa cards today. For most mainland users, the direct route is closed.

The pattern still travels. The "capped virtual card plus agent" architecture that overseas platforms have validated can be rebuilt on crypto-funded card platforms with existing tools: open a fresh card, fund per task, bind it to the automation, close it when the job ends. Same behavior, except the limit's enforcement layer moves from the card network to the card balance. The balance is your ceiling, provided you actually only loaded that much.

If your agent work is mostly subscription billing, our AI subscription payment guide and the subscription cancellation guide are worth a read. Get both the paying and the stopping under control before you automate anything.

The KYA framework: agents are getting ID cards too

A few more words on Know Your Agent, because it may be the thread most worth following in late 2026. On September 10, Ant International, Mastercard, and Visa jointly published the KYA framework, aiming to standardize agent certification across payment networks: operator traceability, shared certification requirements, continuous transaction monitoring, and revocation on demand. It layers on top of Visa's Trusted Agent, Mastercard's Verifiable Intent, and Ant's Agentic Mobile, which effectively merges the three companies' agent whitelists into one system.

None of this touches ordinary users today, but the direction is clear. Within two or three years, "is this agent certified by a payment network" is likely to become a routine field in the transaction chain. Same arc as SSL certificates: early websites took payments without one, then browsers started flagging uncertified sites as unsafe. Uncertified agents will probably face lower limits, extra verification, or outright declines. If you provision cards for agents, build the task-card-limit ledger now so the eventual migration is cheap.

One common misreading: KYA certifies agents, it does not shift liability to them. Who eats an erroneous purchase made inside your authorization window is still a gray zone. Mid-layer products like Authoryze already sell a rules-engine-plus-single-use-card safety layer, which tells you the market assumes the network frameworks do not cover every case yet. Your own layer of locks remains your job.

Three common questions

Can the agent see my real card number? In a sane design, no. Agent Pay hands the agent a network token, AgentCard hands it a one-time card number, and the real PAN never appears anywhere the agent can read. The inverse case is the red line: any workflow that asks you to paste your primary card number into an agent chat or config file, walk away. Once a card number enters a context window or a log, treat it as leaked.

Can I get a refund when the agent buys the wrong thing? In theory, yes, and the token's record of the merchant and amount you authorized helps you prove an out-of-scope charge. In practice, refunds still run through merchant policy and issuer process, no different from an ordinary dispute. So keep large purchases out of fully autonomous flows, or at least keep a human confirmation step in front of them.

Is rebuilding this on a crypto card platform good enough? For subscriptions and ad billing, yes. The gap is the enforcement layer: network schemes decline over-budget transactions at authorization, crypto card setups cap risk with the card balance. Stick to small loads and one card per task, and the two locks end up close in practice. What you cannot replicate yet is token-level merchant locking and KYA certification. Wait for the platforms to catch up on those.

Three things to do now

Do not wait for the networks to hand a framework to every individual. Today you can audit the limit settings on your existing virtual cards and split any big-balance automation into several small cards. Build a one-task-one-card ledger for every automation you run. And keep an eye on KYA-style certification frameworks. When "certified agent" becomes a routine requirement in the payment chain, the people who prepared early will not be re-architecting in a hurry.

Agents spending your money went from demo to product in 2026. The networks built the framework, the platforms shipped the tools. The remaining risk control is yours, and it is done one onion layer at a time.