Nobody Verifies What Your Agent Reads

Devcon 8 · 3 Nov 2026 · 6:46

Envio co-founder Denham Preen examines an overlooked trust boundary in AI agents: the chain data they read. He explains how reorgs, unfinalized state, and transformed metrics can diverge from consensus, then proposes attested reads and provenance that agent interfaces such as MCP could carry.

Speakers

Topics

From Devcon 8, hosted by Ethereum Foundation.

Transcript

[music] Hey everyone. Um, hi guys. My name is Denim, pronounced like the jeans. Uh, that was a fantastic talk by Franchesco and I think mine's going to kind of follow into that too. My topic is nobody verifies what your agent reads. Um, and who here does not use AI? Raise your hand. We got one non AI user. Cool. And who here lets their agent I mean, in fact, Franchesco, this was an exact question. Who lets an agent manage their their crypto bags?

We maybe dabble, but at at this current point, we're a little bit too scared to fully hand over our access or private keys to an agent. And this is a quote that's kind of great from the Coinbase uh CEO. Banking on your phone used to sound crazy and now everybody does it. Using AI agents to manage your financial life or money will follow a similar path. And that's pretty uh much something that we can all agree is going to happen at least in the future. So we we do an incredible job on verifying chain data consensus we verifying the chain we even verify uh the agents now agents identity and I

know there's another lightning talk uh happening 2 minutes after that which I think will be great but we don't actually verify what that agent reads and I want to go into that in a little bit more detail because if you are I want to make this this important distinction between raw data and computed data. All right, raw data we can actually prove it. There's some really fantastic progressions in light clients like Helios uh and we can essentially attest that the data we get from maybe an RPC call is uh true. We can trust it. However, with something like computed values, it gets a little bit more complicated. Now just to explain what a computed value is let's

take a as an example. So a uh to calculate the TVL that would be a computed value we'll have a series of events deposits from withdrawal and we'll sum them up to get the current TVL that's quite a rudimentary example and this summing and whatever kind of computation you're doing is run inside of an indexer. Now it's a much different kettle of fish to to uh essentially uh an indexer is run over a large period of time and so it can't quite be replicated the same as a light client and a vanilla RPC call and arguably computed values are a lot more uh use meaningful or a lot more usable for uh

certain agents. If an indexer could if we could just store all that data on a chain maybe is the thought you have so we can just get it over RPC calls then we'd essentially be building the indexer into the chain and that becomes pretty heavy and inefficient and would be quite costly. All right quick touch on there is some cool stuff happening on the raw side. Uh look at Helios a project by A16Z a light a light client that's really light and you can verify IPC data as well as uh root mesh and DIPC kind of distributed uh load load balanced RPC and then uh just a confession we don't do it we don't have this uh attestable computed data at NVIO um but I work on a

an indexer myself and I also just want to mention that open source does not equal a tested output So just because you can look at the code doesn't mean you can prove that the data point you received is actually running that code. Uh there's another great talk happening pretty much in parallel uh on this right now which uh just on that topic. So with a minute and 20 seconds left, uh just want to really quickly cover the architecture of what we proposed and we we came to this architecture working with Ethereum Foundation as well as uh Nosis or at least NosisVPN uh Sebastian Burgle and uh it's twofold.

So essentially it's running a Helios light client within a trusted execution environment as well as a indexer in that TE. Now this doesn't by itself attest the output. It allows us to attest that the code that is running is the code we know to be on the actual uh indexer. So we can attest that the code running to get to that output is true. And this is kind of the model we we came to. And um just in in wrapping up uh another uh fun fact specifically from our platform, 96% of deployments in the last 3 months were made by Claude. Um it just

really speaks to this and that's Claude that doesn't necessarily include codeex. So that other 4% could be from those. But really uh this number has skyrocketed over the last few months and it's just showcasing that more and more we see uh a lot of kind of more critical infrastructure pieces getting passed to agents and it's not going to be long before agents are fully using our uh or managing our bags. Uh thanks very much. That's my time if uh open to some questions but if anyone wants to chat and is building uh DAPs for agents first I'd love to chat after the call.

>> Thank you so much Denam. Super important work and very interesting talk. A question all right what do you find most difficult in like this current work? Yeah, I think uh it's mostly the integration side of things at the moment to to you know tees are a little bit more limited in it's not kind of a a AWS EC2 instance. Uh so it can be a little bit more tricky to fit the pieces together if they're not initially designed for it. But it is something and I think the other thing is a lot of people want want this but the the future need uh doesn't always prioritize it.

So, we've got some great users that want this, but it's kind of like, yeah, we we really want this, but it's something we, you know, we're not willing to pay towards cuz once it's there, like, great. But, uh, it's just a block on on getting things started. [music]