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.
An agentic wallet is a crypto wallet an AI agent can spend from on its own, inside limits somebody set in advance. No approval pop-up for each action, no human at the keyboard at three in the morning.
That is the easy half of the definition. The hard half — the half that separates the products — is the second clause: inside limits somebody set in advance. What the limits are, and what enforces them, is the entire design.
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 actually 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.
The substrate: account abstraction
None of this is possible with an ordinary wallet, and it is worth knowing why.
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” — 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 appoint a contract
- 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 a claim becomes enforcement rather than 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 appoints. 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 uncomplicated: an agent holding its own key is one successful prompt injection away from sending everything to an attacker’s address.
The question that actually separates them
Not “how strong are the limits” but what is the agent able to express?
A policy engine is a filter. It sits between an agent that can compose an arbitrary 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 sentence unsayable.
Injection you cannot prevent. Expressiveness you can remove.
Here, the agent does not compose transactions. It fills in a fixed form of labelled boxes, drawn from a closed list of operations. There is no box for a destination address and no box for a payload. Destinations are roles — “the owner’s account” — resolved from your account at the moment a step runs.
So the malicious instruction has nowhere to be written. 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. A spending cap enforced by your account on the chain is not something the operator can raise, 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 actually 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 is not a safer wallet. It is a wallet that has traded a human check for a structural one. Whether that trade is good depends entirely on how structural the structure really is — which is a question you can ask precisely, and should.