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.
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
- 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.
- 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
What actually differs
Strip away the shared vocabulary and there are two genuine axes.
1. Can the operator raise your cap?
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.
Enforced by a contract that only answers to your signature. There is no administrative path to raise it, including for us.
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.
An allowlist answers “is this address permitted?” correctly. Removing the field means nothing has to answer it.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
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.