What is an agentic wallet?
A wallet an AI agent can spend from without asking you each time. The whole design question is what stops it, and the answers differ.
In short: If you want an AI agent to run a strategy while you sleep, an agentic wallet is a crypto wallet it can spend from on its own, inside limits set in advance. What matters is what the agent is able to write down, and who can change the limits. Here the agent holds no key. It is a contract your account gives permission to act, it picks from a fixed set of actions and can’t set an address, and spending caps are set on your own account on the chain.
An agentic wallet is a crypto wallet an AI agent can spend from on its own, inside limits somebody set in advance. It needs no approval pop-up for each action and no human at the keyboard at 3 a.m.
That is the easy half of the definition. The hard half, and the one that separates the products, is the second clause: inside limits somebody set in advance. The design comes down to what the limits are and what enforces them.
Why the idea exists at all
An ordinary wallet assumes a person. Every transaction waits for a human to look at it and press something. That is a good assumption for buying a token and a terrible one for anything that has to react: a position that needs rebalancing when a price moves, a loan that needs topping up before it liquidates, rent that arrives on the first of the month.
Every action waits for you. The strategy runs when you remember, at a price you did not choose, and stops the month you are busy.
The agent acts inside bounds you set. The strategy keeps running when you are asleep, and the bounds are what you are trusting.
Every agentic wallet is a bet that the second column can be made safe enough to be worth it. They differ in what they bet on.
What makes it possible: account abstraction
None of this works with an ordinary wallet.
An ordinary wallet is an address controlled by one private key. Every transaction is signed by that key, and anything holding the key can do anything. There is no way to say “this party may do these three things, up to this amount”, because the key is all-or-nothing.
Account abstraction makes the account a contract instead, so the rules about who may do what are code. That is the enabling change, and three consequences of it show up in every agentic wallet:
- The account can give a contract permission
- So an agent need not be a keypair, and a plain key can be refused outright
- Permissions can be scoped
- Named operations, with a cap per asset and per period, rather than full authority
- Someone else can pay the gas
- Which is why you never hold the native coin of a chain you have not used
The standards are ERC-4337 for the account and ERC-7579 for the permission modules. You do not need to know those numbers to use any of this; they matter because “the agent cannot take your money” is a claim, and this is the layer where code enforces that claim instead of a promise.
The three designs on offer
- The agent holds a key
- Simplest and most common in early builds. The agent has a private key and is asked, in software, to behave. Whatever persuades the agent has the key.
- The agent holds part of a key
- MPC or multisig. No single party can sign alone, and policies cap what gets co-signed. The dominant commercial answer today.
- The agent holds no key at all
- The agent is a contract your account gives permission to. It can ask for a named operation and nothing else. This is the design here.
The industry is converging on the view that the first one is indefensible. Coinbase has argued publicly that AI agents should not hold private keys, and the reasoning is simple: an agent holding its own key is one successful prompt injection away from sending everything to an attacker’s address.
The question that separates them
More than how strong the limits are, the question is what is the agent able to express?
A policy engine is a filter. It sits between an agent that can compose any transaction and a chain that will execute one, and it says yes or no. Filters are evaluated against the attacks somebody already thought of, and a filter that has to decide whether “send 3 billion tokens to 0xabc…” is legitimate is doing a hard job under adversarial pressure.
The alternative is to make the harmful transaction impossible to write.
Injection you cannot prevent. Expressiveness you can remove.
Here, the agent does not compose transactions. It picks an operation from a fixed set and fills in its details. It can’t set a destination address or a payload. Destinations are your own account, looked up from your account at the moment a step runs.
A malicious instruction has nowhere to be written, so nothing has to detect it.
What people get wrong about this
“Agentic means the AI has my money”
It does not, in any of the three designs, and least of all in the third. Here your funds sit at an address derived from your own address. You are the sole owner, permanently. The agent cannot hold a token at any point in a plan, and neither can the key that pays network fees.
“The limits are a setting, so someone can change them”
That depends entirely on where the limits live. A spending cap enforced by a server is a policy. The operator cannot raise a spending cap enforced by your account on the chain, because the account only answers to you.
- Where the cap lives
- Whether the operator can raise it
- In the product’s backend
- Yes, by deploying different code
- In a policy engine the operator runs
- Yes, by changing the policy
- In your account, on the chain
- No
“Non-custodial” is a marketing word
It is a testable one. There is a single question that settles it: can you get your money out with no cooperation from the operator, and with their servers switched off? If the answer needs a support ticket, a withdrawal queue, or their signature, it is custody with extra steps.
What to ask a vendor
Four questions, none of which need you to trust a security page.
- What is the agent able to write down?
If the answer includes an address, every other control is a filter standing between a persuadable model and your funds.
- Where is the spending cap enforced?
On their server, or in an account only you control? Ask what happens to the cap if they want to change it.
- Can I leave with your servers off?
And has anyone done it? A recovery path nobody has exercised is a guess.
- What is the worst case for a fully compromised agent?
A good answer is a number you set. A vague answer means nobody has computed it.
The honest state of this category
It is early, and the incident data says so. Enterprises deploying autonomous agents have reported security incidents at a rate that makes “it has not happened to us” an unhelpful defence, and over $45 million was lost to agent protocol weaknesses in the first quarter of 2026 alone, much of it by attacking agents’ memory and the protocols connecting them to their tools, rather than by breaking any cryptography.
An agentic wallet trades a human check for a structural one, and that alone does not make it safer. Whether the trade is good depends on how much the structure really enforces. You can ask that precisely, and you should.