The Authorization Layer for AI Agents

A conversation on X recently put the question well: why does an AI agent need stablecoins at all? Why can't it just remember the sixteen digits of a credit card?

It's the question most people quietly have. And the reply it drew is more interesting than "because crypto."

It comes down to who bears the risk. Card networks are built around fraud, disputes, and chargebacks, and someone, usually the merchant, carries that cost for weeks. An agent making hundreds of payments an hour doesn't fit that model. It needs settlement that's final the instant it happens.

That single question, who bears the risk, is the whole thread. The agent economy runs on crypto rails for four structural reasons, and the first is already sitting in the question.

Why crypto, specifically

Start with what the agent economy actually looks like under the hood. An agent doesn't make one purchase a month. To answer a single question, it scrapes a page, queries a price feed, runs a search, checks an inventory. Each of those calls is a payment: a fraction of a cent, settled in a fraction of a second, final the moment it lands. Four things follow from that, and each is a reason the rails are crypto rails.

Fractional value. Most of these payments are worth a fraction of a cent. Traditional card rails can't carry them; the fee eats the payment. Stablecoins on protocols like x402 settle sub-cent amounts as a matter of course, which means a service can be called ten thousand times a day at a tenth of a cent and still run a business, with no landing page and no brand.

Instant settlement. An agent's work is synchronous. The next step can't run until the last payment clears. A card settles in a day or two, and stays reversible until the T+30 chargeback window closes. Crypto rails settle in well under a second, final on arrival.

Dispute resolution, rebuilt. Crypto payments are final: no chargebacks, no reversals. That sounds like a downside until you see what gets built back: programmable escrow standards like ERC-8183, where funds release only when a job is verified. Cards gave us disputes for free. Crypto has to engineer them, and engineered, they're more flexible than the originals.

Cryptographic identity. Agents transact with strangers. Standards like ERC-8004 give them portable, verifiable identity and a reputation trail. It's not a finished story; reputation can be gamed. But it's the start of a trust layer no platform has to vouch for. Human Passport is launching delegated personhood with WaaP: an agent can carry proof that a verified human stands behind it, the basis for both trust and compliance.

None of this means crypto wins by default. The card networks see the same shift, each from a different angle. Visa leads with agent identity, Mastercard with preset spending rules, Stripe with a human check before payment. They ship working products today, settling stablecoins underneath. It was never crypto versus cards.

And paying for services is only half the story. Agents are already operating onchain, running DeFi positions, trading, claiming yield, voting in governance. An agent that reacts in milliseconds and never looks away from a position fits onchain markets in a way a human at a screen doesn't; roughly a fifth of onchain activity is already automated. Buyer in a commerce economy or operator in the onchain one, the job is the same: hold value, and authorize its use. Which raises the next question: how does an agent actually do any of this?

The framework layer

If you're building an agent today, you don't start from scratch. You reach for a framework: Coinbase's AgentKit, ElizaOS, GOAT, the Vercel AI SDK, Claude's managed agents. They're the runtime layer: the agent's reasoning loop, memory, tools, and personality, none of which you have to write yourself. They're also the distribution layer. ElizaOS alone powers more than seventeen thousand agents through Virtuals.

And they are racing toward money. ElizaOS shipped a cryptographic identity framework and an agent wallet for cross-chain swaps. AgentKit ships fifty-plus action providers out of the box: DeFi, bridging, x402 payments. The builders on these frameworks are, overwhelmingly, building onchain: yield managers, arbitrage bots, governance voters, trading agents.

A framework makes an agent capable. It gives it a brain and a set of hands. It can plan a multi-step DeFi position and execute every leg of it.

What a framework does not give the agent is a boundary. It decides what the agent can do. It has no opinion on what the agent should be allowed to do with this wallet, at this value, right now.

To execute any of it, the agent has to hold value and sign for it. So: what happens at the wallet?

Where it breaks

To sign, the agent needs a key. Frameworks hand it over one of two ways: the key sits in the agent's own environment, or a platform holds it and lets the agent spend within a limit.

Both recreate something fintech engineered out long ago. The app you log into is a key; the money sits elsewhere, in the bank. They're separate, and the separation is the point. You can cap the key, freeze it, watch it for anomalies, without ever touching the account behind it. The interface is where control lives. The account just holds value.

A crypto wallet collapses the two into one. The upside is real: sovereignty, no custodian between you and your funds. The cost is that there's no seam left to put controls on. Lose the wallet, lose everything in it. Hand an agent a private key in an env var, and you've handed it that fused object, the interface and the funds together in the agent's runtime.

Here's what that means in practice. If you're building on ElizaOS today, your agent's key is a plain string in a .env file. Everything the agent runs can reach that file. Every package you installed, every dependency those packages pull in. In March, a malicious build of LiteLLM, a library pulled nearly a hundred million times a month, shipped code that read SSH keys, cloud credentials, and crypto wallets off every machine that installed it. It was live for hours before anyone noticed.

And an agent's machine runs more untrusted input than almost anything else: packages, prompts, tool outputs, model responses. An ElizaOS agent has already had its funds redirected by a single message in a Discord channel: prompt injection into shared memory, on Ethereum mainnet, not a lab. Hyperliquid's own front end stored an agent's key in plaintext in browser storage. The key on the machine is reachable by anything on the machine, and the machine is the least trustworthy place in the stack.

The platforms that built agent-payment products, the incumbents from earlier, do answer part of this. They give the agent a spending limit and hold the key themselves. That works. But notice where the boundary went. It moved off the agent, and it didn't move to you. It moved to a platform.

So the boundary keeps moving: agent, platform, back again. But the key never disappears. It still exists, in full, somewhere. And "somewhere" is precisely what an attacker is counting on.

What's at stake

Concentrate enough keys in one place, and a patient, expensive attack becomes worth running. A server holding keys for a million agent wallets is high value and one location: the profile a patient adversary waits for. DPRK runs exactly this playbook: find a honeypot with a human dependency, then take the time to exploit the human. The group behind the $285M Drift loss embedded inside the team for six months before moving anything. The payoff justified six months.

Last year, roughly three-quarters of crypto losses traced to keys and infrastructure, not to code bugs. Audits don't catch a six-month wait.

So the real question isn't where to keep the key. It's whether the key needs to exist, in full, anywhere at all, whether anything checks a transaction before it signs, and whether the user keeps sovereignty through all of it.

The authorization layer

The obvious move is to add a check. Before the agent signs, run the transaction past a policy: is this contract on the allowlist, is this under the limit? But if that check is code in the agent's app, it runs in the same place as everything that just went wrong. A compromised agent skips its own check.

For the check to hold, it has to live where the agent can't reach it, and it has to be part of signing, not a step before it. That is what WaaP provides: a signing layer, built as a protocol. It carries the programmable security you set and enforces it two ways. A policy engine evaluates every transaction against your rules. 2PC makes that check impossible to skip. Every framework plugs into the same layer, agents and humans sign through it, and the user keeps sovereignty the whole way.

Start with the key. It doesn't have to exist in full. With two-party computation, the key is split into two shares: one held by the user, one in a secure enclave (TEE). Signatures are produced jointly. The whole key is never assembled: not on the agent's machine, not in the enclave, not anywhere. There is no plain string in a .env file, because there is no plain string.

The enclave's share does more than sign. It runs a policy engine. You grant the agent a Privilege: a scoped, expiring authority. Spend up to $500, only on whitelisted contracts, only for the next two hours. Inside that boundary the agent runs free. When a transaction crosses it, you get a tap on Telegram: approve or deny. Not a human approving every transaction. A human deciding where the edge is, and asked only there.

This is the separation from earlier, rebuilt. You hold the interface: enough to authorize, not enough to be the single point of failure. The enclave and its policy engine are where control lives. Neither side is the whole key. And no single party can move funds alone: not you, not the enclave, not the agent, not a package it installed.

This is why the same layer can sit behind any framework: the adapter into it is thin. For Coinbase's AgentKit, it's a wallet provider you swap in. For ElizaOS, a plugin. For OpenClaw and Hermes, a skill the agent loads. Keep your framework, keep your agent, keep your code. What changes is the layer underneath. The key stops being a string anything on the machine can read.

Capabilities, not keys

The agent economy has rails. It has frameworks. What it's been missing is the layer that decides what an agent is allowed to do, and enforces it at the signature, the one place that can't be skipped.

That's the difference between an agent that can transact and an agent you can trust to. The first needs a key. The second needs a boundary it can't cross.

Build that boundary into signing itself, and delegation stops being a gamble. Agents hold capabilities, not keys.

Start building with WaaP →