--- title: "give an agent a wallet and you've built a target" canonical_url: https://ensurance.app/guide/give-an-agent-a-wallet-and-youve-built-a-target markdown_url: https://ensurance.app/guide/give-an-agent-a-wallet-and-youve-built-a-target.md subtitle: "what an ai agent wallet needs before money goes in: an owner, a name, and spending limits that default to no" category: onchain --- # give an agent a wallet and you've built a target *what an ai agent wallet needs before money goes in: an owner, a name, and spending limits that default to no* An agent with a wallet and no rules isn't autonomous. It's an open tab. The question every builder skips is the plain one: who is allowed to empty it? An **AI agent wallet** is an account that software controls so it can hold and send money without a person approving each step. That is the useful part. It is also the whole risk. A key that can pay is a key that can be asked to pay, tricked into paying, or stolen and used to pay. The more an agent can do alone, the more a wallet with nothing around it looks like a prize. This is the second post in a series that starts with [what the agent wave skipped](/guide/every-agent-got-a-wallet-the-earth-didnt?from=guide). This one is about the money inside the wallet, and what has to exist before any goes in. ## what the wave got right Payment rails for agents are real. Standards such as x402 let a program pay a service per request, in the same web call it makes to ask. Chainalysis counted more than 138 million x402 payments on Base by the third quarter of 2026, and more than 87% of them were between a hundredth of a cent and a dime. That is a count of payments, not dollars, and not every one was sent by an autonomous agent. ERC-8004, a draft Ethereum standard, gives an agent an onchain identity and a place to collect feedback, and its identity and reputation registries are deployed on Ethereum mainnet. The draft also specifies a third registry for independent checks of an agent's work. These are good tools, and *ensurance* is built to speak x402. None of them answer who may spend what. A registry names an agent. A payment rail moves value. Neither tells the agent when to stop. ## what is an ai agent wallet? Many agent wallets are still a key pair with a balance. The key belongs to whoever made it, the limits live in the developer's code, and the agent has no name beyond an address. Smart accounts with session keys and spend permissions do better, and they are worth using. They still leave open what the account is for. That works until the first bad prompt. If the only rule is "the model will behave," the wallet is one injected instruction away from a transfer nobody intended. A line in the system prompt is a hope, not a limit. A sturdier design starts from a different question. Not "what can this key do?" but "what is this account, who owns it, and what has its owner allowed?" :::johnson **an agent's wallet is only as safe as the spending caps that default to no.** A cap nobody set should mean no, not yes. [turn an nft you already hold into an agent with its own account →](/guide/how-to-turn-an-nft-into-an-agent?from=guide) ::: ## who owns an agent's wallet? On *ensurance*, an agent is an NFT with an account of its own, a tokenbound account on Base. The account is not a separate key someone has to guard. Its address is set by the token, and **whoever holds the NFT controls the account**. Sell the NFT and the account goes with it. Lose track of it and you lose the agent, which is the same risk as any other thing you own. The protocol covers the setup cost. Creating the account is permissionless, so the protocol's own gas wallet can deploy it for the owner. In a measurement across 28 real deployments on 2026-07-27 it came to about three-tenths of a cent each on Base. The owner never sees a "deploy" step and does not hand over control by letting someone else pay. The same account can belong to a place, a group of people, or a purpose. Most agent wallets are for a bot. This one is for a watershed, a neighborhood or a cause, and the money it holds is meant to go back to that place. The sibling post on [turning an NFT into an agent](/guide/how-to-turn-an-nft-into-an-agent?from=guide) walks the steps, so this one will not repeat them. More than two thousand agents exist this way today. ## a name before a balance Every agent carries an identity record: a **purpose**, a **mandate**, a **place**, a short bio and a voice. This is the part a bare wallet lacks. It is what the agent is for, written down where the rules can read it. It is not the same as a registry entry. A registry says who. The record says what for, and the limits sit next to it. For the longer argument that a mandate has to come before a wallet, see [an agent needs a mandate before it needs a wallet](/guide/an-agent-needs-a-mandate-before-it-needs-a-wallet?from=guide). ## what stops an agent from draining it? Four things, in order of how little they trust the agent. **Spending caps that fail closed.** When an agent acts alone, its mandate is checked first. If the owner never set a per-action cap, the answer is no. If the dollar value of the action can't be worked out, the answer is no. If there is no cap on the rolling window (a day by default), the answer is no. A spend over the per-action cap is refused. A spend that would push the rolling window over its cap is refused. Nothing in that path reads a gap as permission. **Allowlists as hard gates.** An owner can name the tokens, the recipients and the kinds of action an agent may use. Once a list exists, anything off it is refused. One honest note: an empty list means no restriction on that axis, so the caps are the floor and the lists are the fence. **Fixed actions, never raw code.** An agent does not hand the system a blob of transaction data and ask it to run. It picks from a short list of typed actions, such as swap, buy, sell, transfer and attest, each with its own checks, through one dispatcher. A prompt injection can ask for a strange action. It cannot invent one. **No creating instruments.** Agents never create or deploy new coins or certificates. Humans do that. An agent may suggest one and may receive proceeds once a person has made it. | | bare agent wallet | an agent account with a mandate | |---|---|---| | who owns it | whoever made the key | whoever holds the NFT | | what it is for | in the developer's code | written in its identity record | | spending cap never set | often allowed | refused | | what it can send | anything the key signs | typed actions, within caps | | new instruments | not applicable | humans only | ## a person can still hold the pen Autonomous is one of three settings, not the only one. In manual mode a person approves each action. In automated mode a fixed program runs the same way every time, with no model involved. Only in autonomous mode does a model choose, and only inside the mandate above. The same account can run any of them, and the owner turns the dial. The next post in the series covers that dial. ## where this leaves us This is early. The design is built and agents exist, and it does not make an agent wise. A mandate stops a loss. It does not make a good decision, and caps do nothing for an owner who sets them badly. What it gives is a record you can check and a limit that is still there on the day the model is wrong. Agent wallets, x402 and MCP are the rails. The rest is deciding who owns the account and what it is for. For an agent that works for a living system, the answer to "what for" is a place, and the proceeds go to that place first and then to the people who look after it. ## frequently asked questions ### what is an ai agent wallet? An account that software controls so it can hold and send money without a person approving each action. On *ensurance* it is a tokenbound account attached to an NFT, so it has an owner and a name, not just a key. ### who owns an agent's wallet? Whoever holds the agent's NFT. The account's address is fixed by the token, and control follows the token when it moves. ### what stops an agent from draining it? Caps that refuse any spend when a limit is missing or the value is unknown, allowlists that act as hard gates once set, a short list of typed actions instead of raw code, and a rule that agents never create new instruments. Read the [mandate post](/guide/an-agent-needs-a-mandate-before-it-needs-a-wallet?from=guide) for why the limits come first. ### is this crypto? In part. A public ledger (Base) keeps the ownership and the account. The limits are enforced by the *ensurance* service before anything is signed, not by the ledger. If you build agents, [see how to deploy one with its own account and mandate, or work from the API](/solutions/ai-agents?from=guide&topic=agents). ## sources [Chainalysis via Fortune, 2026-10-14](https://fortune.com/2026/10/14/ai-agents-shopping-spree-payments-base-blockchain-138-million-chainalysis/) — more than 138 million cumulative x402 transactions on Base; more than 87% between $0.0001 and $0.10 [ERC-8004: Trustless Agents, ethereum/ERCs](https://github.com/ethereum/ERCs/blob/master/ERCS/erc-8004.md) — the draft standard: identity, reputation and validation registries [ERC-8004 reference contracts](https://github.com/erc-8004/erc-8004-contracts) — mainnet addresses for the identity and reputation registries ## the series Seven posts on the agents we built for the economy nobody pays. 1. [every agent got a wallet. the earth didn't](/guide/every-agent-got-a-wallet-the-earth-didnt?from=guide) 2. [give an agent a wallet and you've built a target](/guide/give-an-agent-a-wallet-and-youve-built-a-target?from=guide) — this post 3. [autonomous is a setting, not a personality](/guide/autonomous-is-a-setting-not-a-personality?from=guide) 4. [trust the receipt, not the agent](/guide/trust-the-receipt-not-the-agent?from=guide) 5. [plug your model into the living world](/guide/plug-your-model-into-the-living-world?from=guide) 6. [nobody was coming, so we built the market](/guide/nobody-was-coming-so-we-built-the-market?from=guide) 7. [the first invoice a river ever sent](/guide/the-first-invoice-a-river-ever-sent?from=guide)