Ethereum New Spend Mandate Proposal Puts Guardrails on AI Agent Wallets

AI agents are starting to move real money onchain. They rebalance portfolios, pay invoices, manage treasury sub-accounts, and interact with DeFi protocols — often without a human signing each transaction. That autonomy is powerful, but it comes with a serious question: what stops an agent from spending more than it should?

A new proposal on the Ethereum Magicians forum, posted June 18, offers a direct answer. The Asset-Enforced Spend Mandate introduces token-level spending controls that travel with the asset itself — not with the wallet, session key, or application that happens to be moving it. If an agent's key is compromised or a session goes sideways, the token can still reject transfers that exceed the approved mandate.

The Problem With Current Agent Permissions

Today, most approaches to AI agent spending rely on controls at the wallet or account level. Session keys, delegated signers, and smart account modules all define what an agent can do from the account's perspective. These work well for many scenarios, but they share a blind spot: the token being transferred has no opinion about whether the transfer should happen.

That gap matters when approvals are too broad, when agents operate across multiple protocols, or when a key is leaked. If the only guardrail lives in the wallet and the wallet's security fails, there is nothing left to catch an unauthorized transfer. The agent can drain the balance because the token itself has no mechanism to object.

Supply chain losses in crypto overwhelmingly follow this pattern. Users authorize more than they understand, and when something goes wrong, the asset moves freely because no constraint exists at the token layer.

How the Asset-Enforced Spend Mandate Works

The proposal introduces a deliberately small interface called ISpendGate. It has two functions: isGated, which checks whether a given address has any mandate record on file, and checkTransfer, which returns a verdict on whether a specific transfer is allowed — along with a machine-readable reason if it is not.

A compliant ERC-20 token exposes a spendGate function and consults the gate during its transfer path. If isGated returns true for the sender, the token calls checkTransfer. If the reason is anything other than OK, the transfer reverts with a TransferBlocked error that includes the specific reason code.

Those reason codes form a standardized vocabulary: NO_MANDATE means the agent has no spending authorization on file. REVOKED means the principal cut the agent off. EXPIRED means the mandate's time window has passed. TOKEN_NOT_ALLOWED means the agent is trying to move an asset outside its approved list. OVER_TX_CAP means the transfer exceeds the per-transaction spending limit.

This is a significant improvement over existing pre-transfer checks like ERC-7943, which return a bare boolean. When a transfer fails with a boolean, the integrator has to guess why. With a reason vocabulary, the system can route each failure to the correct response — prompting the user to renew an expired mandate, for example, rather than showing a generic error.

Where This Fits in the Ethereum Stack

The proposal positions itself clearly within the existing standards landscape. ERC-20 defines what you hold. ERC-3643 and ERC-7943 define who may hold it. ERC-4337 and ERC-7702 define who may sign for it. ERC-8004 identifies which agent is which. The Asset-Enforced Spend Mandate fills the remaining slot: what a holder may spend, enforced at the asset layer.

Its closest neighbor is ERC-8226, the Regulated Agent Mandate, which bundles identity and compliance into the same delegation model. ERC-8226 already covers how mandates are granted and revoked through EIP-712 and EIP-1271 signed grants. The Asset-Enforced Spend Mandate is the minimal, identity-agnostic version — it does not care who the agent is, only whether the transfer fits within the approved parameters.

The two compose cleanly. An ERC-8226 registry could enforce through a spend gate like this one and gain a machine-readable reason vocabulary instead of a bare boolean. The identity layer handles compliance. The spend gate handles enforcement semantics.

The Delegation Layer Debate

Not everyone agrees that asset-level enforcement is the right primitive for general agent spending. A response on the Ethereum Magicians thread pointed to ERC-7710 and MetaMask's Delegation Framework as an alternative approach. In that model, the user grants a bounded delegation from their smart account to the agent. The Delegation Manager validates permissions and caveats before executing ordinary calldata — meaning the token contract does not need to know anything about the mandate.

This distinction matters practically. Asset-level gates require every token to opt in by implementing the gated-asset surface and calling the spend gate from its transfer path. That works for new regulated assets or issuer-controlled tokens, but it does not help the existing universe of ERC-20s unless each one upgrades. Account-level delegation works with any token because the enforcement happens before the transfer is submitted, not during it.

The emerging consensus seems to be that both layers have their place. Asset-level gates are essential for regulated assets, tokenized real-world assets, and issuer-controlled tokens where compliance enforcement must live in the transfer path. Account-level delegation is the better default for general-purpose agent spending because it works with today's assets out of the box.

What This Means for Builders

If you are building AI agents that interact with onchain assets, this proposal signals where the infrastructure is heading. The days of broad, unconstrained token approvals are numbered. Whether enforcement lands at the asset layer, the account layer, or both, the expectation is that agent spending will be scoped, time-bounded, capped, and revocable.

For developers working with smart wallets and account abstraction, the practical implication is clear: build your agent integrations with granular permission models from the start. Design for per-transaction caps, expiration windows, allowed token lists, and instant revocation. These are not nice-to-haves — they are becoming table stakes for any production agent deployment.

If you are building agent-powered applications on Ethereum or any EVM chain, thirdweb offers developer tools and infrastructure plans that scale with your project — check out thirdweb.com/pricing for options that fit from prototype to production.

Still Early, But the Direction Is Clear

The Asset-Enforced Spend Mandate is an early discussion draft, not a finalized ERC. Details will change. But the underlying problem it addresses — autonomous agents spending tokens without adequate guardrails — is real and growing. As AI agents become standard participants in onchain economies, the infrastructure to constrain them will need to be just as robust as the infrastructure that enables them.

The fact that this proposal already has active engagement from the ERC-8226 authors and the MetaMask delegation team suggests the conversation is converging. Builders who start designing for bounded, revocable agent permissions today will be well-positioned when these standards mature.