Brian Armstrong said it in passing — the way executives say the things they are not yet ready to defend in a filing. Coinbase, he suggested, will offer secure sub-accounts so that AI projects can run their own enterprise banking: separate balances, separate permissions, a contained blast radius when something goes wrong.
That is the entire public record. No architecture. No timeline. No product name. No token. No compliance wrapper. No threat model. No pricing. One sentence from a CEO who understands precisely what a sentence is worth in a market like this, and a market that spent the rest of the day pricing in everything he did not say.
I will not invent a roadmap for a product nobody has described. That is a genre of writing I have watched destroy more retail portfolios than any exploit ever has. What I can do is examine the vacuum around the announcement, because the vacuum is the actual event. The distance between what is announced and what is built is where readers lose money, and it is the only place I have ever found durable information. Truth over hype. Always.
So: three questions. Does the demand exist? Where does the liability land? And which asset ends up sitting in the account? Keep those in mind. They organise everything that follows.
The boring history is doing most of the work
Sub-accounts are as old as correspondent banking. A large institution wants to give a small unit — a fund, a subsidiary, a regional desk, a partner firm — the ability to move money without handing over the master key to the whole balance sheet. The solution is a nested ledger: a namespace inside the main account, with its own identifiers, its own reconciliation line, sometimes its own virtual IBAN, and a set of permissions that determine how much can leave and who can authorise it. Banks have sold this as "virtual accounts" for decades. Fintechs rebuilt it in software — Mercury, Increase, Wise, Brex — and made it feel new by making the onboarding fast.
Nothing about the concept is novel. What is novel is the asset.
A crypto wallet is a bearer instrument. Whoever holds the key holds the money, full stop, with no intermediary to call. A sub-account inside a custodian is the opposite of that: an entry in somebody's database, secured by a contract and a policy engine rather than by a private key. Those two things are not the same product in different packaging. They are opposite answers to the question of where the boundary of ownership lives. One is enforced by mathematics. The other is enforced by a service-level agreement and, eventually, a courtroom.
That distinction is the first thing I look for in any announcement like this, and it is the first thing this announcement does not give us.
Now place the move inside Coinbase's actual sequence, because that sequence is unusually legible.
In late 2024 the company demonstrated an AI agent that could transact on Base within minutes of setup — a toy, but a directional one. Through 2025 it shipped the plumbing that would make the toy useful: developer-platform wallets an agent can hold, a toolkit that lets a model call on-chain functions with policy constraints attached, and most importantly a payments protocol that turned an HTTP status code into a payment request. That last piece matters more than its adoption numbers suggest. It reframed paying for something on the internet as a machine-readable instruction rather than a human checkout flow. An agent asks for a resource. The server says payment required. The agent settles in a dollar stablecoin. The resource unlocks. No card, no session, no browser.
So by the time Armstrong mentioned sub-accounts, Coinbase had already built the instruction set. It had already chosen the settlement asset. What it had not built was the balance sheet underneath — a place for an AI project to keep operating capital, with the accounting and the permissions an enterprise finance team expects before it will move real money.
That is what a "secure sub-account" is. It is the layer above the payment rail. Which means it is not a pivot, and it is not a moonshot. It is the obvious next brick.
The competitive set is where this gets genuinely interesting, because almost everyone else is solving a different half of the problem. Google's agent payments framework, Stripe's work with OpenAI, Visa's trusted-agent protocol, Mastercard's agent programme — read them side by side and you notice they are all about authorisation. How does a merchant know that this agent is acting on behalf of a real person, within a mandate that person actually granted? They are trying to reconstruct the chain of authorisation that makes card payments safe, in a world where the cardholder is a piece of software.
Coinbase, by contrast, is going at the layer underneath: custody. Not "can this agent pay," but "on whose books does this agent's money sit, and who can stop it."
Both are necessary. Neither is sufficient alone. And the fact that they are being built by different companies, in different jurisdictions, under different standards, is the real story of the next eighteen months. Trust is the only currency that matters, and right now nobody is minting it in a single place.
What the sub-account probably is, and why the ambiguity is not pedantry
There are two ways to build it, and they are almost incompatible.
One version is a custodial ledger namespace. Coinbase holds the funds. The sub-account is a row — with its own API credentials, its own spend limits, its own audit trail, its own reporting line. The security model is a policy engine plus the company's own internal controls. The user's protection is a contract, and ultimately a regulator.
The other version is on-chain delegation. The funds sit in a smart contract account controlled by the principal. The agent holds a session key — scoped to a spend limit, a whitelist of destinations, an expiry, perhaps a rate limit. The security model is code, and the protection is that the worst case is bounded by parameters rather than by the custodian's goodwill.
Most real products will be a hybrid, because enterprises want the reporting of the first and the guarantees of the second. But the split matters enormously, because it determines who is holding the bag when something goes wrong, and it determines what "secure" is even supposed to mean.
And "secure" is doing an enormous amount of unexamined work in that sentence. Secure against what? Against the agent being manipulated into sending funds to a hostile address? Against a developer at the AI startup, who has production credentials and a bad week? Against the enterprise's own treasury team? Against Coinbase itself? A threat model is the first document I ask for when I review any custody feature, and it is always the first document missing from the announcement.
Based on my audit experience, the flaw is almost never in the cryptography. It is in the permissions — who can move what, when, and who notices afterwards. In 2017 I spent months going through the token distribution tables of two of the largest crowdsales of that cycle, and every one of the three critical vulnerabilities I documented was a permissions flaw: an address that could move supply, a role that could be reassigned, a timelock that was decorative. The charts looked clean. The permissions did not.
A sub-account is a liability boundary before it is a product feature.
That sentence is the core of this piece, so let me defend it.
When an enterprise gives an agent the ability to spend, the enterprise is not really buying convenience. Convenience was available the moment the agent could hold a key. What the enterprise is buying is a limit on how bad the worst day can be — a way to say to a board, an auditor, or an insurer: the machine can reach this much, and only here, and only until Friday. That is a risk product. The account is simply the container the risk product lives in.
Which brings us to the part nobody has solved, and which no amount of engineering elegance will paper over. Who is legally responsible when the agent is tricked?
The traditional financial system has spent fifty years building an answer for human error. Card networks wrote rules that shift liability between issuer, acquirer and merchant depending on whether the transaction was authorised, whether the card was present, whether the merchant did its checks. Consumer protection regimes give individuals a right to dispute an unauthorised transfer, and banks absorb a portion of that cost because they can price it. Wire transfers have their own doctrine: if you authorised the instruction, you own the loss, even if you were deceived into giving it. The entire architecture rests on one assumption — that there is a human at the end of the chain whose intent can be reconstructed after the fact.
An agent does not have intent in any sense a court recognises. It has a prompt and a policy.
There is no regulation for this yet. There is no analogue to the wire-transfer rules for a stablecoin transfer initiated by a model that was prompt-injected into believing it was paying a legitimate vendor. There is no chargeback on final settlement. So the dispute process — the thing that actually determines whether two strangers will transact at scale — does not exist.
Which means the honest reading of "secure sub-accounts" is this: the security is only as real as the dispute policy attached to it, and we have not seen the dispute policy.
If Coinbase says it will unwind fraudulent agent transactions, it is underwriting a genuine new risk. Final settlement plus reversibility is a spread, and spreads require capital and actuarial data this industry does not yet have. If Coinbase says it will not, then the sub-account is an accounting convenience dressed as a security guarantee, and the word "secure" is decoration.
Both are respectable answers. Silence is not.
The product that will decide this race is not a wallet and not a bank account. It is a machine-readable mandate.
Think about what a merchant actually needs before it will sell to a robot at scale. It needs to know three things without a human in the loop: that the agent represents a real, verified principal; that the specific instruction falls within the authority that principal granted; and that if the sale turns out to be fraudulent, there is a named party who pays. The first two are identity and scope. The third is insurance. Everything else — the rail, the token, the chain, the latency — is downstream of those three.
This is why the authorisation standards being built by the card networks and the large platforms matter more than their press coverage suggests. They are attempting to construct a verifiable chain of mandate that survives the absence of a human. It is also why a sub-account at a custodian could be the perfect complement: the principal-side record that the mandate points at. If an agent's sub-account carries a policy a counterparty can verify before the payment clears, the merchant no longer has to trust the agent. It only has to trust the policy and the record.
That is a real product. It is also a much harder product than a ledger row, because it requires a standard that competing custodians agree on, and standards are political.
The concentration problem nobody wants to name
If this works, the natural end state is that a meaningful share of AI operating capital sits inside a small number of custodians, denominated in a small number of stablecoins, moving over a small number of chains. An industry founded on removing single points of failure will have reconstructed a single point of failure, deliberately, because it is convenient.
I have watched this movie. In the years when "liquidity fragmentation" was the phrase of the season, the pitch was always that the market needed another venue, another chain, another bridge, to stitch together what was allegedly torn apart. Some of that was genuine engineering. A great deal of it was supply looking for demand — a manufactured deficit with a product already built to fill it. And when you sat down with the actual buyers, the finance teams, the overwhelming preference ran the other way: fewer counterparties, fewer reconciliations, fewer places where money could get stuck on a Friday afternoon.
Concentration is a feature when the buyer is a CFO and a bug when the seller is a regulator. Coinbase is currently both, and that tension will define how far this product is allowed to travel.
Follow the float
The asset is where the announcement actually pays for itself.
Follow the settlement leg and the picture clarifies. The agent payments protocol settles in a dollar stablecoin. A sub-account holding operating balances at Coinbase will almost certainly denominate in that same stablecoin, because the entire point is to avoid converting between the account and the payment. That means every AI project that adopts this structure is, functionally, a stablecoin float customer — and float, at scale, is one of the most valuable things a financial company can accumulate.
Add the rest of the stack: an exchange, a custodial business, a layer-2 network where the payments clear, a developer platform agents already use, and a long-running effort to obtain a national trust charter so the custody is done under a federal framework rather than a patchwork. Read those together and the sub-account stops looking like a feature and starts looking like a distribution channel.
Whenever a crypto company announces an infrastructure feature, check the float before you check the roadmap. It is a dull habit. It has saved me more often than any chart.
One more thing before the counter-argument.
"AI projects" is not a customer segment. It is a phrase. It covers frontier labs burning nine figures on compute, agent startups with four employees, DePIN networks renting out GPUs, and, inevitably, a long tail of tokens with a language model bolted to the front. Those customers have almost nothing in common except a word in their pitch deck.
And the compliance obligations do not soften because the end user is a bot. If anything they sharpen. Every custodial institution has to identify the natural person behind each legal entity it serves. That means the sub-account must be KYC'd to a principal, and the agent must be a delegate of that principal — with a documented scope, a revocation path, and an audit trail a regulator can follow. Under the European framework I spend a good part of my week translating for readers, the record-keeping duties carry no exemption for autonomy. Under a trust charter, the duties get heavier, not lighter.
Autonomy for the agent, accountability for the human. Any design that breaks that symmetry does not survive a compliance review, no matter how elegant the code is.
The part I might be wrong about
The consensus assumes the demand is already there — that AI projects are sitting around waiting for a bank to open its doors. The evidence for that is thinner than the narrative implies. Most agentic commerce happening today is micro-value: API calls, data lookups, inference credits. Small amounts, high frequency, no treasury function required. And the enterprise need for segregated ledgers with clean permissions is not unmet. It is met every day by virtual accounts at banks and by fintechs, in fiat, on rails that are reversible and carry a dispute process with a century of case law behind it.
For stablecoin sub-accounts to win that business, they have to beat the incumbents on cost or on speed. Not on novelty. Novelty is not a line item a treasurer can defend to an auditor.
There is also a reading of the word "secure" that points inward rather than outward. Perhaps the threat being defended against is not a rogue model at all. Perhaps it is the AI startup's own engineers — the ones with production credentials, the ones who could move the treasury in a single transaction and leave no trace beyond a hash. In that reading, the buyer is the CTO and the product is internal controls. That is a perfectly good business. It is simply not the business the phrase "AI banking" implies, and the two have very different ceilings.
And I should be honest about the pattern. This industry periodically invents a category of deficit — fragmentation, interoperability, composability, modularity — and then sells the remedy. Some of those deficits are real. The test is simple, and it has never failed me: was anyone already paying to solve this, badly? If yes, the product is real and the market is being re-segmented. If no, the narrative is doing the work, and the narrative will outlive the revenue by roughly two quarters.
Noise filtered. Signal preserved.
What I am watching from here
A published threat model. A dispute policy with a named counterparty and a stated loss allocation. An audit whose scope includes the policy engine and the permission paths, not just the smart contract. A named legal wrapper stating which entity holds the funds and under whose rules. A mandate standard that other custodians adopt rather than a proprietary one. And, quietly, the appearance of sub-accounts in developer documentation before they appear in a keynote — because developers ship what the docs describe, and keynote slides are just weather.
The question is not whether machines will hold accounts. They already do, in fragments, across wallets and cards and API keys, badly and without a treasury function. The question is what happens the first time one of them is talked into emptying a sub-account, and whether there exists a document that says who pays.
Coinbase appears to be building the account. The industry still owes us the document.
