Mercury Agent Cards: Enforced Spend Limits and Customer Liability

When a company considers allowing an AI agent to make purchases on its behalf, the first questions are which spending limits apply, which merchants are permitted, what records are kept, who can stop the card, and who bears responsibility if something goes wrong.

On August 11, 2026, U.S. fintech company Mercury announced Mercury Spend, a spend-management service that includes a new feature called Agent Cards.

The fact that an agent can technically complete a purchase does not make the task safe to delegate as a business process.

In addition to evaluating the agent’s accuracy, a company needs to set enforceable limits on how much it can spend, which card credentials it can access, and who may change those limits — in a form the agent itself cannot override.

Mercury’s announcement provides one concrete example of that design.

This article focuses on permission design for AI agents that use payment cards. Autonomous transfers between accounts and investment decisions are different categories of financial activity and fall outside its scope.

Separating Agent Cards from Mercury Spend as a Whole

The first distinction is between the controls specific to Agent Cards and the broader features of Mercury Spend.

They were announced together, which makes them easy to conflate, but the controls operate at different layers.

Mercury describes the following controls as specific to Agent Cards.

An Agent Card is a virtual card, and a spending limit can be set for each card on a daily, weekly, or monthly basis.

Those limits are set and changed by a person; the agent cannot raise its own limit through an API or CLI.

The agent cannot create a new Agent Card on its own, and it cannot unfreeze its own card.

Programmatic creation requests are possible under the card agreements, but no Agent Card is issued without explicit approval from a natural person.

The agent can retrieve the full payment credentials — the card number, expiration date, and security code — only for an Agent Card explicitly assigned to it.

Mercury’s description is that this lets the agent enter its own card details at checkout while remaining unable to retrieve the full payment credentials of the company’s other virtual or physical cards.

Separately, purpose-based budgets (travel, software, procurement, and so on), restrictions by merchant name or merchant category code, and declining transactions that exceed a budget are described as features of Mercury Spend’s budgets, not as Agent Card specifics.

The same applies to automatically freezing a card when a required receipt, memo, or category is missing: that is described as a Mercury Spend policy feature.

The announcement materials reviewed for this article do not state how that automatic freeze applies to Agent Cards.

Likewise, the public information does not make clear at what level merchant name or category restrictions apply across Agent Cards.

CEO Immad Akhund is quoted in the announcement saying that founders need a scalable and programmatic way to manage spending, understand where money is going, and automate the busywork of receipts and accounting.

Because this is a vendor statement, it is best read as Mercury’s product positioning rather than as independent evidence of outcomes.

Issuance Requires Explicit Human Approval

The official documents describe the issuance path for an Agent Card at different levels of detail.

Mercury’s help page states that a person creates an Agent Card from the web or mobile app, and that the agent cannot create one itself.

The IO Charge Card Agreement and the Column Commercial Debit Card Agreement, both last updated August 10, 2026, also contemplate requesting card creation programmatically through API, CLI, or MCP-driven workflows.

Even in that case, both agreements state that no card is issued until a natural person acting as an Administrator or User has affirmatively approved the request.

So the point that holds across all of these documents is this.

An agent cannot autonomously create or cause the issuance of a new Agent Card; final issuance requires explicit human approval.

Accuracy Alone Is Not Enough — Enforce Limits at the Payment Layer

Concerns about allowing an agent to make purchases often focus on one question: what if the agent makes a bad decision?

This can make the available safeguards appear to be limited to two options: improve the agent’s accuracy, or have a human approve every transaction.

The agent’s accuracy does matter.

But for payment transactions, which can be difficult to unwind once authorized or settled, accuracy cannot be the only safeguard.

What Agent Cards illustrates is a design in which, alongside the model’s performance, limits are enforced at the payment layer in a form the agent itself cannot change.

It is worth being clear that this does not mean a person makes every purchasing decision.

Depending on how the workflow is designed, the agent may still have discretion over whether, when, and where to make a purchase, and how much to spend within the configured limit.

Mercury itself cites uses such as online purchases, advertising spend, and booking travel.

So what Mercury is presenting is not a design that entrusts safety to judgment alone, but one that places an outer boundary — spend amounts, access to card credentials, the ability to change limits — that the agent cannot cross on its own.

We have long held that in AI decision-making, the design of the authority granted deserves at least as much attention as the intelligence itself.

The structure of Agent Cards is a concrete example consistent with that view.

What Is Actually Constrained — Seven Control Dimensions

The public information reviewed for this article points to seven distinct control dimensions: spending amount, merchant scope, credential access, administrative actions, suspension and revocation, tracking and audit, and expiration.

We treat these as the basic checklist when granting authority to an AI agent.

Mapping the public information onto those dimensions gives the following.

• Spending amount: a daily, weekly, or monthly spending limit set per card (specific to Agent Cards)
• Merchant scope: restrictions by merchant name and merchant category code (on the Mercury Spend budgets side)
• Credential access: the full payment credentials of the assigned Agent Card only; the full credentials of other standard virtual and physical cards remain inaccessible (specific to Agent Cards)
• Administrative actions: the agent cannot autonomously create a new Agent Card, change its own spending limit, or unfreeze its own card (specific to Agent Cards)
• Suspension and revocation: a person can freeze or cancel the card
• Tracking and audit: Mercury states that transactions can be tracked and audited
• Expiration: in addition to the normal card expiration date, the agreements contemplate issuing an Agent Card as a Single-Use Card, which is then closed automatically at the earlier of the first qualifying authorization or the expiration date

Transaction-count limits are a separate area that remains unclear in the public materials reviewed.

Of these dimensions, credential access is the one most often overlooked in permission design discussions.

Narrowing the set of credentials handed to an agent is a control independent of any spend limit.

Two further points are not clear from the public information reviewed here.

How much short-term automatic expiry can be set for a given business purpose, and how per-transaction exception approval can be built in, both remain open.

That is not to say those capabilities are absent — only that they are not stated in the public information available.

Merchant Category Restrictions Are Not Restrictions on What Is Bought

One more area is easy to misread in practice.

Restrictions by merchant name or merchant category code are fundamentally controls at the level of the counterparty or industry.

They are not a mechanism for judging the content of an individual product or service being purchased.

If a single merchant sells several categories of goods, for example, the merchant category being permitted is not the same as the purchased item complying with internal policy.

Merchant restrictions are therefore one control that narrows scope; in our view they do not fully substitute for verifying that what was bought was appropriate.

Setting a Limit Does Not Transfer Responsibility

Here it is important to note that spend limits and the allocation of responsibility are separate questions.

Mercury’s help page and the card agreements state that, for transactions made with an Agent Card, responsibility rests with the customer in principle — regardless of whether the agent acted within the authority the company intended.

The IO Charge Card Agreement states that all Agentic Transactions and transactions on cards created by agents are deemed authorized transactions under the agreement, “regardless of whether the autonomous agent operated within the scope of authority intended by the User or Company.”

It also states that the customer bears “sole responsibility for all Agentic Transactions, including Transactions that exceed any parameters, spending controls, or instructions you configured for the applicable agent.”

The Column Commercial Debit Card Agreement likewise limits the bank’s and the servicer’s liability and requires the customer to indemnify them for certain claims arising from the operation, malfunction, compromise, or unauthorized conduct of an autonomous software agent.

None of this means that the limits enforced through Mercury’s card controls and the underlying payment infrastructure are meaningless.

It means, rather, that limits enforced by the card infrastructure need to be distinguished from limits that exist only as instructions to the agent or as an internal rule.

A limit enforced at the payment layer can help bound the company’s card-spend exposure. It does not transfer responsibility for the underlying transaction decision to Mercury, the issuing bank, or the card network.

In our view this is a point to settle before selecting a product, in any situation where an AI agent is given outward-facing spending capability.

Four Layers, Kept Apart

What is easy to miss is where each constraint takes effect.

At minimum, these four layers need to be considered separately.

Instructions within the agent: rules written into a prompt or workflow, such as “only purchase items below $100” or “use only this vendor.” These rules are flexible, but they remain vulnerable to model error and configuration mistakes.

Mercury platform settings: per-card spend limits, freezing, the scope of card credentials. Set by a person, and not changeable by the agent.

The card program and underlying payment infrastructure: the layer where supported authorization controls are enforced and transactions may be declined. This layer involves Mercury, the issuing bank, and the payment network.

Internal governance and accountability: who issues, changes, audits, and suspends, and how exceptions and disputes are handled.

The reason this split matters is that a limit written into a prompt and a limit that gets declined at payment time are not the same thing.

Treating the adoption of Agent Cards as a complete control framework can obscure the configuration choices and operating rules that the company must still define for itself.

Before Giving an Agent Authority to Spend: A Starting Template

Whether or not you use a feature like Agent Cards, deciding the following in advance reduces gaps in the design when an AI agent is given any spending authority.

This is one example. The specific thresholds and operating rules should reflect the size of the business, its risk tolerance, and any applicable industry requirements.

What to decide	Question to check	Main enforcement / management layer
Purpose of use	Which purchasing work is delegated to the agent, and what is out of scope?	Internal rules, agent workflow
Amount limits	At what levels — per transaction, daily, weekly, or monthly — should limits apply?	Platform settings, issuing bank and payment infrastructure
Merchant and scope	How narrowly should spending be restricted by merchant name or category? Is there a separate control for reviewing the items purchased?	Budget and policy settings, internal purchasing rules
Access to card credentials	Which Agent Card is assigned to each agent, and can the agent access the full credentials of any other card?	Card issuance and credential management settings
Issuance, changes, and unfreezing	Who approves card issuance, limit changes, and unfreezing?	Administrator permissions, internal approval
Expiry and suspension	How are temporary use, single use, and anomaly-triggered suspension designed?	Card settings, Single-Use Cards, incident response
Records and audit	Can you trace which agent or card made each payment, when, to whom, and for how much?	Transaction records, accounting and audit systems
Responsibility and disputes	If an unintended purchase or misuse occurs, who investigates and files disputes?	Internal policy, card agreements, finance and legal

The point is not to conflate, within one table, the items that can be technically enforced — amount limits, merchant categories — with the items left to internal rules, such as approval and the allocation of responsibility.

The former can be enforced technically through the product or card infrastructure. The latter depend on whether the organization consistently follows its own approval, review, and accountability processes.

These settings should not be established once and then forgotten; they should be reviewed periodically as the underlying work changes.

Closing Thoughts — Design the Boundary Before Delegating Spend

What Mercury’s Agent Cards illustrates is not a configuration that hands an AI agent unlimited spending authority.

The design gives the agent a dedicated card that a natural person has created or explicitly approved for issuance, and controls the per-card spend limit, the scope of accessible card credentials, and the authority to change limits or unfreeze — all outside the agent.

Meanwhile, Mercury Spend’s budgets and merchant restrictions, the purchasing rules inside the agent, and internal approval and audit procedures each sit in different layers.

You need to check separately which control is an instruction in a prompt, which is a setting on the platform, and which is enforced by the issuing bank and the payment infrastructure.

And setting a payment limit does not move responsibility for using the Agent Card elsewhere.

The question to ask before delegating spending authority to an AI agent is not only whether the agent is capable enough.

It is which authority is constrained, where each control is enforced, whether the agent can override it, and who investigates and responds when an unintended transaction occurs.

In our view, those questions should be answered before the agent is given access to a live payment card.

Sources and Verification

This article draws on Mercury’s product announcement “Mercury Launches Spend with Agent Cards and Intelligent Budgets for the AI Era,” distributed via Business Wire on August 11, 2026; Mercury’s official help article “Agent cards: Giving AI agents a card of their own”; and the IO Charge Card Agreement and Column Commercial Debit Card Agreement, both last updated August 10, 2026. The information was reviewed as of August 17, 2026.

The Business Wire item is a distribution of Mercury’s own company announcement, not an independent product evaluation.

On how an Agent Card is created, Mercury’s help page describes a person creating it in the web or mobile app, while the card agreements contemplate creation requests via API, CLI, or MCP and state that no card is issued without the affirmative approval of a natural person. This article is written on the basis of what is consistent across those documents: an agent cannot issue a card on its own, and human approval is required.

This article summarizes selected provisions of the agreements for the limited purpose of discussing Agent Card governance. It does not provide a complete interpretation of the agreements or of the parties’ rights and obligations in any specific case.

Mercury is a fintech company, and its banking services are provided through partner banks. The issuing bank and card agreement that apply may differ depending on whether the card is a debit card or an IO Charge Card.

MIF has not independently verified the security of Mercury Spend or Agent Cards, the effectiveness of their controls, or their audit capabilities. Product features, terms of use, and the allocation of responsibility may change.