What Are AI Agent Wallets and How Do They Work?

A normal wallet asks a human to approve each transaction. An agent wallet cannot — so it moves the rules into the contract instead. Here is the architecture, the session key pattern at the centre of it, and how to build one without handing an AI a master key.

The definition

An agent wallet is any wallet that holds funds and signs transactions on behalf of an autonomous AI agent under bounded authority.

The phrase doing the work is bounded authority. Everything technically distinctive about these wallets follows from one constraint: there is no human in the loop to read the transaction and click approve. So the approval logic has to live somewhere else.

The problem being solved

An AI agent will sign anything you convince it to sign. That is not a flaw in a particular model, it is the nature of a system that takes instructions in natural language and acts on them. Feed an agent a poisoned document or a hostile web page and you may be able to talk it into a transaction.

So the design goal is not an agent with good judgement. It is a wallet where bad judgement cannot cause a large loss.

That principle — constrain the wallet, not the model — is what separates a serious agent wallet from an API key with extra steps.

The session key pattern

This is the central mechanism. Understand it and the rest of the field falls into place.

Under ERC-4337 account abstraction, the wallet becomes a smart contract. That is the architectural shift that matters, because a smart account can enforce rules at the contract level before a transaction executes — spending limits, allowlisted contracts, time-bounded sessions, method-level restrictions — without trusting the agent’s judgement at all.

The structure works like this. The smart account has a master key controlled by the human. The agent is issued a session key with limited scope: which contracts it may call, which methods, what spend cap, and what time window. The session key cannot exceed those bounds regardless of what it is told to sign, and when the session expires the key is revoked automatically.

Conceptually, the permission set an implementation encodes looks like this:

struct SessionKeyData {

address sessionKey; // the agent’s signer

address[] allowedContracts; // where it may transact

bytes4[] allowedSelectors; // which methods it may call

uint256 spendingLimitUSDC; // how much, cumulatively

uint256 validUntil; // when it dies

bool active; // kill switch

}

Five fields, and between them they answer every question that matters: who is signing, where, what, how much, and until when. ERC-7715 standardises this permission model so any application can request the same scoped credential the agent’s wallet enforces.

Where the policy lives

This is the single most important architectural decision, and it is the question to ask any provider first.

Neither is universally correct. On-chain enforcement is the stronger guarantee; off-chain enforcement is the only option once card networks or fiat rails are involved. Most production systems use both.

The five architectures

How a TEE server wallet actually signs

The server wallet pattern is the one most production teams end up using, and MetaMask has published a reference architecture worth understanding:

1. The client holds an agent key used to authenticate who is asking to sign. This is separate from the on-chain account key that controls funds.

2. The backend exposes minimal APIs that forward requests into a trusted execution environment, for example AWS Nitro Enclaves.

3. The enclave is the only environment permitted to verify agent keys, generate and decrypt account keys, apply policy and produce signatures. It has no external networking and no persistent storage.

4. The encrypted key and its metadata live in a database outside the enclave, encrypted by the agent key.

5. Each request describes the action and is signed with the agent key to prove origin and integrity before the enclave will act on it.

The separation in step one is the point. Proving who is asking and controlling the funds are two different jobs, handled by two different keys.

Layered enforcement is the norm

In practice nobody relies on a single control. A well-built agent wallet stacks them so each layer catches a different failure mode:

A TYPICAL CONTROL STACK

Smart-contract wallet — a per-transaction cap that applies to everything.

Session key — a tighter per-call cap, restricted contracts and method selectors, and an expiry.

Signing service — a circuit breaker on aggregate spend over a rolling window, e.g. the last hour.

Allowlists — recipient, contract, function selector, and for card rails the merchant category code.

Sub-account isolation — fund the agent account separately so its balance is your maximum loss.

The last one is underrated and costs nothing to implement. Whatever you put in the agent’s account is the blast radius. Everything else is refinement.

The two layers around the wallet

Identity: ERC-8004

A wallet address is anonymous by design, which is a problem when a counterparty needs to decide whether to transact with an agent at all. ERC-8004 — developed jointly by the Ethereum Foundation, MetaMask, Google and Coinbase, published in August 2025 and live on mainnet in January 2026 — defines three on-chain registries covering Identity, Reputation and Validation.

The division of labour is clean: ERC-4337 and 7702 give an agent its wallet; ERC-8004 gives it a reputation. An agent that has executed thousands of clean transactions can be treated differently from one that has never moved a token.

Payments: x402, AP2 and MCP

x402 revives the dormant HTTP 402 status code to embed stablecoin micropayments directly into web requests, letting an agent pay per API call without registration or manual keys. AP2 is Google’s agent payments protocol, which uses x402 as its crypto payment track. MCP is the connector standard that lets AI applications discover and call these capabilities in the first place.

Some agent wallet platforms are dual-rail, pairing stablecoin payments with virtual Visa and Mastercard credentials carrying their own spending caps — useful when the thing an agent needs to buy does not accept crypto.

Building one: the practical sequence

1. Decide where policy lives. On-chain session keys if you want verifiable guarantees; a TEE-backed server wallet if you need speed, multichain support or card rails. Most teams end up with both.

2. Separate the authentication key from the funds key. The agent proves who it is with one key; a different key controls money. Never let the agent hold the master.

3. Scope the session key narrowly, then narrow it again. Specific contracts, specific method selectors, a spend cap you would be comfortable losing, and the shortest expiry that still lets the task complete.

4. Fund a dedicated sub-account. Not your treasury. Not your main wallet.

5. Add an out-of-band circuit breaker. Aggregate spend limits enforced by your own service, outside the model and outside the agent’s reach.

6. Validate everything the agent reads. Signed tool responses, strict schema validation, and transaction simulation before contract interaction.

7. Log every request and signature. When something goes wrong, the difference between an incident and a mystery is whether you can reconstruct what the agent saw and why it acted.

What still goes wrong

• Prompt injection. A hostile page or document instructs the agent to transact. Policy limits contain the damage; they do not prevent the attempt.

• Over-scoped sessions. The most common real-world failure is not an exotic exploit, it is a session key granted broad permissions for convenience during development and never tightened.

• Off-chain policy trust. If enforcement lives in a provider’s API, a compromise there bypasses your controls entirely. This is the argument for on-chain enforcement.

• Liability. If an agent makes an erroneous payment, responsibility between user, developer, model provider and platform remains unsettled across the industry.

• Standard fragmentation. x402, AP2, ERC-8004 and proprietary layers are converging rather than settled, so integration choices made today may need revisiting.

The bottom line

An agent wallet is not a new kind of cryptography. It is the same keys and signatures with the approval logic relocated — out of a human’s hands and into a contract, an enclave or a policy engine.

If you take one design principle away, take this: assume the agent will sign whatever it is asked to sign, and build so that this does not matter. Scoped session keys, on-chain limits, a funded sub-account and a circuit breaker will do more for your safety than any amount of careful prompting.

The tooling to do all of this is live, largely open-source, and mostly free at small scale. The barrier now is design discipline rather than technology.

Important

This article is a general technical explainer, not security, financial or legal advice, and not an endorsement of any provider or standard. The code shown is illustrative pseudocode, not production code, and has not been audited. Systems that allow software to hold and spend funds carry substantial risk including total loss. Standards referenced may be in draft and subject to change. Anyone deploying agent wallets against live funds should commission an independent security review and start with amounts they can afford to lose entirely.

Sources

Ethereum Improvement Proposal documentation for ERC-4337, EIP-7702, ERC-7715, ERC-8004 and draft ERC-8199, MetaMask server wallet architecture documentation, plus technical write-ups and product documentation from Openfort, Crossmint, thirdweb, Turnkey, Circle and Eco.

Bitnxt tracks wallets, payment infrastructure and crypto technology providers across the US, UK, EU and UAE. Explore the directory at bitnxt.io.