When your AI agent uses your wallet, what are you trusting?

Transcript

[music] [music] >> Okay, awesome. >> It's life. >> So, yeah. I will follow up on the presentation we just had. So, before we talked about agents and humans that gets to agents, but the world is much larger and we also will soon see autonomous agents that actually don't have anyone that they should report to. And the question asked was how we can actually check that the agents that run now actually the agents that are expected to run. So, again, it's a background. I think we just heard a perfect explanation of why the problem itself is very important. But, yeah. There are tons of activity, agentic activity, cross-agentic activity. And right now

it's very hard to know if this is real real agents doing real work or it's just some arbitrary computer sending or pretending to be an agent. So, what this is is let's say you have your own personal agent and you want to do ask it to do some work for you. But, it's pretty simple setup, just three boxes. Uh but, it's much harder to actually figure out if the action going from the agent to the account is actually agentic account um sorry, agentic action and not some adversary impersonating the agent. So, if we look into what the agent is, uh it's effectively a server that runs a program called agent harness. And this agent harness makes a series of calls to motor provider tools.

Well, it kind of looks out in the world, makes decisions, and wants to act on the decisions. And it needs permissions or resources to act on. So, let's say we have an Ethereum account it wants to act. But, how do we connect the two? So, how do we prevent an attacker from talking from as if it was an agent and overtaking the account? So, how people Yeah, how do you know that the account uh is being acted on by the agent? So, the simple solution as we just talked was you can put a key. So, you can put a key on the machine and um as long as the agent has access to the key, it's all good.

Well, people tried and that really backfired cuz agents are notoriously not secure. They can go out in the wild, look on these strange websites, download a virus, get compromised, or even just the tooling that runs agents can get compromised. So, the key is leaked and then the attacker can just overtake your account cuz it now has the private key for the account. Well, people thought of that. So, the next solution was let's put the key somewhere else. Let's put the key in a box and protect the box. But then the agent will make a call to the box and the box will sign the transaction and move the transaction to the account.

That's seems like a solution. But again, the box Sorry, no. The agent, the machine. The agent can get compromised and the moment the agent get compromised well, it can make arbitrary commands to the box. The box signs everything cuz the box doesn't know what should happen, what not should not happen. And the your account is drained again. Well, not good. Um limits. So, you can set the box and say, well, the box is only going to sign a particular transactions within the limit. Nice, but again, limits means that it still can drain some part of it and it can drain some part of the time. So, you just reduce your attack surface.

Seems not the best. Well, policies. So, what if we try to limit what the agent can do? So, prevent the agent from going to harmful websites or I don't know, just make it hard like hardened. Well, again, we can try it, but research shows that agents will try to abuse the policies. They will try to escape the policies or again, the tooling that agents runs on gets compromised and the whole system falls apart. So, yeah, nothing seems perfect and the question is why do we even need a key?

So, actually an agent is just a program and the good part about programs is if they're more or less deterministic, we can just prove that we run the correct program and we don't need a key, actually. So, yeah, that's actually what my research looks into. We try to define an agent as a program, create a proof that the agent was run correctly, and then we check the proof inside of the contract. So, how it works is we first define an identity for the agent. It's called agent identity document, basically like a passport, and we define what the agent is expected to do, like the tools it can access, the memory structure, the model it can call, and from there we for every call it makes, for every comment it runs, it generates a proof

that it followed the expected transcript. And it bundles this into a proof, and then the proof can get on chain, get verified, and again, using an identity lookup, you can be sure that the transaction came from the agent that you would expect, and um yeah, um but we sort of solve the problem. Um with a theorem, it's easy and nice. Like there are some issues that we still need to think of. You still trust the model provider, cuz again, the model provider can be overtaken, and the model provider uh can inject some malicious commands, and we have no check that the model provider really outputted the inference results.

I think Anthropic published 2 days ago a very nice blog post on how they scaled the proving, but like have a look, but again, it's it's still a big problem. Tools get can can get compromised, and agent can be tricked by different tools. Um you still need to trust the auditors, you need to trust that the agent identity is secure, cuz again, identity can have compromises in itself. And of course, you the agent needs to also authenticate who gave it a task. But like these are more manageable. Like at least we have the big picture of how we make it secure, and then the other ones we tackle one by one.

And yeah, um that solves one of the resources, but again, as we talked, there's so much more you want to give your agent, or allow agents to act on. So, there can be API keys, SSH servers, emails, bank accounts, physical world, everything else. And that's actually what my the rest of my research will look into, and that's how to uh address all of these, and try to give us agents that can securely act in the world. Yeah. I think that's that's all for me. So, yeah, thank you so much. >> [applause] >> All right. Thank you very much.

Thank you, Artem. All right, we do have a little bit of time for Q&A. Would anybody like to ask a question? We do have a question. Where's my little box? Can I have my little box? I love throwing this around. Yes. Who's got the question? Raise your hand. Here you go. Catch it and hold the mic close to your mouth, please. Feel free to ask. >> Uh thank you so much. Those those are pretty cool. >> Closer to me. Yeah. >> Here, um I have what the CK circuit that you have to specify that you're approving on top of uh does it resemble some kind of policy? And if so, how do you specify what policy the agent needs to follow and how do you ensure that it's not able to just bypass it?

>> Yeah. So, I guess the hard questions of the system are bypassed and set off to the actual person that decides what the configuration they trust. Oh, uh this was all right. Anyway. So, uh remember there was this AID, the agent identity document, and that's basically what you say you will trust the agent to be. So, effectively, um that's where the policy will be. So, maybe you just trust that the agent can only access Polymarket and act on the Polymarket data, and that will be the AID, and that's your policy. Again, like you can go as crazy as you want. That's out of scope. And actually, that also brings to the point like I've never really looked into ZK. Like ZK's part of it, but it's not as useful for most of the system. So, you also need to use TEEs, you need to use TLS notary, and uh

like Web TLS. I think there are so many technologies that can combine together as long as they are secure for your use case. So, yeah. >> Yeah, thank you. >> All right, great question, great answer. Let's give our speaker, Artem, another big round of applause. Thank you. >> [music]