# Agentic wallets compared: where the limits actually live

> Every one of them enforces spending limits. They differ in where the enforcement sits, and that decides what happens when the operator is wrong.

- Source: https://defiloops.com/blog/agentic-wallets-compared-where-the-limits-live
- Published: 2026-06-09
- Category: Architecture
- Tags: agentic-wallet, comparison, ai-agents, custody
- Author: DeFiLoops

---
Read the marketing for any agentic wallet and you get the same list: least privilege, scoped
permissions, per-transaction and daily caps, allowlists, human approval for anything
irreversible. Everyone has it. It tells you almost nothing.

The question that separates them is not *whether* there are limits. It is **where the limits
are enforced**, because that decides who can change them and what survives the operator
having a bad day.

## The four places a limit can live

<Spec title="Where enforcement sits" rows={[
  ['In a policy engine the operator runs', 'MPC or multisig plus rules. The operator can change the policy'],
  ['In a trusted execution environment', 'Caps enforced by the signing infrastructure, ahead of time'],
  ['In a human', 'Someone approves exceptions. Strong, and it does not scale to 3am'],
  ['In your own account, on the chain', 'The account only answers to you, so nobody else can raise it'],
]} />

None of these is fake. They fail differently, which is the useful thing to know.

## Who does what

Everything here is from each vendor's own published material. Where a product does something
better than we do, it says so.

<Spec title="The main approaches, as of late 2026" rows={[
  ['DeFiLoops', 'The agent is a contract your account appoints and holds no key — a plain key cannot be appointed at all. It fills a fixed form drawn from a closed catalogue of 61 operations, with no field for a destination address: destinations are roles resolved from your account at run time. Caps are fixed in your account, per asset and per period, and nothing on our side can raise them. The appointment is one-way, and revocation is one transaction from your own wallet. ERC-4337 account, ERC-7579 permission modules. 3 chains'],
  ['Cobo Agentic Wallet', 'MPC, non-custodial by default with an optional custodial mode. Policies are declared as a “Pact”: task intent, execution boundaries, stopping point. Out-of-policy actions get denial feedback so the agent can retry inside scope. Human approval via web, mobile, Telegram and Discord, plus an emergency freeze. 80+ chains'],
  ['Coinbase AgentKit', 'Keys isolated in a trusted execution environment and never exposed to agent code. Programmable spend controls enforced at the TEE: session caps, per-transaction caps, allowlisted contracts. Bundles a payment client and a gasless rail on Base. 5 chains'],
  ['MetaMask Agent Wallet', 'A guard mode built around human-in-the-loop approval for policy exceptions'],
]} />

<Callout type="note" title="Chain coverage is not close, and it matters">
  Cobo supports 80+ chains. Coinbase supports five. We support three. If your agent needs to
  touch a chain we have not integrated, none of the rest of this page helps you — that is a
  real and immediate reason to pick something else.
</Callout>

## What actually differs

Strip away the shared vocabulary and there are two genuine axes.

### 1. Can the operator raise your cap?

<Compare left="A cap in a policy engine" right="A cap in your account" verdict>
  <Fragment slot="left">
    Enforced by software the operator runs. Changing it is a config change or a deploy — a
    thing they can do, whether or not they would.
  </Fragment>
  <Fragment slot="right">
    Enforced by a contract that only answers to your signature. There is no administrative
    path to raise it, including for us.
  </Fragment>
</Compare>

This is not an accusation. A policy engine is a real control and a well-run one is
trustworthy. It is a statement about what remains true if the operator is compromised,
acquired, or subpoenaed.

### 2. What can the agent write down?

This is the one we think is underrated, and it is narrow.

Coinbase's **allowlisted contracts** is the closest thing in the field to our design: the
agent may only reach approved addresses. That is a meaningful reduction in blast radius and
it is a good idea.

The difference is a step further along. In an allowlist model, the agent still composes a
transaction containing a destination, and something checks that destination against a list.
In ours there is **no field for a destination at all** — destinations are roles like "the
owner's account", resolved from your account when the step runs.

<Quote>
  An allowlist answers "is this address permitted?" correctly. Removing the field means
  nothing has to answer it.
</Quote>

Both stop the same attack today. They fail differently: an allowlist has to be right about
every address on it, and a missing field has nothing to be right about.

## Where each one is stronger than us

Worth stating flatly, because a comparison that flatters its author is not a comparison.

<Spec rows={[
  ['Cobo', '80+ chains against our 3, enterprise operations, human approval routed to Telegram and Discord, and an emergency freeze — we have revocation, which is not the same thing as a fast operational kill switch across a fleet'],
  ['Coinbase', 'TEE key isolation is a stronger story than “a key in memory”, which is exactly why our keeper service refuses to start in production today. Five chains, a payment rail, and a gasless path on Base'],
  ['MetaMask', 'Human-in-the-loop for exceptions is the most legible control there is. If your use case can tolerate a person in the path, it is hard to beat'],
]} />

## The questions that actually settle it

Four, and none of them require trusting anybody's security page — ours included.

<Steps>
  <Step title="Where is the cap enforced, and who can raise it?">
    “In your account, on the chain” and “in our policy engine” are both real answers. They are
    not the same answer.
  </Step>
  <Step title="What can the agent express?">
    If a destination address is a field the agent fills in, every control is a filter judged
    against attacks somebody already imagined.
  </Step>
  <Step title="Can you leave with the operator’s servers off?">
    And has anyone done it? This is the only test of “non-custodial” that means anything.
  </Step>
  <Step title="What is the worst case for a fully compromised agent, as a number?">
    A good answer is a figure you set. A vague answer means nobody computed it.
  </Step>
</Steps>

## Our own honest column

The same scrutiny, applied here.

The agent holds no key and cannot name a destination. Caps live in your account and nothing
on our side can raise them. The appointment is one-way: your account can never be re-pointed
at a different agent, only at none.

And: the guard works as a list of banned actions rather than permitted ones. It completely
blocks a takeover but does not block every way value could move through an action nobody
thought to ban — **we have proven four such attacks against ourselves**. There is **no
external audit**. Our keeper service refuses to start in production because it keeps its key
in memory, which is precisely the problem a TEE solves and we have not solved yet.

Three chains. Nine protocols. If that is not enough for what you are doing, the rest of this
does not matter.

## The short version

If you need breadth, Cobo's chain coverage is not close. If you are a developer wanting keys
your code cannot touch, Coinbase's TEE model is the cleanest in the field. If you want a
person in the loop, MetaMask has built for that.

If what you care about is that nobody — including the operator — can raise your limit or
redirect your funds, then the question to ask everybody is where the cap lives and whether a
destination is a field. Those two answers sort the category faster than any feature table,
including this one.