MetaMask Agent Wallet: How Self-Custodial AI Trading Works

MetaMask launched Agent Wallet on August 6, 2026: a self-custodial wallet built for AI agents to execute on-chain transactions on your behalf, inside limits you set in advance. You keep the keys and can export your Secret Recovery Phrase at any time. The agent gets restricted permissions, not control.

That framing is the whole product. Every agent framework that can trade has faced the same unsolved problem. The runtime can decide what an agent is allowed to read, but nothing in the runtime decides what it is allowed to spend. Agent Wallet moves that decision to the wallet, where it can actually be enforced.

Here is what it does, what it costs you in control, and where the documentation is thinner than the coverage suggests.

What Agent Wallet actually is

Agent Wallet is a self-custodial wallet with a policy engine and a CLI. You connect an agent framework, define operating parameters, and the agent transacts through the wallet rather than holding key material of its own. MetaMask’s own description of the design goal is eliminating the choice between agent autonomy and fund security by layering safeguards instead of picking one.

Mechanically, three things are set before an agent does anything:

• Spending limits — a daily outflow ceiling the agent cannot exceed
• Protocol allowlists — the specific contracts and protocols the agent may interact with
• A risk profile — which determines how much gets waved through versus escalated to you

Keys stay under user control, through either a server-side dedicated wallet or user-supplied key material. This is the meaningful distinction from letting an agent drive a custodial exchange account through an API key: with a custodial account, the exchange holds the assets and your API key is the only thing standing between an attacker and them. Here, the constraint is enforced at the signing layer.

Guard Mode and Beast Mode

Two operating modes ship, and the difference is how often you get interrupted.

	Guard Mode	Beast Mode
Default	Yes	Opt-in
Daily spend limits	Enforced	Enforced
Protocol allowlist	Enforced	Enforced
Transaction outside your policy	Requires human approval	Fewer approval interruptions
Flagged or malicious transaction	Blocked or escalated	Still requires 2FA

Guard Mode is the default and enforces daily spend limits, allowlisted protocols, and human approval for anything falling outside your stated policy. Beast Mode is the opt-in alternative that reduces approval interruptions while keeping the security checks running underneath. Transactions flagged as malicious still demand two-factor approval.

The honest reading of Beast Mode is that it trades oversight for throughput. It does not disable the scanning pipeline, but it does mean fewer moments where a human sees what is about to happen. For a strategy running unattended overnight, that is the point. For a wallet holding meaningful size, Guard Mode is the setting that matches what most people say they want when asked.

The three-step transaction pipeline

Supported EVM transactions pass through a mandatory pipeline before signing. This is the part that has no equivalent in any agent runtime, and it is the reason the product exists.

1. Simulation. The transaction is executed against current state first, surfacing balance changes, token approvals, and gas before anything is signed. Approval-drainer attacks, where the damaging action is an unlimited token approval rather than a transfer, become visible at this step, which is exactly where they are normally missed.
2. Threat scanning. Powered by Blockaid and, in MetaMask’s description, production-tested across millions of MetaMask transactions. Transfers identified as malicious are auto-rejected rather than surfaced as a warning to click through.
3. Smart transaction execution. MEV protection against front-running, plus gas optimization, where available.

Two caveats belong next to that list. The pipeline covers supported EVM transactions, and not every transaction qualifies. And simulation reflects state at simulation time; a contract designed to behave differently on execution is a known class of evasion.

Transaction Shield: what the coverage actually is

Agent Wallet includes up to $10,000 per month in Transaction Shield coverage, subject to terms and eligibility. It is worth being precise about the conditions, because secondary coverage has described this loosely.

The coverage applies when an eligible transaction clears all three pipeline stages — simulation, Blockaid threat scanning, and Smart Transactions MEV protection — and still results in a loss. In other words, it backstops the pipeline’s own false negatives. It is not general insurance against agent error, and it does not cover a loss from a transaction you approved that the pipeline correctly flagged, or from a strategy that simply lost money on the trade.

Read that as a statement of confidence in the scanning stack rather than as a safety net for autonomous trading generally. It is a real feature, and it is narrower than “$10,000 loss protection” implies.

How this compares to giving an agent an exchange API key

Before Agent Wallet, the standard way to let an agent trade was to issue it an exchange API key with trading permissions. That comparison is the clearest way to see what changed.

	Exchange API key	Agent Wallet
Who holds the assets	The exchange	You
If the key leaks	Attacker acts as you on your full balance, subject to exchange limits	Attacker is bounded by your spend limit and protocol allowlist
Malicious destination	Withdrawal allowlist, if you configured one	Auto-rejected by threat scanning before signing
Visibility before execution	None; you see the fill afterwards	Simulation shows balance changes and approvals first
If the counterparty fails	Your assets are on their balance sheet	Your keys, your assets
Scope	Centralized venue only	On-chain, supported EVM networks

The row that carries the most weight is the last-but-one. An API key delegates authority over assets someone else is holding. Agent Wallet delegates bounded authority over assets you are holding. Those are different in kind, not degree, and it is the same distinction that separates custodial and non-custodial payment processing on the merchant side.

Which agent frameworks connect

MetaMask names six supported frameworks: Claude Code, Codex, OpenClaw, Hermes, OpenCode, and Cursor. Agents integrate through a CLI exposing mm commands.

That roster is a useful signal about where agentic trading actually happens. It is general-purpose coding and automation agents, not crypto-specific trading bots. Four of the six have direct relevance if you have been following this space:

• OpenClaw — the largest of the group by contributor count, and the one whose 2.0 release on August 31 hardened local permissions while leaving spending controls entirely to the wallet layer. Agent Wallet is the complement to that release, not a competitor to it.
• Hermes — Nous Research’s self-learning agent. Our guide to Hermes Agent covers how its autonomy model differs, which matters here because a self-modifying agent is precisely the case where an externally enforced spend ceiling earns its keep.
• Claude Code — the most common entry point for developers building payment automation, including the MCP server patterns we have documented.
• Codex and Cursor — general coding agents, included presumably because developers already run them with broad local permissions.

If you are choosing between the first two, our Hermes versus OpenClaw comparison works through the differences in autonomy and security posture.

Networks: what is documented and what is not

This deserves care, because the numbers circulating in coverage are not all sourced from MetaMask.

The documentation states support for multiple EVM-compatible chains and specifies that the exact roster varies by CLI version. The current list comes from running mm chains list. HyperLiquid and Robinhood are named directly in the launch material, and Ethereum and Base appear as typical networks in the documentation. Various secondary reports cite a fixed chain count; that figure does not appear in MetaMask’s own materials, and given that the roster is explicitly version-dependent, treat any hard number as unverified.

The practical takeaway: check mm chains list against your own CLI version rather than trusting a count from a news article.

Setting it up without undoing the point

The failure mode with a policy engine is configuring it until it stops interrupting you, at which point you have a fast agent and no guardrails. Four settings decide whether that happens.

• Set the daily limit against what you would accept losing, not against what the strategy needs. These are different numbers, and only the first one is a limit. If the strategy genuinely requires more headroom than you are comfortable losing in a day, the strategy is the thing to revisit.
• Keep the protocol allowlist short and add to it deliberately. Every entry is a contract you are pre-authorizing an automated party to interact with. An allowlist that grew by reflex during a debugging session is not a control.
• Start in Guard Mode and stay there until the agent has a track record. Beast Mode’s value is removing interruptions from a workflow you already trust. It is not a starting configuration.
• Fund the wallet with a working balance, not a treasury. The policy engine caps outflow per day; it does not reduce what is sitting there to be reached if something upstream goes badly wrong. A dedicated wallet holding a working balance keeps the worst case bounded by the balance as well as by the policy.

That last point is the one most likely to be skipped, and it is the cheapest to implement. Every control in this product operates on transactions. None of them operate on the balance.

What this solves, and what it does not

Agent Wallet closes a specific and previously open gap. Before it, an agent trading on your behalf ran on trust plus whatever the runtime happened to restrict, and the runtime restricts files and hosts, not dollars. Daily ceilings, protocol allowlists, pre-signing simulation, and auto-rejection of malicious transfers are all controls that had no home.

Three things it does not solve:

It does not make an agent’s judgment good. A transaction inside your limits, to an allowlisted protocol, that passes threat scanning, and that is simply a bad trade, executes normally. The guardrails bound your losses; they do not produce gains.

It does not cover non-EVM assets. Bitcoin, Lightning, and Tron-based stablecoin transfers sit outside an EVM transaction pipeline entirely. If your holdings are meaningfully in USDT on Tron or in Bitcoin, this product does not reach them.

It does not address the receiving side. Agent Wallet governs an agent spending your funds. It has nothing to say about how a business gets paid, which is a different problem with a different custody question, and one worth separating clearly.

The same principle on the receiving side

What makes Agent Wallet interesting is not the feature list. It is that MetaMask concluded the way to make automation safe was to keep custody with the user and constrain what the automated party can do, rather than to hold funds centrally and promise to be careful.

That is the same conclusion, reached independently, that applies to accepting crypto payments. When a customer pays a business through a custodial processor, the funds sit in the processor’s account before reaching the merchant, and the merchant inherits every risk attached to that window: the processor’s security, its uptime, its solvency, and its compliance decisions. The merchant did nothing wrong and still carries the exposure.

Aurpay applies the non-custodial model to that side of the transaction. Customer payments settle directly into the merchant’s own wallet — BTC, Bitcoin Lightning, ETH, and USDT or USDC on Ethereum and Tron — at a flat 0.8% per transaction, with no intermediary account holding the money in between. There is no MetaMask Agent Wallet integration here; these are different layers of the stack. But the design logic is identical, and it is worth reading across: custodial versus non-custodial gateways lays out what each model actually exposes, and our look at how AI agents spend crypto in autonomous commerce covers where the two sides eventually meet.