Your Agent Needs a Wallet. But What Kind of Wallet Should It Be?

Every agent wallet architecture is a tradeoff between how much autonomy the agent gets and how much control the user retains. This blog provides a comprehensive guide of the three approaches being explored in the market.

Engineering
Kurt Larsen
March 17, 2026
All posts
Share this:

In nine months, AI agents made 140 million payments to each other. That's $43 million in volume at an average of $0.31 per transaction (State of Agents 2026). Stripe launched machine payments on Base in February. Google's Agent Payment Protocol has over sixty backers. Coinbase's x402 protocol now generates nearly a fifth of all Base network traffic. There are 406,000 buyer addresses on-chain but only 81,000 sellers! Five agents trying to pay for API calls, compute, and data feeds for every one accepting payment. The bottleneck isn't demand. It's supply.

Agents are transacting today. The question isn't whether they need wallets. It's what kind.

Three architectures, one core tension

Every agent wallet architecture is a tradeoff between how much autonomy the agent gets and how much control the user retains. Get this wrong and you either build an agent that can't do anything useful, or one that can do things its user never intended.

The market has converged on three approaches.

Agent-owned wallets. 

The agent gets its own wallet with its own private keys, typically secured inside a TEE. It can receive funds, hold balances, and transact independently.

The problem is custody. If a user funds this wallet, who owns those assets? The agent isn't a legal entity. It can't hold property, enter contracts, or be held liable. In practice, the company that built the agent becomes the de facto custodian, without the licensing, compliance, or liability frameworks that custodians normally operate under. If the agent malfunctions, the user has no kill switch. Their funds sit in a wallet they don't control, managed by software they can't override.

Equipping agents with independent wallets creates an accountability vacuum. The software can hold assets and cause losses, but can't be held liable. 

Dual-key wallets. 

A smart contract wallet with a multi-owner setup: an Owner Key belonging to the user and an Agent Key secured in a TEE or MPC network. The spending policies of the Agent Key are dictated by a backend system, not enforced on-chain. The backend decides what to sign. The chain just sees a valid owner signature.

This is better than an agent-owned wallet. The user has an override key. But the agent key is still a persistent private key whose constraints live in a black box. Whether that key sits in a TEE, an MPC network, or a cloud KMS, the actual scoping depends on backend infrastructure you can't inspect, audit, or independently verify. If that backend gets compromised, has a bug, or the company changes the rules, the agent key can sign anything the contract will accept, which is everything. On-chain, it looks identical to the owner. The "policies" are a promise, not a guarantee. If the constraints were enforced by the smart contract itself, you'd have session keys, and you wouldn't need a persistent agent key at all.

User-owned wallets with session keys. 

The user owns a smart account. When they want an agent to act on their behalf, they issue a session key: a temporary, scoped, on-chain permission that defines exactly what the agent is allowed to do. The agent operates within those boundaries. The user can revoke at any time.

This is what we built Rhinestone's Smart Sessions around. And it's the architecture the rest of the industry is converging on too.

Why session keys win

The user owns the wallet. The agent is a delegate, not a co-owner. There's no custody ambiguity. No regulatory grey areas, no novel legal interpretations required.

Session keys can be scoped by protocol, token, amount, time window, and function selector. You can permit an agent to swap USDC to ETH on Uniswap up to $500 per day for 30 days, and nothing else. The permissions are enforced by the smart contract, not by a trusted black box.

And because permissions are per-key, a user can issue different session keys to different agents. A trading bot, a yield optimiser, a subscription manager, each with its own scope, all operating on the same smart account with the same balances. The wallet becomes a platform for delegation rather than a single-purpose tool. And regulators understand delegation. A user granting scoped permissions to an agent looks more like a standing order and retains self-custody. On the other hand, agent-owned wallets are custodial.

The enterprise market is arriving here on its own. The State of Agents 2026 report recommends "scoped autonomy" as the baseline for deploying agents in financial environments: limiting agents to specific assets, protocols, and thresholds, with human override and immutable on-chain audit trails. That's not a description of some future standard. It's what session keys already do. a16z Crypto's "agency by design" framework lands in the same place: preserve user control, minimise the blast radius of any single delegation.

How Rhinestone makes this work

Smart Sessions is our delegation mechanism. It's built on ERC-7579 modular smart accounts, so permissions are enforced at the contract level rather than by trusting the agent to respect its boundaries. Every delegation and every action is auditable on-chain.

But delegation on a single chain isn't enough. A yield optimiser needs to move funds from Arbitrum to Optimism to Base depending on where the best rates are. A trading agent needs to execute across multiple venues on multiple networks. Single-chain session keys are too limiting.

Warp, our crosschain intent system, handles this. The agent expresses what it wants (move $1,000 USDC from Arbitrum to a yield vault on Base) and Rhinestone's orchestration layer and first-party solver network execute it in under 1.5 seconds.

Session keys without crosschain capability confine agents to one chain. Crosschain execution without session keys requires the agent to hold its own keys. We're the only provider that combines modular smart accounts, scoped session keys, crosschain intents, and a first-party solver network in one stack.

ZyFai, a DeFi yield optimisation agent, already runs on this in production. Users create smart accounts, issue scoped session keys, and ZyFai executes automated trading strategies across chains. If the agent misbehaves, permissions are revoked instantly. ZyFai is also independently listed in Cambrian Network's Q1 2026 Agentic Finance Landscape as a live, retail-facing yield management agent.

Cambrian's Q1 2026 landscape report reinforces this. The largest capital-managing agents still rely on rule-based strategies over LLM-driven decision-making. When real money is at stake, auditability and bounded behaviour win. Session keys are how you enforce those boundaries at the wallet level.

What are you building for?

The wallet architecture you choose today determines whether your users keep sovereignty over their assets or hand control to infrastructure they can't see or override.

Our position: users own their wallets, agents earn their permissions, and every action is scoped, revocable, and auditable on-chain.

Smart Sessions documentation ZyFai case study Get in touch


Sources

Stripe, Machine Payments on Base: x402 integration, Feb 11 2026.

Share this:
Engineering

Sign up for the latest insights from the bleeding edge of crypto UX and interop.

Thanks. We'll be in touch.
There was an error. Please try again.

Read another

Introducing Safe7579

Safe is now compatible with the growing ERC-7579 module ecosystem

Engineering
Kurt Larsen
July 5, 2024

$5m Seed Led by 1kx to Unlock the Next Era of Smart Accounts. With participation from Circle Ventures, Alchemy Venture.

Engineering