Mercury Just Gave AI Agents Their Own Company Credit Cards. Here's the Actual Control Model.
On August 11, 2026, Mercury launched Mercury Spend, and buried inside a fairly ordinary expense-management release is a card type built specifically for AI agents. A human issues the card and sets the spend limit, merchant restrictions, and duration. The agent uses it to check out on its own, no approval click required for each purchase, and every transaction lands in an audit trail the human can review. Mercury CEO Immad Akhund told Fast Company his framing directly: "You can have a lot of control while having agents with some ability to spend."
I've spent the last few months wiring agents into things that touch money indirectly (API metering, usage-based billing) and always stopping short of letting one hold a card. Mercury just made that the default path instead of the workaround, and it's worth taking seriously on its own terms rather than as a banking press release.
What actually shipped
Mercury Spend bundles four things: employee cards, dedicated agent cards, budgets with self-enforcing spending controls, and per-card audit trails, all sitting on top of Mercury's existing IO card infrastructure. The mechanics, per Mercury's own help center documentation, work through "budgets": a defined dollar amount tied to a card, with a per-person spend limit and an optional merchant or merchant-type allow list. If a budget doesn't have enough funds left, the transaction is declined at the point of sale. If a merchant isn't on the allow list, same thing, even if there's money left in the budget.
Agent cards use this same budget engine. On Mercury's product page, a demo shows an agent checking out on a $100 digital-advertising purchase against a card with a $1,000-per-month limit, with a line confirming the card details "were used only for this checkout, never stored." Only admins or team members with spend-management permissions can create budgets and issue cards in the first place, agent included, which is the load-bearing part of the "human creates it, agent can't touch the parameters" claim: the agent has no path to raise its own limit, add a merchant to its own allow list, or extend its own card's life. Mercury also ships automatic card locking for overdue tasks like missing receipts, which for a human employee is a compliance nudge and for an agent is closer to a kill switch with a paperwork trigger.
None of this is entirely new engineering. Akhund told Fast Company that customers had already been "manually issuing our virtual cards" to agents before this launch. What's new is that Mercury productized it: dedicated controls, dedicated visibility, one product surface instead of a workaround built on a card meant for a person.
Why this is the interesting part of the release
The actual gap Mercury is filling isn't banking, it's a missing default answer to "how do I let an agent spend money without wiring my own guardrails from scratch." Before this, if you wanted an agent to autonomously pay for API credits, book a service, or run a small procurement task, you were either handing it a real card and hoping, building your own limit-checking layer on top of a payments API, or avoiding autonomous spend entirely and routing every purchase through a human click. Mercury is betting that cards, not a new payment rail, are the near-term answer. Akhund said as much: "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." That's a pragmatic bet on existing infrastructure over the agent-native payment protocols still being built, like Google's AP2 effort, and it's probably the right one for the next year or two given how few merchants can accept anything else yet.
Mercury isn't alone here. Ramp already runs accounts-payable agents that find card-eligible vendors and pay them automatically, and Robinhood added agent-directed shopping for Gold cardholders back in May. But Mercury's version is the first I've seen that treats "give the agent its own card, with its own limit, that it cannot edit" as the headline feature rather than a side effect of an AP automation pitch.
The real question: is a limit and an audit trail actually enough
Here's where I think the marketing framing undersells the problem instead of overselling it. A spend limit and an audit trail solve the failure mode of an agent going rogue and draining an account, which is the scary, viral version of this risk. They don't solve the much more boring, much more likely failure mode: an agent making a legitimate-looking purchase, inside a limit a human approved, that was still a bad decision. Renewing a $180/month tool subscription nobody uses anymore because the agent's task was "keep our tools active" and it interpreted that literally. Paying a vendor invoice that's inflated or fraudulent because the invoice format matched what the agent was trained to recognize as legitimate. Buying more API credits than needed because the agent's retry logic misjudged usage and burned through the budget refill cycle faster than a human would have noticed.
A budget cap catches "the agent spent too much." It does nothing about "the agent spent the right amount on the wrong thing." That's the failure mode this category moves toward once agent cards become normal, and Mercury's audit trail helps you catch it after the fact, which is real value, but it's forensics, not prevention. The honest description of what Mercury shipped is "guardrails against catastrophic loss," not "guardrails against bad decisions," and those get conflated in most writeups of this launch.
What I'd actually do
If you're wiring an agent to any payment method, Mercury's or otherwise, check five things before you flip it on. First, spend limit granularity: can you set it per transaction and per period, not just a monthly ceiling that lets one bad call blow the whole budget in one shot. Second, the merchant allow list: a card with only a dollar limit is a much bigger blast radius than one locked to specific vendors, and that allow-list feature should be the default, not the one you skip. Third, revocation speed: how fast can you kill the card the moment something looks wrong, one click or a support ticket. Fourth, credential leakage: Mercury's demo notes the card number "was used only for this checkout, never stored," which is the right design, but verify that's true of every tool in your agent's chain, since a leaked API key upstream can let someone impersonate the agent's requests without ever touching the card itself. Fifth, and the one nobody markets well: what's the smallest limit that still lets the agent do its job. Every dollar of headroom above what the task needs is pure downside with no upside.
My own bar for this: I'd wire an agent to a card for a narrow, repetitive, low-stakes purchase, restocking a specific API credit balance from a specific vendor, before I'd wire it to anything involving vendor selection or invoice interpretation. The limit-and-audit-trail model is genuinely good for the first case. It's a false sense of security for the second, and I think a lot of teams will discover that distinction the expensive way over the next year.
Where I could be wrong: budgets and merchant allow-lists are more restrictive than I'm giving them credit for. If you lock an agent card to three specific vendors with tight per-transaction caps, you've actually closed off most of the "bad decision within a good limit" scenario, not just the catastrophic one. The honest counter to my own argument is that this is a config problem more than a category problem, and a careful solo operator setting tight allow-lists gets most of the protection I'm claiming is missing. I still think most people won't bother setting it up that tightly, which is where the risk actually lives.
Author
Lukas
@lukcombinator