The surprising thing about MetaMask Agent Wallet is how little of the wallet's decision-making happens onchain.
The assets are onchain. The approvals, swaps, transfers, positions and receipts eventually become onchain state. But the system that decides whether an agent is allowed to create that state — the CLI, session, quote construction, policy lookup, rolling spend counter, simulation, threat scan, two-factor approval and normal signing path — is offchain.
That is not automatically bad. A TEE can protect a key, a hosted policy engine can reject a dangerous request, and a private relay can keep a trade away from a public mempool. “Offchain” describes where a control runs, not whether it works.
It does change the trust model. MetaMask's product page currently says its guardrails are “enforced onchain.” The developer documentation says the Guard Mode allowlists and outflow limits are stored as policy YAML on the server wallet, and its architecture page says the wallet service evaluates those policies before signing. The published packages describe the same remote policy and signing service. I could not find a documented onchain policy contract or policy schema in the current Agent Wallet material.
So the short answer is:
MetaMask Agent Wallet has an offchain control plane and an onchain settlement plane. In a normal EVM action, almost everything before the signature and broadcast is offchain. The final authorization, protocol execution and durable state are onchain.
How much of MetaMask Agent Wallet is onchain?
There is no defensible percentage by bytes, compute time, cost or trust. Counting lifecycle stages is arbitrary: I can split “simulation” into five services and make the offchain number larger without changing the product.
A more useful boundary is this:
| Layer | Where it runs | What it does |
|---|---|---|
| Agent reasoning and skill selection | Offchain, in the agent runtime | Turns a prompt into a proposed action |
mm CLI, session and wallet metadata |
Offchain, on the local machine | Authenticates, selects a wallet and sends structured requests |
| Prices, balances, quotes and routes | Mostly offchain services reading chain data | Builds the transaction the agent may sign |
| Guard or Beast policy evaluation | Offchain, in the wallet-service path | Applies allowlists, risk mode and the rolling outflow policy |
| Simulation and decoding | Offchain execution against chain state | Predicts reverts, approvals and balance changes |
| Blockaid threat scan | Offchain service | Classifies contracts and transaction risk |
| Human exception approval | Offchain, email or MetaMask Mobile | Releases a request paused for 2FA |
| Key use and signature | Offchain, in a TEE or local process | Produces the cryptographic authorization |
| Relay or Smart Transaction submission | Hybrid | An offchain service submits something that will execute onchain |
| Transfer, approval, swap or protocol call | Onchain | Validators execute the authorized state transition |
| Balances, logs and receipt | Onchain | Records the durable result |
The ten stages make the boundary visible; 7/1/2 is not a claim that the product is 70% offchain. Source: current MetaMask architecture, trading-mode and outflow documentation, cross-checked against @metamask/agent-wallet 7.0.0, @metamask/agent-sdk 7.0.0 and @metamask/fox-sdk 2.8.0 on September 23, 2026.
The blockchain does the one thing it is uniquely good at here: it settles an authorized operation into shared state. It does not decide whether an LLM correctly understood the prompt, whether Blockaid disliked the destination, or whether the user's rolling 24-hour limit has been reached.
What happens when the agent makes a trade
Imagine asking an agent to swap USDC for ETH.
First, the model interprets the request and chooses the MetaMask skill. The local mm process loads the session and active wallet from ~/.metamask/. The current architecture documentation names separate local files for the auth session, wallet roster and prediction-market state. The package README adds cached fees, network metadata, command history and an anonymous analytics identifier.
Second, offchain services construct the action. Token metadata, prices, balances, bridge or swap quotes and route selection are API work. Those services may read onchain state, but reading a chain through an RPC endpoint does not make the service itself onchain.
Third, the wallet path checks the proposal. In server-wallet mode, the CLI sends the request to a wallet service. That service may simulate the transaction, scan it, and evaluate policy. If it needs a person, the job enters an AWAITING_MFA state and the CLI gets a polling ID. Approval arrives through MetaMask Mobile or an email link, not a contract call.
Fourth, a signature is produced. This is another common source of confusion: cryptographic does not mean onchain. A transaction is normally signed before it reaches a validator. In MetaMask's server-wallet mode, key operations happen in a trusted execution environment. In bring-your-own-wallet mode, the BIP-39 mnemonic and signing process are local.
Finally, the signed payload is broadcast. It may go through MetaMask's Smart Transactions path or a gasless relay. Once a validator includes it, the target contracts execute and the balances, approvals, events and receipt become onchain evidence.
This architecture is closer to a payment card authorization stack than to a smart-contract account whose policy is fully encoded in bytecode. The chain is the ledger and execution engine. MetaMask's service is the risk and authorization layer in front of it.
Two custody modes, two different security boundaries
MetaMask offers a server wallet and a bring-your-own-wallet path. Calling both “self-custodial” hides an important operational difference.
| Server wallet | Bring your own wallet | |
|---|---|---|
| Where key operations happen | MetaMask says server-side inside a TEE | Locally from a BIP-39 mnemonic |
| What the agent can read | Wallet address and results, not raw key material | The agent process invokes a CLI that can access the local signing path |
| Guard / Beast modes | Available | The docs say trading modes apply to server-wallet only |
| Result model | Async job and polling ID | Immediate result |
| Recovery / exit | Product page says the user can export the secret recovery phrase | User already supplied the mnemonic |
| Main dependency | MetaMask auth, wallet, policy and signing services | Local key security plus MetaMask's transaction pipeline when using this CLI path |
The server-wallet claim is that the key is isolated from the LLM and exportable by the user. That can be a sensible self-custody model: normal signatures happen remotely, while the user retains an exit path. It still means ordinary availability and policy enforcement depend on MetaMask's service.
The BYOK path makes the distinction sharper. MetaMask's docs describe local control and make encryption at rest optional through MM_PASSWORD or mm wallet password set. The @metamask/fox-sdk package says it signs locally, then sends the signed raw transaction to the remote service for policy or MFA evaluation and server-side broadcast.
That protects the MetaMask CLI path. It cannot make the policy an invariant of an ordinary externally owned account. Software with the same mnemonic can sign and broadcast through another RPC endpoint. The same is true after exporting a server wallet's recovery phrase. If a restriction must survive a second signer or a different broadcast path, it needs to exist in a smart account, a permission contract, a multi-party signing rule, or another authorization layer that the key alone cannot bypass.
Guard Mode, Beast Mode and the outflow counter
Guard Mode is the serious default.
It applies network, address and token-recipient allowlists plus a rolling 24-hour outflow limit. A request outside the allowlists or above the configured limit pauses for 2FA. Risky and malicious transactions also trigger approval. Beast Mode removes the allowlists and outflow cap, leaving the threat scan as the main automatic boundary.
The name “outflow limit” sounds simpler than the implementation. The outflow-policy documentation says MetaMask simulates the value leaving the account, estimates it in dollars and adds it to the rolling total after a successfully submitted transaction.
Three limitations matter:
- Swapping 10 USDC into ETH and later swapping that ETH into DAI counts as $20 of outflow, not $10. The counter measures movements, not net capital leaving the wallet.
- Permit2 and other signatures are not included. A signed permission can create later spending authority without moving tokens during the signature step.
- Tracking can be imprecise when a transaction is not submitted through MetaMask's backend.
Those are reasonable limitations for a hosted safety counter. They are also direct evidence that the counter is not an onchain balance rule. A contract-enforced daily limit would see the calls that reach it regardless of which backend broadcast them, and it would need an explicit model for delegated signatures.
What EIP-7702 and ERC-7821 do — and what they do not
MetaMask uses two newer execution primitives in supported paths.
EIP-7702 lets an externally owned account authorize delegated code. MetaMask documents using it when a wallet lacks the native token for gas: a relay submits an ERC-20 transfer or swap and takes its fee from the token being moved.
ERC-7821 defines a minimal batch-execution interface. MetaMask can combine an ERC-20 approval and trade into one atomic execute() call on eligible chains and accounts, falling back to sequential transactions when batching is unavailable.
Both are onchain execution mechanisms. Neither current Agent Wallet page says the Guard Mode YAML is compiled into that delegated code, that the rolling outflow total is stored in a contract, or that a policy contract rejects an out-of-policy call. They make settlement more capable. They do not, by themselves, move the documented policy engine onchain.
The relay is hybrid for the same reason. Its queue, routing and submission logic are offchain. The transaction it eventually sends is onchain. Smart Transactions can improve inclusion and protect a trade from public-mempool MEV, but a private submission service is still a service.
The documentation currently contradicts itself
I found three places where the current public story does not line up cleanly.
The most important is policy location. The product page says guardrails are enforced onchain. The reference docs say policy YAML is stored on the server wallet and evaluated by the wallet service before signing. The package architecture says the backend owns policies, MFA, signing and broadcast. Until MetaMask publishes the contract, address, storage layout or delegation logic that carries those rules, the developer documentation is the more specific description.
Second, the same product page presents transaction simulation as part of the mandatory pipeline, while its FAQ describes dry-run simulation as “soon.” The architecture reference says the CLI simulates before execution, but the async lifecycle softens that to the service “may simulate.” I would treat simulation coverage as chain- and action-dependent until those pages converge.
Third, the product FAQ says one CLI supports Solana. The current supported-chain reference is organized around EVM networks, and the shipped SDK contains Solana code alongside the EVM path. That may be a documentation lag rather than a product gap, but it is exactly the kind of mismatch that should make a production integration test its intended action instead of relying on a logo grid.
None of these contradictions proves the controls fail. They do mean the strongest marketing sentence — onchain enforcement — is not the sentence I would put in a threat model today.
Should you use MetaMask Agent Wallet?
For an agent trading a small, isolated EVM portfolio, I would start with MetaMask in Guard Mode. Its transaction pipeline can combine simulation, threat scanning, allowlists, a rolling outflow limit and a human exception path without requiring approval for every normal action. I would treat MetaMask's service as part of the trusted computing base, because that is where the current documentation places policy evaluation and server-wallet signing.
The custody choice depends on which failure you are trying to contain:
- Use the server wallet when the priority is keeping raw key material away from the agent process and using Guard Mode, 2FA and TEE-backed signing.
- Use bring your own wallet when local custody is the priority. Set
MM_PASSWORD, restrict filesystem access and remember that software with the same mnemonic can bypass the hosted policy path by signing and broadcasting elsewhere.
Before letting the wallet handle real funds:
- Create a separate wallet for the agent rather than sharing a human wallet.
- Fund it with only what the current task needs.
- Start in Guard Mode and keep network, address and token-recipient allowlists narrow.
- Set a low rolling outflow limit and verify that the 2FA route actually reaches you.
- Test the exact action on the exact chain with a small amount; do not assume simulation and batching coverage are identical everywhere.
- Review any Permit2 or typed-data signature separately because the documented outflow counter does not include it.
- Confirm which path will broadcast the transaction. A transaction sent outside MetaMask's backend may not update the hosted outflow total precisely.
The unresolved design question is not whether the final trade is onchain. It is whether the safety rule must remain true if MetaMask's service is unavailable, compromised or bypassed. If the answer is yes, the rule needs an authorization mechanism the private key alone cannot escape, such as smart-account logic, a permission contract or multi-party signing. MetaMask's offchain simulation and threat scanning can then remain useful defense in depth.
An agent wallet is not safe because it is onchain. It is safe when every path to a valid signature has a boundary you understand.