Agent Wallet Architecture: Giving an AI a Wallet Safely

Teams keep asking me "which wallet should our agent use," and it is the wrong question. The right one is: what can this key do if the agent holding it is completely compromised? Once you ask it that way, you notice that giving an agent a wallet is really two separate problems, and most teams solve only the first.

Two jobs, and people forget the second

This is the whole architecture in one picture. Custody tech protects the key. Policy bounds the decision. They are orthogonal, and you need both, because a threshold-signed transaction that drains your wallet is just as valid as any other. Buying fancy custody and skipping policy is the single most common mistake I see.

Protecting the key

Three families of custody, and they compose rather than compete:

• MPC / threshold signatures split the key into shares held in separate places, so the full key is never assembled anywhere. Signing is collaborative and produces one ordinary on-chain signature. Strong against key leakage, at the cost of some signing latency.
• TEEs keep the key inside an isolated hardware enclave so the host and operator never see it. Lower latency, but trust concentrates in one enclave vendor.
• These even stack. Some providers generate the key inside a TEE and also split it, so it is only ever reconstructed briefly inside the enclave to sign.

All of this is real security, and all of it protects the key and not the decision. Which is why it is only half the job.

Bounding the decision: smart accounts

To constrain what a signer is allowed to do, the account itself has to be programmable. That is account abstraction.

• ERC-4337 made accounts into smart contracts without changing Ethereum's core, introducing user operations, a bundler that submits them, an entry-point contract that executes them, and paymasters that can sponsor gas. The account can carry arbitrary authorization rules.
• EIP-7702 is the 2026-relevant unlock. It went live on mainnet with the Pectra upgrade in May 2025, and it lets an existing ordinary wallet temporarily run smart-contract code while keeping its address and key. For agents that already hold assets, this is the difference between "migrate all the funds to a new contract to get safety" and "upgrade the wallet you already have, in place." It made retrofitting policy cheap.

Session keys: the pattern that makes autonomy auditable

Do not hand the agent the root key. Hand it a session key: short-lived, scoped to a spend limit, restricted to an allow-list of contracts, with a hard expiry, and let the smart account enforce that scope on every action. Now "what happens when this key leaks" has a bounded, pre-defined answer instead of a nightmare. An emerging permissions standard (ERC-7715 with ERC-7710) is formalizing how an agent requests such a permission and how the account enforces it, though it is still a draft and the exact method names are in flux, so build against the concept and expect the interface to move.

On-chain versus off-chain policy

You will be offered off-chain policy engines that check a transaction before it is signed, and they are useful: fast, flexible, and good at catching most bad transactions cheaply. But they live in the same trust domain as the agent, which means the same compromise that hijacks the agent can disable them. On-chain policy, a Safe guard that runs on every transaction, a 4337 validator module, an on-chain delegation manager, is enforced by the chain, and a prompt injection cannot argue with a smart contract. Use off-chain policy as the cheap first filter and on-chain policy as the hard wall behind it.

The 2026 toolkit

You do not have to build this from scratch. Coinbase's AgentKit gives an agent a wallet and on-chain actions, and its Agentic Wallets, launched in early 2026, advertise per-agent session spending caps, per-transaction limits, and native x402 support. Privy and Turnkey provide server-side wallets with TEE-held keys and policy engines that enforce allow-lists and caps before signing. Safe is the canonical on-chain policy substrate, with spending-limit modules and guards. Treat each vendor's specific performance and security claims as claims to verify, not facts, but the building blocks are mature.

And this is what actually pays: when an agent settles a payment over x402, the wallet is the thing signing the transfer. Which means the wallet's spend policy is the only thing standing between an autonomous payer and an unbounded one.

What to hold onto

1. Ask what the key can do if fully compromised, and size your on-chain limits to that answer. Assume the agent will be tricked, because prompt injection is unsolved.
2. Put policy on-chain, where a prompt cannot talk its way past it. Off-chain checks are a filter, not the wall.
3. MPC protects the key, not the decision. Custody and policy are different jobs. You need both, always.

We build agent wallets and the wallet and infrastructure layer around them, with the spend policy on-chain from day one. If you are giving an agent the ability to move money, that is the conversation to have first.

References

• Ethereum Foundation, Pectra mainnet (EIP-7702): EIP-7702 live on mainnet, May 2025.
• EIP-4337, Account Abstraction: user operations, entry point, bundlers, and paymasters.
• Safe smart account modules and guards: on-chain spending limits and transaction guards.