Mercury Gave AI Agents Their Own Credit Cards. The Control Moved Into the Authorization.

What Agent Cards actually enforce, why a spending limit is a weaker control than it looks, and how to issue your first one without regretting it.

A human creates the card. An AI agent then uses it, completes the purchase end to end, and nobody signs off on the transaction. That is the entire product description of Mercury's Agent Cards, launched August 11 as part of Mercury Spend.

The detail that stuck with me is that Mercury did not invent this behavior. It caught up to it. "People have already been manually issuing our virtual cards [to agents]," CEO Immad Akhund told Fast Company. Founders were handing agents card numbers and hoping. Mercury's contribution is the guardrail, not the idea.

So the interesting question is not whether agents will spend money. They already do. It is what a card authorization can actually see at the moment it decides yes or no.

The approval step did not improve. It got compiled.

Here is the shape of the week, and it is worth naming because Mercury is the third company to do the same thing in seven days. Anthropic made auto mode the default in Claude Code today, replacing the permission prompt with a classifier. Claude Code v2.1.229 added server-supplied hooks so policy lives on infrastructure the org runs, not on a developer's laptop. And Mercury took the expense approval click and turned it into card authorization rules.

Three different companies. One deletion: the moment where a person said yes.

I think this is directionally right. The human approval step in expense management was theater long before anyone automated it. Nobody reads the $14 receipt. Anthropic published its own version of this arithmetic, showing users approve 97 percent of permission prompts, which is another way of saying the prompt was not a control. Moving enforcement to the point of sale is honest about that.

But moving a control does not preserve what it was measuring. A human approving an expense evaluates purpose. A card authorization evaluates arithmetic and merchant identity. Those are not the same question, and the gap between them is where this gets interesting.

What the card can actually see

The launch lists six pieces. Four of them are enforcement surfaces, and those are the ones worth reading closely.

Budgets. You create a pool for a purpose (travel, software, procurement) and issue cards against it. Transactions over budget get declined at the point of sale. Not flagged. Declined.

Merchant restriction. You can restrict by merchant name or by merchant category code.

Agent Cards specifically. Only a human can create one. Mercury says they are trackable, auditable, and cancellable, and that the agent "can transact within defined limits and cannot bypass or change them."

Policy enforcement after the fact. Cards can be automatically frozen when a required receipt, memo, or category is missing, and stay frozen until somebody completes the task. That is a setting you turn on, not a default. Separately, under automated accounting, receipts get collected through a Gmail integration that scans a connected inbox for matches, or by texting a photo.

Akhund's reasoning for using cards rather than waiting for a purpose-built agent payment protocol is the most practical thing in the coverage. "Everyone already supports cards. They already have fraud protection and disputes and charge-backs and things like that built in. For more day-to-day, sub-$2,000 purchases, I think ... agentic cards will be the way most agents do payments."

He is right, and it is the reason to take this seriously rather than treat it as a press cycle. Card rails already carry decades of dispute machinery. An agent that overspends on a card leaves a reversible trail. An agent that wires money does not.

Now look at what that authorization message contains. Amount. Merchant identifier. Merchant category code. Timestamp. That is close to the whole picture the network sees.

It contains no field for why.

Merchant category codes are a soft floor

If your control plan rests on category restriction, understand what you are resting on. MCCs classify the merchant, not the purchase. Merchants often self-classify, and one vendor can carry different codes across different channels or locations. A hotel restaurant and a client dinner produce food-adjacent codes that mean different things under your policy. Spend-management vendors write about this openly, and the standard advice is to layer merchant-name rules on top of category rules rather than trust the code alone.

Now run that through an agent instead of an employee.

An agent with a $2,000 monthly software budget and a software MCC allowlist can buy the wrong software, buy the right software twice, buy an annual plan when you wanted monthly, or buy something an attacker steered it toward through content it read on a vendor's page. Every one of those is an approved transaction. The limit held. The category matched. The money is gone and the decline never fired.

That is not a Mercury flaw. It is the ceiling on what any authorization-time control can do. I would rather have the ceiling than the theater. But you should know you are buying a budget cap, not an intent check, because the marketing language around agent spending tends to blur those together.

The real change is in the audit. When a human approved each purchase, the question after a bad transaction was "who approved this?" With Agent Cards, that question has no answer, because nobody approved it. The question becomes "who wrote this budget, and what did they think it was for?"

Your budget is now your policy document. Most people write budgets like arithmetic.

Put this into practice

If you want to try this, the lowest-friction version takes about twenty minutes and does not require you to trust anything yet.

Issue one card for one job. Not a general-purpose agent card. Pick a single recurring task with a knowable cost, like a research agent buying API credits or a procurement agent renewing one category of tooling.
Set the limit to one period of real spend, not one month of headroom. If the job costs $80 a week, the limit is $80 a week. The instinct to give it slack is the instinct that makes the control meaningless.
Restrict by merchant name where you can, not category. Category is the fallback for merchants you cannot enumerate. If you can name the five vendors this agent should ever touch, name them.
Turn on the receipt and memo freeze. This is the underrated feature in the launch. A card that freezes itself when documentation is missing gives you a hard stop that does not depend on anyone noticing.
Read the first twenty transactions by hand. All of them, including the boring ones. You are not looking for fraud. You are looking for the purchases you would not have made, which is the category the automated controls cannot flag.
Write down what "wrong" looks like before you issue the card. One paragraph. If you cannot describe the bad transaction in advance, you will not recognize it in a statement.

The thing I would actually do first: run the agent for two weeks with a human-issued virtual card and manual review, log what it buys, then set the Agent Card limits from that log. Setting policy from observed behavior beats setting it from imagination, and it costs you two weeks.

Honest limitations

The credential handoff is documented, and reading it is instructive. For an agent to transact, the card details reach the agent somehow. Mercury spells this out in its API reference, published the same day as the launch: GET /api/v1/cards/{cardId}/reveal on the vault API returns "the full card number, expiration date, and CVC," and the docs note it is "available for agentic cards only." There is a matching help-center article, Agent cards: Giving AI agents a card of their own.

Sit with the shape of that. Mercury's own MCP server is read-only and in beta, so the reveal is not an MCP tool with a permission gate around it. It is a REST call authenticated with a bearer token. Whatever code holds that token can pull a live PAN, expiry, and CVC on demand. The card's spending limits still bind, which is the point of the design, but the credential itself now lives wherever your agent's secrets live, and it can be re-fetched. Rotate and scope that token like it is the card, because functionally it is.

Declines are the only hard stop. Everything under the limit and inside the allowlist happens silently and completes. There is no "this looks unusual" gate in the flow as described. Fraud monitoring on the card rails exists, but it is tuned for stolen-card patterns, not for an authorized agent making authorized-looking mistakes.

MCC precision, covered above. Treat category restriction as a coarse filter and not a policy.

Mercury is a fintech company, not a bank, and says so. Banking services run through Choice Financial Group and Column N.A., both FDIC members, and the IO card is issued by Patriot Bank, N.A. under a Mastercard license. Mercury received conditional OCC approval in April 2026 to establish Mercury Bank, N.A., which is in progress, not complete. If you had to reconstruct an agent's spending during a dispute, you would be working across those relationships.

Adoption is early and Mercury does not pretend otherwise. Fast Company's reporting says transaction volume on agent cards "may be small for now." There is no independent data yet on how these controls behave under an agent that is behaving badly, because not enough agents have.

The Command AI layer carries its own footnote. Mercury's own disclaimer on the launch reads: "AI-generated responses and suggested actions may vary and are not guaranteed. Please review outputs before taking action." That is a reasonable disclosure, and it applies to the interface you would use to configure the controls.

What this actually asks of you

Mercury built the right primitive. Cards are the correct bridge between agents and a payment system that already exists, and the agent-created-by-a-human constraint is a real one worth having.

What changed is not the amount of control you have. It is when you exercise it. You used to review purchases. Now you write the rules that review purchases, once, in advance, and then you find out whether you wrote them well.

So go look at the budget you would give an agent right now, today, before you issue anything. Ask what an agent could legitimately buy inside that budget that would make you unhappy. If the answer is "quite a lot," the budget is not a policy yet.

The invoice arrives either way. The difference is whether you wrote down what you meant before it did.

Sources: Mercury launch announcement (Business Wire, Aug 11 2026), Fast Company interview with Immad Akhund, Mercury Spend, Corpay on merchant category codes, Navan MCC glossary.