What Is an Agent Wallet?
An agent wallet is an account or credential that lets an AI agent hold or spend money on its own, within limits set by the person or company it acts for. Many agent wallets are onchain wallets the agent uses through an API while the keys stay in an isolated enclave the agent cannot reach, with caps per transaction or per session. The term is also used for setups where the agent holds a tokenized card credential instead of keys. A wallet's own checks cover only that wallet; a budget shared by several agents has to be tracked by whoever runs them.
Updated
What is an agent wallet?
Agents increasingly need to pay for things in the middle of a task: one API response, a data lookup, compute, a purchase. A person approving each payment defeats the point, and handing an agent a card number or a raw private key is unsafe. An agent wallet is the compromise: the agent can pay without a human in the loop, and the wallet limits what it can do.
Coinbase's Agentic Wallets, announced February 11, 2026, show the typical shape. The launch post lists "Session caps: Set maximum amounts agents can spend per session," "Transaction limits: Control individual transaction sizes," and "Enclave isolation: Private keys remain in secure Coinbase infrastructure, never exposed to the agent's prompt or LLM," and it puts x402 "At the core of Agentic Wallets" for paying per request. The same post describes them as "non-custodial wallets secured in Trusted Execution Environments (TEEs)," so the keys sit in Coinbase's infrastructure without Coinbase taking custody of the funds.
Three variants are common:
- 1.Agent-held wallets. The agent has its own balance; the keys usually sit in an enclave run by the wallet provider, which applies the limits before anything is signed.
- 2.Delegated allowances. The user keeps the wallet and grants the agent's address a capped allowance. In Coinbase's spend permissions, each permission has an
allowance, the "amount of tokens spendable per period," and aperiodthat resets it. - 3.Card-based wallets. The agent holds a tokenized card credential instead of keys, such as agentic tokens in Mastercard Agent Pay or the tokenized credentials in Visa Intelligent Commerce.
How an agent wallet works
Follow one payment and note who checks what. An agent calls a paid API, gets a price back, and decides to pay.
| Check | Who runs it | What it can see |
|---|---|---|
| Signature, balance, replay | The chain, or an x402 facilitator | This payment |
| Session cap, per-transaction limit, screening | The wallet provider | This wallet |
| Allowance per period | The spend-permission contract | One account, spender and token |
| Shared budget, per-agent share, payments in flight | The agent platform | Every agent |
Each layer is correct within its scope. The problem is composition. An illustrative team runs twelve agents, each with its own wallet and a USD 5.00 session cap, under a USD 40.00 daily budget. Twelve USD 5.00 session caps add up to USD 60.00, so every wallet's check can pass while the team overspends. Only the bottom row sees the team total, and the wallet leaves that row to you. It is the platform's authorization-time context: remaining budget net of payments already signed, per-agent limits and recent spend, read at the moment the agent signs.
The platform-side check has the same structure wherever money moves: before the agent signs, reserve the amount against every budget it touches in one transaction, record the payment intent, and settle or release the reservation when the result comes back. The x402 post walks through it with SQL.
Why agent wallets matter in real-time systems
Coinbase's spend-permission design explains why it keeps the allowance onchain: "Given the fragility and complications with doing this accounting offchain and the severity of inaccuracies, we designed for fully onchain accounting." That rigor covers one permission. A budget that spans many wallets, agents or payment rails, card rails included, usually has no single contract to hold it. It has to live in the platform's own state, with the same accuracy, under concurrent agents.
Tacnode enforces nothing inside a chain's, a wallet provider's or a card network's ledger. What it can hold is the platform's side: per-agent limits, reservations and payment intents held in Tacnode are covered by ACID transactions, so two agents cannot both reserve past the same cap, and derived reads such as spend per agent in the last hour run on demand against the latest committed data. Concurrency for agent decisions is covered in ACID for agents.
FAQ
Related terms
Agentic tokens are network payment tokens issued for an AI agent, so it can pay without the card number and issuers can see the payment came from an agent.
An agent mandate is a signed record of what a user authorized an AI agent to buy: one exact purchase, or constraints such as a budget the agent must keep to.
Agent spend limits cap what an AI agent may commit per transaction, period or agent. They are only as accurate as the spend total they are checked against.
Authorization-time context is everything a payment or purchase decision must read when it authorizes: mandate status, remaining budget, limits and recent spend.
Multi-writer contention is two or more actors reading and writing the same mutable state in the same short window. It is not multi-tenancy or partitioning.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.
