Every decade or so, a new type of user shows up and forces payment infrastructure to bend around them:
- Consumers got cards (1950s–60s)
- Businesses got ACH and wires (1970s)
- Platforms got APIs and split payouts (2010s)
Each shift began the same way: a new economic actor started trying to pay for things, and the existing rails didn’t quite fit. Agents are next, and this time the mismatch is bigger than it looks.
Agents are useful because they take a user’s intent and execute against it, which requires reaching across systems the user never has to touch directly. Depending on the product, that could look like an agent researching a flight across three online travel agencies, pulling real-time market data to help a user make a trade, or autonomously reviewing and paying for a small business owner’s collection of SaaS subscriptions.
Every one of those reach-outs is increasingly a paid interaction, ranging from tiny payments for a single API call to the larger transaction the agent ultimately makes when it executes the user’s intent. Which means the question isn’t whether agents will need to pay for things. It’s where they’ll pay from, and who decides what they’re allowed to spend.
The Internet Is Getting Paywalled for Agents
An agent doing real work pulls from search engines, scrapes product pages, reads news articles, queries APIs, and hits data providers. None of those hosts get ad revenue from an agent; they’re serving a bot that doesn’t look at banners and doesn’t click sponsored links. Sooner or later, the economics catch up, which means the publisher starts charging to serve the request and the data provider starts charging per row, a shift already underway.
This is why open protocols like x402 matter. x402 builds on the dormant HTTP 402 status code and gives a server a clean way to say “this resource costs X, pay here in stablecoins to access it.” It’s a sensible standard, and it’s showing up at the right moment. Fireblocks has joined the x402 Foundation and contributed a security extension to the protocol that adds request integrity and spend governance, the controls that make it safe for production and not just prototypes.
The reason it has to be stablecoins that are exchanged is structural. Card economics break because there’s a fixed-fee floor that was designed for payments orders of magnitude larger than what agents need to settle. Stablecoins settling on low-cost chains strip that floor out entirely, because the settlement cost is a function of block space rather than a fixed fee.
The rail question is close to being answered. The harder question sits one layer above it: where does the agent keep the money it’s about to spend, and who decides what it’s allowed to do with it?
Rails Are Necessary, but Not Sufficient
An agent-initiated transaction has two sides. On one side, merchants, publishers, and API hosts need a way to accept agentic payments. It’s an area Fireblocks has been investing in heavily. On the other, the agent itself needs somewhere safe to pay from. The rest of this post focuses on the agent and the wallet it’s paying from.
Before an agent can pay anyone, it needs somewhere to hold funds, a way to be authorized to spend them, and a set of constraints the business issuing the agent actually trusts. That last piece is the part most companies are underestimating. Letting an agent transact means letting software act on your balance sheet, or on your customers’ balance sheets, at machine speed.
Three things have to be in place for any of that to work safely:
- The agent needs its own wallet, with compliance and security controls built in at the infrastructure layer
- The spend has to be governed by permissions that fit the use case, which could mean limits on amount, counterparty, purpose, or time
- The business behind the agent needs to be able to point to a clear record of what the agent was allowed to do, and what it actually did
Blockchain rails don’t carry any of that weight. The wallet carries all of it.
Embedded Wallets Were Built for This Moment
The assumption with agent payments is that agents will route their transactions through existing infrastructure: card networks, bank APIs, or custodial crypto accounts. The problem is that none of those were built for a user category like this one.
Card networks weren’t designed for autonomous entities making thousands of small decisions, and the economics don’t hold at agent-scale price points. Bank APIs assume a treasury team and a batch cycle. Custodial accounts work early on, but the custody risk they expose the operator to scales faster than anyone priced in.
Embedded wallets fit the problem in a way none of the existing options do. A non-custodial embedded wallet delivers on four fronts:
- The agent spins up its own account through Dynamic’s embedded wallet infrastructure, without seed phrases or onboarding friction
- Private keys are managed with TSS-MPC, removing single points of failure and leaving multiple paths for independent recovery
- The business provisioning the wallet never has to custody funds, which takes the heaviest regulatory burden off the table
- Policy rules are programmable inside the wallet itself, with controls that can be tuned to the specific agent and the specific job it’s doing
A Day in the Life of an Agent With a Wallet
Let’s make it concrete.
Imagine a user of your fintech app asks their agent to plan and book a long weekend trip. The agent will search for destinations, pull weather data, check flight options, compare hotels, and eventually book. Several of those steps involve paying someone, whether that’s a data provider serving real-time availability, an OTA granting access to its feed, or the airline and hotel taking the booking itself.
Each of those payments has to pass through the same set of controls the user defined up front, which might include a total session spend limit, a separate cap on the booking itself, or a whitelist of counterparty categories. Strip the agent wallet out of this setup and the whole thing breaks down, with paywalled calls tripping fraud flags and small charges getting held up by the rails they were never meant to run on.
With its own embedded wallet and clear spend limits, the agent handles all of this without incident. The user sets the rules at setup: up to $25 for research and data costs this session, up to $1,200 for the booking, and only travel-category counterparties. The agent operates inside those bounds.
Every payment gets signed from the agent’s own wallet and checked against the user’s rules by the policy engine before anything executes. Anything outside the rules is refused outright, not held for review, and the full trail of what the agent was allowed to do and what it actually did is available afterwards. Nothing happens off the record, and nothing happens outside the rules.
The Infrastructure That Makes This Real
Agentic commerce only works in production if the infrastructure underneath is quietly doing a lot of work. Here’s what that actually looks like in practice:
- Wallets at scale: Every user, every agent, and every session may need its own wallet, which means spinning up a large number of wallets must be fully programmatic and secure
- Policy enforcement: The policy engine has to evaluate every transaction against the business’s rules before signing, and those rules have to be granular enough to distinguish between a routine tool-call payment and an unusual transaction
- Multi-chain by default: Agents will not stick to one chain, so if the best yield is on Base, the best liquidity on Solana, and the counterparty is on Ethereum, the wallet has to operate across all of them without the developer having to think about it
- Sub-second signing: The wallet has to produce signatures fast enough to keep up with the pace of tool calls, which means wallet infrastructure built for consumer-grade responsiveness
- A real audit trail: Every decision an agent makes is either a compliance event or evidence in a dispute, and the wallet is where that trail either lives or dies
None of this is exotic, and most of it already exists today. The same wallet infrastructure has been battle-tested against payroll flows, payments, and retail trading, and is already running institutional-grade digital asset products at scale. The agent use case doesn’t ask for new infrastructure, it asks for that same stack to extend to agents as the next category of user.
The Part Worth Remembering
Every new user category reshapes payments around itself. We’ve seen it with consumers, businesses, and platforms. This time, agents are reshaping wallets.
Not because the rail problem doesn’t matter, but because the interesting question about any autonomous economic actor has never been whether it can pay. The interesting question is what it’s allowed to do with the money, and who can prove it after the fact.
That question doesn’t get answered at the rail layer. It gets answered at the wallet layer, which is where most teams building agent products are going to end up spending the next few years of engineering effort.The wallet layer is where the next few years of agent engineering happens. We mapped out what that looks like, including permissions, proofs, payment flows, and the teams already building it, in our Agentic Finance and Stablecoins report. If you’re ready to put the infrastructure in place, you can request access to the Agentic Payments Suite.
