Why Agents Shouldn’t Hold Their Own Keys: Introducing The Shade Agent Framework

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:11

   Hey everyone, good to see you. Um, yeah, great organizing here cuz we just had Nova before us who was actually building on the shade agent framework. So, really good um show of of what it can do. Uh, so this allows me to go a lot deeper into what the shade agent framework is, why we need it, and how it actually works. We're going to go quite deep here. A bit of an introduction to myself. I'm Owen. I work at Proximity

2. 0:43

   Labs, and we've been building the Shade Agent Framework for the best part of around a year. And basically in a nutshell what the shade agent framework is, it allows agents and off-chain services to become verifiable and decentralized so you can build properly autonomous businesses. So let's get into it. So why do agents need crypto? It's pretty common knowledge by now that agents need to transact. They need to hold assets to be able to buy items, pay for services, or even paying

3. 1:24

   other agents. We're somewhat seeing agents starting to manage people's money, which is really interesting. Um, I'm not ready to trust it just yet. Maybe in a few years, we'll see. Um, and we need agents to use crypto because I mean, agents can't open bank accounts.

4. 1:44

   they can't do KYC, but you can programmatically create wallets. And also, banks have a lack of cryp uh programmability that crypto allows for natively with smart contracts and uh APIs and whatnot. And we've seen agents using crypto already, primarily through SDKs like X42 to pay for APIs, inference, and content that's behind all pay walls.

5. 2:15

   So there's a few setups with agents. The main one is that agents are running on a a traditional cloud. This is what most people are doing. This is very cheap, very easy. However, you have no cryptographic privacy or security guarantees. So, the next one is you've seen a lot recently with Mac minis being sold more and more every day that people are running their agent setups locally, which is is great.

6. 2:46

   You have that privacy. Your data and your keys stay with you. However, hardware is very expensive and it's difficult to manage. And you've seen with things like OpenClaw, these more powerful frameworks, you need to you need to keep your personal setup completely separate to your uh agent setup because prompt injection and malicious skills could just extract your data without you intending it to do that. So the final one which is the best

7. 3:18

   at the moment really is running agents in trusted execution environments. If you don't know what a TE is, it's basically an isolated part of a CPU where the host, like the person running the machine, can't see what data is inside of it. And they can provide a proof of what code is running in there.

8. 3:40

   So, it's verifiable and private and verifiably private. And this setup's pretty great. However, there's some limitations in access to like frontier models because they need to be open source and um there's some exploits with tees which we'll get into which we've built some defenses around with shade agents.

9. 4:05

   So, trustless businesses, what is it? Basically, it's a business that's operated by agents that don't require trust of a human or code. So, this TE setup we talked about before, it's not sufficient for running trustless businesses because whilst the code itself is verifiable, the key is still known by a human. So, let's say you want to pay for your agent to do some shopping. You could deposit into this agent's account. You can

10. 4:42

    verify that the code is going to buy all the products you want and give you the best shopping experience. However, the developer of that agent could just come along, take the key, and extract all the assets from it. So, you can't trust the whole system. So with autonomous businesses, we need a way that not even the developer and no human knows the key. So we can build these businesses that operate just on verifiable code.

11. 5:15

    So the shade agent and other two trusted execution environments use a thing called KMS key management system which uh in the context of TEES allows agents to access keys like cryptographic keys only if they're running the correct code which is pretty cool. And how the shade agent framework does this is actually via smart contracts. So you approve which code is allowed to run in the TE and if it's running the correct code

12. 5:47

    then it's able to access the smart contract and sign transactions via the smart contract and this means that the keys never actually enter the TE which is great because we can build really strict guard rails for the agent to stop unintended actions and uh stop any actions even if the TE is compromised which there's been a few attacks lately.

13. 6:20

    So I think I had the wrong slide on there. We'll go on to this one. So walking through deeper how this goes and how you would develop a shade agent is that the developer starts by writing the agent code. normal and they calculate the measurements for this code. The shade agent CLI actually handles all of this for you. It'll compute the measurements and the measurements essentially are just a collection of hashes that dictate

14. 6:53

    what code is running on the T and uh what hardware it's specifically running on. So they calculate these measurements and they upload this to the smart contract. And they also upload a thing called a PP ID which defines which physical machine it's running on because with trusted execution environments it's actually quite critical to run them in secure locations because of side channel attacks. So if you approve specific PPI IDs you can actually verify which

15. 7:26

    physical machine this is running on and that it's running in a secure data center. And to go a bit more into the measurements, you can see there's a list here. So the MRTD, this defines uh the initial trusted domain of the trusted execution environment. RTMR0 is the hardware or the virtual hardware. So how many CPUs, how much RAM it has.

16. 7:51

    Uh RTMR one and two, these define like the kernel and the operating system it's running. And then there's the key provider digest which sets which KMS it's using. However, since shade agents they use onchain signing. It basically has no key provider. But we need to make sure it has no key provider. That's where why we measure that. And then the final one, the most important really is this app compose hash. And this sets what actual code you're running in the TE. So this is like your agent's code.

17. 8:26

    And so you can see we're verifying not just the app, but we're verifying all the way through to the operating system and the hardware. So when they've calculated the measurements, they'll go ahead and approve these in the smart contract.

18. 8:42

    Uh so when the agent boots up, it's going to derive and a private key called like an ephemeral private key and a near account that's associated with it. And it means the what it means by it being ephemeral is that it's like a one-time key that is unique to every single agent and it's generated randomly and no state or asset should be stored on this private key.

19. 9:12

    It's just used to call smart contracts and represent the identity of the agent in the smart contract. And these will be generated each time an agent boots up. So say the TE shuts down, it will generate a new key and a new account ID.

20. 9:31

    And to register an agent, the TE will generate a cryptographic attestation and then submit that to the agent contract. And there's a method in the contract called register agent that verifies the attestation. It says, is this a legit TE? Is it running on actual TE hardware? Then it will check does the attistation contain the measurements that the contract expects it to contain.

21. 10:00

    Does it check the PP ID? And it also checks this thing called the report data which makes sure that the the account ID that is calling the contract matches the account ID that was generated in the TE. So this lets you stop someone just coming ahead copying your attestation and submitting it and registering.

22. 10:28

    And so once it passes all this checks, it'll essentially just registering the contract with the agents account ID, its measurements, its PP ID, and how long it's valid for. So once an agent is registered, it can go ahead and request signatures for transactions. So when it's requesting a signature, it will do checks again. So it'll check it's a valid agent. It'll check it still has the measurements. It

23. 10:57

    still has the PP ID and it's still valid um like in terms of time. And you need to do these checks again to make sure that the measurements are still approved because a developer might want to deprecate old code and add new code. So it does these checks and then it also checks the transaction. So you can program in a load of different checks like what chain you want the transactions to be on, what functions you're allowing it to call for how much assets. So you can see here the agent is

24. 11:31

    only allowed to call the function by bananas on whatever chain and it can only use up to 100 USDC. And if this transaction is valid, it'll get signed. And to go into like how this signing actually happens, if you've ever heard of chain signatures, it's basically a service on near that operates on multi-party computation. So when the transaction is authorized and the agents authorized, it'll make a crosscontract

25. 12:01

    call to this MP MPC contract which is a contract on near backed by a load of individual nodes that will give you a signature share for your transaction. So each node gives you a signature share. The MPC contract takes all these signature shares, puts them together, and then gives the agent a signature.

26. 12:24

    And this the agent will just take the transaction, take the signature, put them together, and then relay it to the destination chain. So you see it's relaying to Ethereum here, but it supports basically like 90 to 95% of all chains.

27. 12:44

    and how to sort of update this system. You can uh the developer or a council which could be a multi-IG, they'll go ahead and approve new measurements to the contract. So these measurements allow the agent to run new updated code and you can remove old measurements which will uh yeah stop old code from running essentially.

28. 13:13

    And how it's like actually verifiable and decentralized is that anyone can take the source code of the agent and go ahead and compute its measurements and check that these measurements uh match the ones that are stored in the smart contract and the one that the agent is running. And you can just go ahead and query this all on chain and anyone can actually run their own instance of an

29. 13:39

    agent which is pretty cool. So if I give you the source code, you can go ahead and run your own agent. You can register it and you can sign transactions. And this is good for well, yeah, decentralization, redundancy, and even censorship issues.

30. 13:58

    So yeah, that's that's pretty much everything I have. Uh, thanks a lot for listening. Yeah, really interested to dive in deeper with you if you want to have a chat