Guardrails for the Robot Hand: MetaMask's Agent Wallet Goes Public

MetaMask opened its Agent Wallet to the public this month: a wallet surface built specifically for AI agents to transact through, governed by user-set policy — spending caps, permitted networks, permitted protocols — rather than by the agent's judgment.

The design concedes something important, and refreshingly honest: agents cannot be trusted with a seed phrase. Anyone who has watched a language model confidently do the wrong thing understands why. Instead of pretending alignment solves custody, the Agent Wallet treats the agent like a teenager with a debit card — real spending power, hard external limits, and a parent who can see the statement.

Why policy beats trust

The alternative designs are all worse. Give an agent raw keys and a prompt-injection anywhere in its context becomes a drained account. Make every transaction require human approval and you've built a notification generator, not an agent. Policy enforced outside the model — this much per day, these networks, these contracts — is the only architecture that survives both failure modes. It's the same conclusion the traditional card industry reached decades ago with merchant categories and per-transaction limits.

How the limits are actually enforced

The policy language is not marketing copy sitting on top of an ordinary wallet. It resolves into two Ethereum standards, and the mechanics are worth understanding because they determine what the guardrails can and cannot stop.

MetaMask's own documentation describes Advanced Permissions as a way for an application to "request fine-grained permissions from a MetaMask user to execute transactions on their behalf" — the ERC-7715 side of the design. The illustrative example in the docs is deliberately small: spending ten USDC daily for a month. Once granted, the application can act "without an active wallet connection," which is the entire point when the thing acting is a piece of software running unattended at three in the morning.

The structural safeguard is the account the agent actually holds. In MetaMask's model the agent operates a session account, established solely to request and redeem those permissions, and — in the documentation's own words — it "doesn't contain tokens." It can be a smart account or an ordinary externally owned account, and it is separate from the wallet holding the user's money. Redemption then happens through ERC-7710, the companion standard that lets a smart account delegate a capability to another account.

Read that architecture carefully and the security claim becomes precise rather than aspirational. A compromised agent does not hold funds; it holds a bounded, revocable right to move someone else's funds within limits enforced by contract. The worst case is not an emptied wallet. The worst case is the full daily allowance, every day, until somebody notices — which is a meaningfully better failure mode, and still a real loss.

Related The $500,000 isn't in the paper

The standard underneath is still a draft

One caveat that the launch coverage largely skipped. ERC-7715 remained in draft status as of April 2026, per Eco's explainer, despite production implementations across MetaMask's toolkit, Coinbase Smart Wallet, Rhinestone and Biconomy. Naming conventions are still moving with it: the method MetaMask's current docs describe is wallet_requestExecutionPermissions, where earlier write-ups of the standard refer to wallet_grantPermissions.

That is not a scandal — this is how standards mature, and shipping ahead of Final status is normal. It is worth stating plainly anyway, because "your agent's spending limits are enforced by an open standard" and "your agent's spending limits are enforced by a draft several vendors have each implemented" are different sentences, and users are being sold the first one.

Turning it off, and the clock that does it for you

A permission you cannot withdraw is not a permission, it is a transfer. So it matters that revocation exists — and that it lives in the standard rather than in any one vendor's product. ERC-7715 defines a companion set of methods alongside the request call: wallet_revokeExecutionPermission to withdraw a grant, wallet_getGrantedExecutionPermissions to enumerate what is currently outstanding, and wallet_getSupportedExecutionPermissions to ask a wallet what it will honour in the first place.

The second of those is the one users will need and the one nobody demos. An agent economy means standing grants accumulating quietly across months and applications — the kind of thing that stays invisible until an audit or an incident. A method that lists every live permission is the difference between managing that and merely hoping about it.

Time limits are handled separately, as an explicit rule attached to a grant. The spec models expiry as a rule carrying a Unix timestamp, which means a permission is bounded only if somebody sets that bound. Nothing in the design expires by default. The spec's own guidance is that applications should request only the permissions they need, "with a reasonable expiration time" — advice that is sound, non-binding, and addressed to precisely the party with the least incentive to follow it.

Worth noting for anyone reading the docs rather than the standard: MetaMask's conceptual page on Advanced Permissions walks through the three-stage lifecycle — set up a session account, request permissions, redeem them — without addressing revocation or expiry at all. The mechanisms are in the ERC. The introduction most users will actually read does not mention that the off switch exists.

Where the trust actually went

The strongest thing in ERC-7715 is not a feature; it is a sentence in the security considerations that declines to oversell the whole approach. Wallets must enforce permissions correctly, the spec says, and users "must trust that their wallet software is implemented correctly."

That is the honest accounting. The guardrail model does not remove trust from the system — it relocates it. You stop trusting the agent's judgment and start trusting the wallet's enforcement code, which is a much better trade, because enforcement code is auditable and deterministic in a way that a language model's next token is not. But it is a trade, not an elimination, and a bug in that enforcement layer fails for every agent using it at once.

The spec is equally direct about the other exposure, and it is not the agent at all. Malicious applications can pose as legitimate ones and trick users into granting broad permissions; wallets, the document says, must display permissions clearly and warn against dangerous ones. Which locates the real attack surface at the moment of granting — a consent screen, read quickly, by someone who wants the agent to start working. The industry spent a decade learning that lesson with token approvals and blind signing. Nothing about attaching an AI to the other end makes that screen easier to read.

ERC-7715 was created on May 24, 2024, and remains in Draft. Two years and change of production deployment on a standard that has not been finalised is not unusual, and it is not an accusation. It is simply the fact underneath the reassurance.

The timing is not subtle

The launch lands in the same month Binance shipped Agent OS, its own bridge between consumer AI tools and exchange rails, and the same month security leaders warned that agent-driven attacks will make today's losses look small. Agent money is arriving on both sides of the fight simultaneously — spending infrastructure and attack surface, shipping the same quarter.