# 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.

- Source: https://defiloops.com/blog/what-is-an-agentic-wallet
- Published: 2026-07-14
- Category: Architecture
- Tags: agentic-wallet, ai-agents, account-abstraction, custody
- Author: DeFiLoops

---
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.

<Compare left="An ordinary wallet" right="An agentic wallet" verdict>
  <Fragment slot="left">
    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.
  </Fragment>
  <Fragment slot="right">
    The agent acts inside bounds you set. The strategy keeps running when you are asleep,
    and the bounds are what you are actually trusting.
  </Fragment>
</Compare>

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:

<Spec rows={[
  ['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

<Spec title="How agentic wallets constrain an agent" rows={[
  ['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.

<Callout type="warn" title="Most of the argument is about the second row">
  MPC with policy limits is a real improvement and it is where most of the market sits. Our
  disagreement with it is narrow and specific, and it is in the next section rather than in
  an adjective.
</Callout>

## 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.

<Quote cite="The structural version of the argument">
  Injection you cannot prevent. Expressiveness you can remove.
</Quote>

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.

<Callout type="note" title="This is a narrower claim than “safe”">
  It stops an agent being talked into paying an attacker. It is not a claim that every way
  value could move has been closed — see the security post for the four attacks we have
  proven against ourselves, and the fact that there is no external audit.
</Callout>

## 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.

<Spec rows={[
  ['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.

<Steps>
  <Step title="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.
  </Step>
  <Step title="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.
  </Step>
  <Step title="Can I leave with your servers off?">
    And has anyone actually done it? A recovery path nobody has exercised is a guess.
  </Step>
  <Step title="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.
  </Step>
</Steps>

## 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.