Permission, Not Possession: Setting Agent Wallet Defaults Before They Harden

Devcon 8 · 3 Nov 2026 · 7:23

MetaMask developer-relations lead Francesco Andreoli explores how agents can act through a wallet without receiving unrestricted control. Drawing on a personal trading-agent experiment, he examines scoped delegation, session keys, spending caps, time limits, allowlists, and revocation as alternatives to blanket approvals or custody.

Speakers

Topics

From Devcon 8, hosted by Ethereum Foundation.

Transcript

[music] Okay, perfect. Okay, let's do countdown five minutes. This is a really lighting talk. So, what's up everyone? Um, yeah, as you said, basically like I've been testing different things. Um, just a quick presentation for the people that doesn't know me. Let me scroll down then. [snorts] Um, yeah, I'm Frances Condroll, lead developer relation at MetaMask. How many of you guys um use an agent wallet for anything? Payment, export to payment, uh trading. Uh okay. Okay, sounds good. Basically, like I Yeah, I did kind of like different testing with all all the agents out there, especially after I think was the first uh was like last last year in Denver when uh you were prompt

engineered and um uh kind of like the loss of funds uh directly from the wallet. Um and [snorts] kind of like I was fascinating about like agent Garels from the start. So I've been testing different things and as many of you guys know we launched something called the meta mask agent wallet and uh I just wanted to talk this specific like talk and I have four minutes left on agent guards and kind of like best practices and kind of like lesson learned. Um TLDDR is u um some of the previous talk were about all how AI is enabling like builder needs. Um I don't know if you've been in in some of those but I define different like pyramids on what um uh uh builders, developers, dubs founders uh are uh currently kind of like um uh needing in order to build like a

sustainable product. Um and this is mostly for humans, right? I also build this kind of like devil um operation grid is is TLDDR of this is going from like humanled to an agent native setup. And obviously like agent native is something that we care about not just for trading, not just for payments, not just for purchasing things with our payment processor. Um but uh one things that happen is obviously like builders are are changing. Yes, it's developer relation but the end is almost like agent relations too. Um and uh uh one question that we ask ourself is uh uh the journey is obviously like difference. you get um some sentiment analysis, some social out, you get some think about token discovery, depend the

use case that you're into, but you get a signal, right? And obviously you throw this through your orchestrator um and the the agent or the chief of staff or orchestrator whatever you guys are using is deciding what to do and then obviously like the execution area is on the on the wallet side uh and uh sign and send and then is moving and executing and the question obviously is like a liability question it's not even that technical I think like technicality are important but also like the the the big discussion that happened in the the previous kind of like um debates where where the liability is standing from is the users is the orchestrator uh who is signing who is who is this um standard

uh that create uh specific things or is kind of like the payment processor that should actually stop on doing that. So who the key um and uh one things kind of like uh uh that I mean is not rocket science is obviously you cannot make a language completely unfullable. I think there are different like uh parts of the game that you see um that uh that there were problems, right? Prompt engineering is one of the first one, but a couple of like days ago also we got this by um by Cornell and and Yale that nine out of 10 probably raised their own cup without actually like permission uh reading fully ownership on uh the the user inbox uh obviously because everything is browsing mode. Um and a couple of others and I see I have literally like 1 minute

30. Um but one things I want to kind of like say is that uh uh the limits that you need to set up need to be on the wallet not on the prompt. So whenever you ask the agent to do something you have like obviously a scope and then you have an expiry and then there is a revoke um setup and uh um there are two main guards that I see working and some example I bringing also on the architecture of the the agent wallet wallet but obviously like you have different modes so on the policy side uh one things that I'm recommending obviously on the guard mode uh to push this as a default uh you have a network recipient allow lists. Um we have also like a 24 hours outflow uh limit and uh

uh when uh you have tightened um setups you also like need 2FA. So the important like outflow clap is is your blast radio. So uh interesting part is that we allowing literally like the execution side that is the same of mobile and extension meaning you have the same uh security uh uh primitives right so both allow list and limits are checked before every transaction of course you will lose some uh latency on that but we're still speaking about millisecond and I think like the user uh is is more than happy the second guards is on the runtime side so um you want the agent uh never touching like your your key so there specific on a TE and then every simulation this is probably the most

interesting one. So you are simulating every uh transaction. So you have a scan uh protection and me protection on the uh pre-transaction side. And uh the cool thing is that if this is only an execution layer uh it's some sort of like an orchestrator on the wallet side this is also like fully working with any uh model out there. And uh important thing is that you know I've rewrote here like if the if the model is fooled the wallet still say uh no. Um and I think we're almost on time. one uh one setup default. This is the last part I want to mention is uh own wallet. Never try your main one. Even if you're testing this test happen like for for six months uh in a row cap what you're what you're willing to lose. Allow list build

delegation. I think delegation are super important. Seven is to also like compliant. Um have permission that also expired not just in trading but in uh different uh part and also like having a human approval for threshold. So I'm finishing this with this up. the goal isn't a perfect agent, it's a compromised agent that can hurt you, right? And I think this is the right direction when we want to go in a much more heavier use case for agent. So, thank you so much everyone. >> Thank you so much, Franchesco. We have time for a mini question if someone has a super quick one.

>> That was a true lightning talk. Yeah. Hey, great talk. >> Lightning question. >> Yeah. Yeah. Regarding the guardrails, uh how deep can we go exactly? So, we can mark contracts allow list. Can we also list functions the agent can call? Can it be like granular like this contract only this amount? How deep can you go? >> So you can uh is you can basically like build a delegations allow list also. There are two modes, right? You have like the the easier mode and the second is like deeper on the security side are both similar. You still have like double check malicious contract everything that you can do on extension and mobile um are are also like suited for the agent wallet side. Um what this is one part.

The second part is um uh you can also build your own customized security guarantee as a plug-in and have it directly being supported on your agent wallet. The cool thing is that there is bunch. [music]