Give an AI agent a real job and it hits a wall fast. It wants to call a paid API, pull a dataset, maybe rent some GPU time, and every one of those wants an account, a card on file, and a human to click "confirm." The agent can plan the entire task. It just can't pay for any of it.
That gap is what an "agent wallet" is supposed to close. It's also one of the noisier corners of the whole agent stack right now, so let me try to say what one actually is without the brochure version.
So what is an AI agent wallet, really?
It's a wallet an agent can spend from on its own, inside limits you set, without a person approving each transaction.
That's the whole idea. The "inside limits you set" part is doing far more work than the demos admit, and it's usually the part they skip. A normal crypto wallet holds keys and signs whatever you tell it to. A normal card assumes a human is watching the screen. An agent wallet has to assume nobody's watching, which changes the design from the ground up.
Why can't the agent just use my credit card?
You can hand an agent your card number. People do. It works right up until it doesn't. The card has no idea it's being driven by software, it has no per-task limit it understands, and the first time the agent loops on a bad retry or gets prompt-injected into buying something stupid, your only backstop is the fraud department.
The card networks know this, which is why they've been busy. Visa shipped its Trusted Agent Protocol and Mastercard shipped Agent Pay, both essentially ways to prove "a real agent is acting for a real user" at checkout. The point was never to give agents your raw card. It's to give them a scoped, throwaway credential instead.
What does the wallet actually have to do?
A few unglamorous things:
- Hold value, usually a stablecoin like USDC, sometimes a card line.
- Sign payments by itself, fast, no human in the loop.
- Refuse to spend outside the rules you gave it.
- Leave an audit trail, so when it spends $40 you can see exactly why.
The first two are mostly solved. The last two are where everyone is still fighting.
How does an agent actually pay for something?
The cleanest answer in 2026 is x402, Coinbase's revival of the long-dead HTTP 402 Payment Required status code. The flow is almost boring, which is the best thing about it:
# 1. Agent asks for a paid resource
GET /v1/market-data HTTP/1.1
Host: api.example.com
# 2. Server says: pay first
HTTP/1.1 402 Payment Required
{ "amount": "0.01", "asset": "USDC", "network": "base", "payTo": "0x..." }
# 3. Agent signs a payment, retries with the proof in a header
GET /v1/market-data HTTP/1.1
Host: api.example.com
X-PAYMENT: <signed-payment-payload>
# 4. Server verifies on-chain and returns the data
HTTP/1.1 200 OK
No account, no API key, no signup. The agent reads the price off the response and decides. x402 has the most real traffic of any of these protocols today, which is why it keeps showing up everywhere. It's also stablecoin-only, so if your money lives on cards, you need something else underneath it.
Who's actually building this, and what do they get right?
There are a lot of names, and it's easy to feel lost. The useful way to read the space: it's a stack, not a winner.
- Authorization (can this agent spend, and how much?): Google's AP2, now handed to the FIDO Alliance, with its signed "mandates."
- Settlement (move the money): x402 for stablecoins, Stripe's MPP for a fiat-and-crypto mix.
- Checkout (buy from a store): OpenAI and Stripe's ACP. Worth knowing this one stumbled when OpenAI pulled Instant Checkout in March.
- Card networks sit underneath all of it as the credential layer.
If you only track one company here, track Stripe. It co-authored MPP, it's a founding member of the x402 Foundation, and it co-built ACP. Developers trust it for a reason, and it's standing in nearly every room.
How do you stop an agent from spending money it shouldn't?
This is the actual interesting problem, and the field has quietly agreed on one idea: don't hand the agent a reusable credential. Hand it a single-use, scoped one.
Stripe's Link Agent Wallet issues one-time-use cards. Mastercard's Agentic Tokens are scoped to one agent, one merchant, and a set spending mandate. Fireblocks shipped a spend-governance extension straight into x402. Different rails, same instinct: give the agent just enough authority to do the one thing, and nothing left over for the next mistake.
The card-rails version of this is where I spend my days. FluxA, an AI agent payment platform I work on, does it with a single-use virtual card per task plus an Intent-Pay mandate that pins down the ceiling, the merchant, and the purpose before the agent ever moves a cent. Same pattern as the Shared Payment Token and the Agentic Token, pointed at cards instead of stablecoins. I bring it up as one shape of the answer, not the answer. Pick whichever rail your money already lives on.
What's still broken
Plenty.
The liability question is wide open. x402 defines how a payment happens, not who's on the hook when an agent buys the wrong thing or gets talked into it. There's no law for that yet, so everyone is writing their own house rules.
The wallet layer is fragmented. Coinbase, Stripe, Fireblocks, and a dozen smaller players each ship a different idea of "agent financial identity," and there's no single standard a builder can safely assume. Daily volume is also still thin next to the noise, even though the protocols process real money.
None of that means the idea is wrong. It means it's early in the genuinely useful sense, where the primitives work and the conventions don't exist yet.
If you're building one
The honest starting move is small. Pick x402 for service calls. Decide whether your money is stablecoin or card. Then put a hard spending cap in front of the agent before you ever let it run unattended.
The wallet matters less than the limit. Get the limit wrong and nothing else you bolt on will save you.
