Crypto wallets are beginning to embrace artificial intelligence (AI) in ways that extend far beyond simple assistants or chat interfaces. A new generation of AI agents is being built to execute trades, manage positions, and interact with smart contracts on behalf of users.
That promise, however, invites difficult questions. If an AI agent can move funds, place trades, or interact with decentralized applications autonomously, how much authority should it have? What safeguards can prevent a mistake, a malicious prompt, or an unexpected exploit from turning automation into a liability?
MetaMask believes the answer lies in limiting what an agent can do rather than asking users to trust what it might do. Through Agent Wallet, the company is building a framework for programmable permissions, policy-based controls, transaction simulation, and threat detection, designed to keep automation within boundaries defined by the user.
To understand the thinking behind that approach, Crypto India Magazine (CIM) spoke with Francesco Andreoli, Head of Developer Relations at Consensys and MetaMask.
In Conversation With Francesco Andreoli
CIM: You’ve been at Consensys and MetaMask since 2021, working across MetaMask, Infura, and Linea. Looking back, what’s changed the most about what developers expect from MetaMask today compared with when you first joined?
Andreoli: In 2021, the question was “how do I connect a wallet and get an RPC endpoint?” MetaMask was a button on a website. Developers wanted docs, an SDK, and reliable infrastructure underneath.
Today the question is “how do I let software act on my behalf without losing control of it?” That’s a completely different ask. Developers now expect the wallet to carry guarantees, not just connectivity; things like policy enforcement, transaction simulation, and a real error model they can program against. And they expect all of it to be machine-readable. A GUI is a terrible API. That shift, from interface to infrastructure, is the biggest change I’ve seen.
CIM: You built Snaps, worked on the MetaMask Card, and now Agent Wallet, which, unlike the browser extension everyone knows, runs through a command-line interface. How would you describe what it does and what makes it different for someone hearing about it for the first time?
Andreoli: It’s MetaMask without the browser window. You install the CLI (https://metamask.io/agent-wallet), plus a set of skills for your AI framework, and from that point your agent can transfer, swap, bridge, earn yield, trade perps, and take positions on prediction markets across 22 EVM chains. You talk to your agent in plain language, and it translates that into wallet commands.
What’s different is who the user is. The extension was built for a human reading a confirmation screen. Agent Wallet is built for software that executes without a human in the loop, so the safety has to live in the wallet itself, not in the popup.
CIM: Agent Wallet supports swaps, perpetuals, prediction markets, and liquidity provisioning across EVM chains as well as Hyperliquid. Was supporting Hyperliquid an intentional early strategic decision? And do you expect to add more non-EVM chains over time?
Andreoli: Completely intentional. Perps are the most agent-native product in crypto; they run 24/7, they’re latency-sensitive, and the decision loop is exactly the kind of thing you’d want to delegate. Hyperliquid is where those traders are, so it was never really a debate. We also support HIP-3 builder-deployed DEXs, so positions and orders work across those too.
And yes, we’ll keep going where the users are. We’ve just added Robinhood Chain and Monad, among others. The principle isn’t “EVM-only,” it’s that we don’t ship a chain until the security story on it is honest.
CIM: Every transaction goes through simulation, Blockaid’s threat detection, and MEV protection. In practice, where do you actually see things get flagged the most?
Andreoli: The most common flags aren’t the ones people worry about. Outright malicious contracts are actually the smallest bucket; Blockaid catches those, and they get bounced without much drama.
The bulk of what we surface is economic, not adversarial: fees that eat more than 25% of the trade, high price impact on thin liquidity, dust-sized amounts that don’t make sense to execute. Then there are approvals, over-broad allowances to contracts that were deployed last week. And a large share is simply the agent hitting the user’s own guardrail, such as a recipient that isn’t on the allowlist, or a trade that would breach the rolling 24-hour outflow cap.
That last category isn’t a failure. That’s the system working.
CIM: MetaMask covers eligible transactions up to $10,000 through Transaction Protection. What decides whether a transaction qualifies and if something still slips through after all those checks, what can a user actually do?
Andreoli: It comes down to two things: which chain you’re on, and whether the transaction actually went through our security pipeline. The $10,000 coverage, called Transaction Protection, is EVM-only, and it applies on 13 of our 22 chains where our Transaction Shield security layer is live: Ethereum, Optimism, BNB Smart Chain, Polygon, Monad, HyperEVM, Sei, MegaETH, Robinhood Chain, Base, Arbitrum, Avalanche, and Linea. The transaction also has to go through the security pipeline rather than around it. Coverage is up to $10,000 a month, subject to the terms.
We’re specific about which chains are covered because precision is part of the security model, not a caveat to it. On covered chains, transactions run through the full pipeline before they land, and users always have complete history in the CLI plus a clear claims path in the docs.
CIM: Before granting an agent any permissions, users set spending limits, allowlists, and two-factor authentication. What’s the most common mistake you see people make at that setup stage?
Andreoli: Almost all of it comes down to one thing: people size their limits around what they want to trade instead of what they’re willing to lose. They’ll set a 24-hour outflow cap equal to their whole balance, which technically satisfies the setup step and protects nothing.
The second one is jumping straight to Beast Mode because Guard Mode felt like friction during testing. Guard Mode exists for a reason: full guardrails plus the outflow limit. Beast Mode is threat-scanning only. It’s for people who’ve already learned what their agent does when nobody’s watching.
And the ‘boring’ one: not running “mm doctor” before the first trade. It tells you in one line whether you’re actually authenticated and initialized.
CIM: There’s a real problem with “approval fatigue” when people just click “approve” without reading anything. How do you design against that without turning the whole experience into a chore?
Andreoli: The key is to move the decision rather than repeat it. Approving every transaction doesn’t scale and never really works. Attention is a finite resource, and clicking is free. So instead, the user makes one considered decision at the policy layer: spend limits, allowlisted recipients, risk mode. After that, the agent operates inside it and doesn’t ask.
2FA only fires when something’s actually off: a policy violation, or a transaction the scanner flagged. That’s by design. If you’re getting prompted constantly, the problem usually isn’t the prompts, it’s that your policy is set wrong. And when we do interrupt you, we decode the transaction into plain language so you can actually tell what you’re approving.
CIM: Beyond key security, there’s also prompt injection, an agent getting manipulated into doing something it shouldn’t. When that happens, what actually stops real damage from occurring?
Andreoli: I’d start by accepting that you cannot make a language model un-foolable, and I’d be wary of anyone who claims they can. So the goal isn’t a perfect agent. It’s a compromised agent that can’t hurt you.
The policy is enforced server-side, outside the agent’s context window. The agent can’t raise its own limits or switch itself from Guard Mode to Beast Mode; that path is protected by 2FA. The allowlist means funds have nowhere to go even if the agent is convinced they should. Blockaid scans the transaction regardless of what the agent believes about it. And the outflow cap is your blast radius: the worst case is capped at a number you set yourself, up front.
CIM: Many users still hesitate to give an AI agent spending permissions. What’s the biggest misconception they have?
Andreoli: That it’s binary, that you either hold your keys or you hand them to an AI. That’s not how it works. What you’re granting is a scoped, revocable, rate-limited permission to a specific set of actions. It’s closer to a company card with a spending limit than to giving someone your bank login.
The second misconception is that automation and self-custody are opposites. They’re not. Keys either sit in a TEE with server-side signing, or you bring your own mnemonic, and it never leaves your machine. It’s your choice at setup. Either way, you can export and walk away. The agent is an operator, never the owner.
CIM: As Agent Wallet moves beyond early access, what should people be watching for? Any integrations, security upgrades, or new features you’re genuinely excited about?
Andreoli: A few things I’m genuinely excited about. The first is gasless execution. With EIP-7702, a swap can go through even when you’re short on native gas, and with ERC-7821, the approve and the trade settle atomically in one transaction. That kills two of the most common ways an unattended agent gets stuck at 3 am.
Second, reliability. We’ve put a lot of work into transaction success rates, with extensive testing, performance optimization, and a steady stream of fixes and improvements, so that when you hand your agent a trade, it can one-shot it. Unglamorous work, but it’s the difference between an agent that gets the job done and one that stalls out.
Third, and this is the one I care most about, the policy engine is exposed through the SDK. Other teams can build on those guarantees instead of reinventing them.
Editorial Note: This article is based on an interaction between Polina and Francesco Andreoli, Head of Developer Relations at Consensys and MetaMask. The excerpt has been published as originally shared, without any modifications to the questions or answers. Only the introduction has been edited to provide additional context and enhance readability.