The Authorization Gap: AI Agents Need More Than a Wallet
Issue #1 — The Mandate Layer
本文亦有中文版：授權缺口：AI Agent 需要的不只是一個錢包
Over the past year, almost every conversation about Agentic Payment eventually circles back to the same question:
Should AI agents have their own wallets?
The more I think about it, the more I’m convinced this is the wrong question.
The debate is dominated by wallet questions: Do agents need their own crypto wallets? Should they hold private keys? Should settlement run on-chain or through traditional card rails? These are real technical questions, but they’re all surface-level.
The thing actually happening underneath isn’t getting enough attention.
For the past 60 years, every payment system has been built on the same assumption:
The person who wants to buy something, and the person who actually executes the transaction, are the same entity.
Your credit card is yours.
Your password is yours.
The finger that presses “confirm payment” is yours.
Visa, Mastercard, PayPal, SWIFT — every layer of modern payment infrastructure is built on this assumption.
AI agents break it for the first time.
When you authorize a Shopping Agent to book hotels, buy software, or handle procurement:
You are the authorizer.
The agent is the executor.
These two have been separated for the first time. Once the authorizer and executor are no longer the same person, half a century of payment authorization logic starts to lose its grip.
So the real question isn’t whether the agent has a wallet.
It’s: Who authorizes it? Authorizes what scope? What happens when conditions change? Who’s accountable when things go wrong?
Wallet solves custody.
Mandate solves delegation.
This isn’t a wallet problem.
It’s an authorization architecture problem.
Three Models, Three Different Gaps
The market is moving in roughly three directions on Agent Payment today.
Each one solves part of the problem.
But each one leaves a different gap.
1. Agent-Owned Wallet
Represented by Coinbase Agent Kit.
Each agent has its own on-chain address, with private keys held inside a TEE (Trusted Execution Environment) and full signing authority.
For DeFi arbitrage, market-making, and high-frequency on-chain trading, this is a reasonable — even necessary — design. In those contexts, waiting for human approval is itself an unacceptable delay.
The problem isn’t the architecture. It’s the scale.
500 agents means 500 private keys. Once you have that many keys, management quickly spirals: rotation, revocation, incident response, risk isolation — every one of these becomes operation and management overhead.
This model fits high-autonomy, high-frequency trading agents. But not most enterprise process agents.
2. Shared Treasury Model
This is the most common approach today.
Developers maintain a shared pool of funds. Agents authenticate via API Keys, OAuth tokens, or platform accounts, but don’t hold any keys themselves.
For Coding Agents, Research Agents, or any agent whose spending is limited to API costs, this works well. Simple, controllable, easy to manage.
But there’s one problem: the authorization granularity is too coarse.
API Keys are great at answering:
“Is this a legitimate service?”
“Does it have permission to call the API?”
But they can’t answer the more important question: “How far is this agent actually authorized to go right now?” Or, more precisely: “Where are this agent’s authorization boundaries?”
For example:
What’s its daily spending limit?
Which vendors can it pay?
When does the authorization expire?
Does anything above a certain amount require human approval?
Should it automatically halt when the department budget gets close to its cap?
“Who you are” (Authentication) and “what you’re allowed to do” (Authorization) are two fundamentally different things.
But much of today’s agent infrastructure treats them as one.
3. Mandate-Based Delegation
The most architecturally interesting direction right now is Google’s AP2 (Agent Payment Protocol).
The point of AP2 isn’t to give the agent a wallet. It isn’t an API key either. It’s to give the agent a verifiable authorization document: a Mandate.
A Mandate is essentially a cryptographically signed credential that explicitly records:
Who authorized the agent (Principal)
What kinds of transactions it’s allowed to execute (Scope)
Under what constraints (Constraints: spending limits, allowed merchants, expiry)
And a cryptographically verifiable record of every action (Auditability)
In short: Mandate = who authorized + what’s allowed + constraints + verifiable record.
An agent carrying a Mandate is like an agent carrying a verifiable letter of authorization. The counterparty doesn’t need to trust some intermediate platform’s assurance that “this agent is allowed.” They can verify it themselves.
The direction is right.
But what AP2 is solving is mostly the “authorization format” and “protocol structure” problem. It defines what a Mandate should look like. The genuinely harder parts come next:
How do you issue Mandates at scale?
How do you make revocation take effect in real time?
How do multiple platforms share the same authorization state?
How are Constraints enforced across systems?
How can audit records be independently verified by third parties?
The format exists. But a runtime layer that can actually operate at enterprise scale doesn’t.
KYA: The New Authorization Question of the AI Era
One framework I’ve found genuinely useful here comes from a16z crypto: KYA — Know Your Agent. Think of it as KYC for the AI era.
KYC asks: “Who is this person?”
KYA asks four things:
Who is this agent, and who built it?
Who authorized it — which human entity delegated its actions?
What is it authorized to do — spending limits, scope, allowed counterparties?
Is the authorization still valid right now — has it been revoked, has it been exceeded?
The real shift underneath this is: future payment and commerce systems no longer just need to verify “identity.”
They need to continuously verify “authorization state.”
Skyfire’s KYAPay is currently the most concrete KYA implementation in the wild. It defines three JWT tokens:
KYA Token: records the agent’s identity and the human principal behind it
PAY Token: records what this transaction is authorized to do
KYAPay Token: combines both, letting merchants verify identity and payment authorization in one shot
All tokens are signed using ES256 elliptic-curve signatures, with expiration, audience binding, and unique IDs. Skyfire publishes its verification public keys via a public JWKS endpoint, so merchants, payment processors, or auditors can pull the public keys themselves and verify a token’s authenticity locally — no need to round-trip back to Skyfire.
But this isn’t enough.
Knowing who an agent is and knowing what it’s allowed to do are two different things. The latter requires an authorization-scope layer like AP2 Mandate to fill in. KYAPay and AP2 are currently independent proposals, with no integrated implementation. Existing solutions cover part of the problem, but no one has actually built the full chain of trust.
My read on this direction: the architectural thinking is right. But what it solves is “issuing a well-formatted authorization credential at a single moment in time.”
The hard part is authorization lifecycle management. Because agents don’t stop after a single request. They keep running.
Today’s market conditions, tomorrow’s budget situation, next week’s policy update — all of these affect whether an agent “can still do this thing right now.”
What’s actually needed isn’t a static letter of authorization.
It’s a system that updates authorization dynamically as conditions change:
Conditions change, authorization adjusts.
Boundaries crossed, the agent stops immediately.
Context changes, humans can intervene to modify rules at any time.
This dynamic capability — no current solution really does it well.
The Missing Layer: Mandate Engine
This is the layer of the Agentic Payment stack that I think is most critical right now — and still vacant.
MoonPay’s Open Wallet Standard (OWS) is, in fact, very close to the right direction. Its Policy Engine handles the basics: per-agent daily spending limits, address allow-lists, time-bound authorization windows, pre-signature checks.
OWS only defines the high-level framework. Inside the Policies sub-spec, it deliberately reserves an extension hook: Optional Custom Executables.
The intent is pretty clear.
Real enterprise authorization logic can’t be solved by a handful of static rules. Real-world enterprise authorization is much more than “daily spending limit.”
Real cases look more like this:
A procurement agent submits an order above $500. It shouldn’t just fail — it should pause and wait for a manager’s approval.
A DeFi arbitrage agent shouldn’t just “allow / deny.” It should know to wait when gas fees are too high, and execute when conditions are met.
A single department might have a dozen agents running at once, each only seeing its own transaction, with no idea how much the others have already spent today. Without a shared budget cap, you find out about an overspend only when the bill arrives. Too late.
All authorization and execution history needs to be independently verifiable by external auditors — not dependent on the platform operator’s internal records.
These aren’t edge cases. This is how the enterprise world actually works.
This kind of “authorization lifecycle management” has been mature in other domains for years.
HashiCorp Vault manages cryptographic keys and API credentials: who can access them, under what conditions, when to revoke.
Okta manages enterprise employee identities: who can log into which systems, when permissions expire.
Both solve the same class of problem: who can do what, when, and what happens when the rules change.
Now we need a tool of the same caliber — only this time it manages agents, not people.
AP2’s Mandate format needs an Engine to go with it.
What a Real Mandate Engine Has to Do
At least four things, in my view.
1. Verifiable Authorization Execution
Authorization rules can’t live only inside the platform.
A third party has to be able to independently verify: did this agent actually execute within its authorization scope?
Not just “trust us, we did it right.”
2. Real-Time Revocation
Once authorization is revoked, every running agent must halt immediately.
You can’t rely on “we’ll sync next cycle.”
In the agent world, a few minutes of lag can be real financial risk.
3. Auditable Execution History
The truly difficult moment is when the compliance team walks in.
Banks, in-house counsel, and regulators will all eventually ask the same thing:
“Show me proof that every transaction in the past six months was within authorization.”
What matters in the future isn’t just whether the payment succeeded.
It’s whether the full authorization chain can be verified.
4. Protocol Neutrality
This layer can’t bind to a single platform.
AP2, OWS, x402, card networks, bank rails, even future agent protocols — all of them need to plug into the same authorization execution layer.
Otherwise, every platform ends up as its own siloed authorization island.
Stripe’s Answer, and Its Boundary
Stripe Sessions 2026 just wrapped. It delivered the clearest closed-platform commercial answer to date.
Stripe rolled out three things in Agentic Payment:
Agentic Network Tokens (agent-specific digital credentials, in partnership with Visa and Mastercard)
Issuing for Agents (programmatic single-use virtual cards for agents)
Agent Guardrails (specify agent identity, set executable scope, configure human-in-the-loop checkpoints)
The logic is fully coherent.
Stripe’s advantage is real. One of the hardest things about payments has always been integration. Visa, Mastercard, Klarna, Affirm — each comes with its own spec and authorization flow. In the past you had to integrate them one by one. Now you integrate Stripe once and most of it is handled.
That value is concrete, not marketing.
But it also represents a tradeoff.
Stripe’s answer is essentially: “Let me handle the authorization problem for your agents.”
Inside Stripe’s ecosystem, that works.
But Stripe’s Guardrails and authorization logic live mostly inside Stripe’s box. You can set rules — but you can’t independently verify whether they were actually enforced.
More importantly: the moment your agent operates in a context, protocol, or platform Stripe doesn’t cover, your constraint settings cease to exist.
This isn’t a criticism of Stripe’s design choices.
It’s a structural limitation of any closed platform on authorization infrastructure. Providing independently auditable cryptographic verification means exposing internal control logic to external verification — and doing that erodes the platform’s core moat.
Stripe’s answer is: “Trust me to manage your agents’ authorization.”
Within Stripe’s coverage, that works.
Outside it, the problem remains.
Why This Gap Will Eventually Have to Be Filled
The truly difficult moment isn’t the demo.
It’s when AI agents actually start operating inside corporate financial processes.
When that happens, compliance, legal, audit, banks, and regulators all walk in. The question they ask won’t be “which wallet does this agent use.”
What they’ll actually ask is:
Who authorized it?
What was its authorization scope?
Did it exceed its authorization?
How does the system detect and prevent violations?
Who’s accountable when something goes wrong?
Today, most systems don’t have complete answers.
Closed platforms offer “platform trust.”
Protocol standards offer “data format.”
But a truly cross-platform, verifiable, revocable, and auditable “authorization execution layer” is still blank.
Regulatory pressure is what will ultimately force this problem to be solved. Not because anyone thinks “we should.” But because once AI agents start carrying real responsibility inside enterprise finance, compliance will force enterprises to reconsider whether “trust someone’s black box” is still an acceptable answer.
This layer will eventually emerge.
The question is in what form:
Each major platform’s own closed authorization system, mutually incompatible, each only valid inside its own boundary;
Or one open, cryptographically auditable Mandate Engine layer, where the ecosystem’s trust doesn’t depend on trusting any single operator.
My read: regulatory pressure and enterprise procurement decisions will ultimately push toward the latter.
The closed version already exists — Stripe has given its answer.
What’s still missing is the open, auditable, cross-platform version.
So the questions worth asking next are:
Who builds the open Mandate Engine first?
Do the open route and the closed platforms ultimately coexist, or does one replace the other?
If you’re building in the AI payments space or exploring this infrastructure, I’d like to hear from you.