Exploring AI Agent Authorization with MOI

GM, GM! Welcome to what's going to be another fantastic episode of DevNTell. So if you didn't know, DevNTell is a 30-minute podcast held every week allowing founders, hackers, and anyone in between the opportunity to come on the show and showcase what they've built. And today, I'm ecstatic to welcome Piyush and Gokul from MOI. So if you're not familiar, MOI gives every participant—human or agent—persistent, portable existence in computation. So if you stick around for today's episode, you'll get to meet Piyush and Gokul, learn all about MOI, and learn how you can start building with them today. All right, let's get into it.

GM, GM! Welcome to the show, guys. I'm ecstatic to have you on today.

GM, GM! Thanks for having us.

Of course, my pleasure, my pleasure. Yeah, I'm really keen to learn more about MOI, especially in this day and age where agents are going wild, as we've seen this week has been a crazy week. But before we get into all of that, would you guys just like to give an introduction about yourselves?

Sure. So hey everyone, I'm Piyush. I go by pmaheshwari on the Twitter side of things. I'm in space since 2018-ish. Before that, I used to be the security guy turned developer turned business developer. So being in there for a couple of cycles. So yeah, that's about me. Gokul, over to you.

Yeah. So hello, everyone. So I am Gokul. I've been working with MOI for the past five years, and I've been in the space for almost five years actually. Once I started with MOI, that's when I started working on the blockchain. So yeah, I've been a core contributor to the MOI consensus layer, and I do help the application development team on the dApp development. And yeah, that's about me now.

Excellent, excellent. And yeah, just curious, like what got you guys into tech in general? Was there a particular inspiration or kind of, yeah, just curious to hear the story.

Yeah, for me, it was like I was working as a bug bounty hunter plus security researcher, so working with a couple of security guys in space. And that's how I explored blockchain, and first of course Bitcoin, just because we got one payment in Bitcoin for particular, you know, gray hat submission. And that's how I was like, okay, this is interesting, not just value, but the behind the scenes as well. So that's how I started building things when it comes to permissioned, private, plus public chains. And then further, I worked with Polygon since early days 2020. That time it was Matic. And then eventually worked with Protocol Labs, Filecoin team. You worked with Lilypad, I know very well. So Lilypad was spun out from Filecoin, that was also interesting days. And then I've worked with Bware, and since this year I started with MOI as head of ecosystem and BD. And yeah, that's about my journey.

So yeah, about me, so I started my journey in blockchain when I joined MOI. Before that, I had done a basic project in college in blockchain. But after 2022, I joined MOI, and that's when I started working on the dApps basically. And after a while, I got an opportunity to contribute to the protocol where they were building a Layer 1 protocol from scratch. Unlike a lot of other L2s and L3s, this was in-depth actually. I mean, it was a deep tech idea to work on, so I was curious to contribute to that, and it was a very good experience that I have came across.

Amazing. Yeah, seems like you guys have been all over the place and really entrenched in the space, and I'm sure you guys have seen your fair share of things. Yeah, I think there's no better time to be in this space than now and building what you love. So yeah, just to kind of help set the scene for our audience today, I know MOI is really big on this concept of the participant layer. Could you explain what that means and why people should care about it?

Awesome. So I'll go from bottom-up, because when it comes to we, I'm saying MOI and Anantha was there, the chief architect, our CEO, he was involved on the core research. He did two research on the basic technology which is now patented technology for us called Contextual Compute, which is for who you are in the system, because as of now we are just defined by smart contracts. We have seen what, where, how, like smart contracts, data availability storage, but we haven't seen person's existence into space. And that's where MOI comes into picture as well, which is basically a public implementation of Contextual Compute. So the base technology is Contextual Compute, which is quite crazy. If you see, we haven't changed any systems for past 70 years. It's altogether same. Even Ethereum and other blockchains are built on the same stack. We haven't tried to change those systems, because parallelly executing, like simultaneous execution is a big problem. We have to wait for the transaction to be added in a block. We said, okay, doesn't matter. What we will do is that you as a participant—because a participant can be one person or an organization—it can do the transaction. So let's say Gokul and I wants to do our consensus or wants to do our transaction, we will achieve at our level. So that's the participant layer, we say the participant layer of internet, just because it is concentric to participant rather than the global blockchain or the global ordering system which we used to have. So that's where the consensus is altogether designed in this fashion that it can have, you know, more of finality is local rather than the global ordering. So that's what makes us special as well, and that's how the participant layer name came into picture. And why users should care about, there are many reasons. We have seen many reasons recently why you should care about it, just because literally you are giving your everything on Claude as of now, everything on multiple other platforms. If you give this to agents as well, your critical information, you're doomed because anything can happen with that agent. What we bring to the table is that, okay, you have that agent, register your agent. You as a participant have a kind of backpack, which is context super state, but we relate it via backpack, so that you can hold everything under your management rather than your agent is doing it for you. So yeah, I will talk about it later as well, but yeah, that's how people should care about it because everything around authority, especially, people are losing it. Agents are doing their own things rather than we should manage it. And authority is a human primitive, but we never talk about it in that fashion.

Absolutely. And yeah, just wanted to kind of hear your thoughts. You mentioned that basically a lot of the technology on the internet hasn't changed in quite a while. Why do you think that is? Do you think it was kind of like there wasn't a need for it to change until this moment where we kind of have a new participant on the internet—AI agents, so to speak?

That's a very fair question. Because if we talk about that why we did that, I mean, reason was simple: that we were literally building everything on the existing systems. We have seen two days before that PHP got hacked, and literally we were building on the same structures. We were not doing anything on top of it. Why MOI was, why Contextual Compute or both together was built, just because we were not talking about—like, we have seen data structures, we have seen many use cases, but person's existence was not there. And if we talk about person's existence, every country even wants to have their data to be sovereign to their state. As of now, they cannot do it. But with MOI, they have the ability that they can pick and choose. So okay, we have seen blockchains as well, right, that everyone was building it. Some of them also claim that they have achieved TPS of 40 million or so. Some commented that okay, I can achieve 41 million next day. Some, all of them are my friends, but no hard feelings. But the problem is this: that basically if we are trying to achieve like your nodes are sitting on a specific island, all of the nodes, or let's say in a particular jurisdiction, we will be able to achieve that because it's easy. But with MOI basically, or the Contextual Compute idea came into picture just because we were talking about the general structures into technology, while there was no paradigm shift. It was more of like, yeah, we were building on the same structures which we have seen, no carticians were thought of. So MOI was even built in this fashion that, okay, you have your validators—what we have, we call it verifiers. These verifiers can sit on a particular jurisdiction as well. So let's say if I am in Singapore, and if I want Singaporean specific nodes so that I can verify and the data can be in Singapore itself. As of now, it's kind of hard, but with us it is possible. So that's the reason we came into picture rather than using the traditional approach. So that's the reason we say that okay, that's how the Contextual Compute and MOI came into existence, because we were not even talking about the foundational change. Because we have seen TCP made the network primitives, we have seen HTTP made the resource a network primitive, TCP made the messaging the network primitive. What Contextual Compute makes is the participant a network primitive. Because information can be processed like anonymously, values, whenever we talk about values, we have to talk about participant, because it requires the participant. So yeah, that's the reason MOI and the core technology primitive of Contextual Compute came into picture.

Amazing, amazing. And is it correct to say that MOI is kind of like a specialized chain for like a particular use case, or do you see it as a general-purpose chain?

So MOI as a general, we say it like 'My Own Internet', so, or Moi in French, whatever you say. It is a chain which is designed, it's a Layer 1 which is designed in this fashion so that everything can be achieved at participant level rather than global ordering. Of course, MOI itself has a huge possibilities which we can achieve, because when it comes to enterprises, while we are working with enterprises, when it comes to the agentic commerce side, they create their own agent harness and they can create things with MOI from authority perspective or otherwise. But the initial niche or initial target what we want to achieve is authority. Because authority is something need of the hour, because agents are booming, and that's where we came up with MOI authority layer initially. And of course, it will expand further, because MOI in general has a lot to offer. I'll share definitely further as well that how exactly this structure looks like. But yeah, in a nutshell, it's more of like MOI authority layer is the first layer which is more of like the SDK version of it. So you can have your agents anywhere, doesn't matter if you create it on LangChain or any kind of OpenClaw or something like that. You just have to register your agents. You as a participant can make these agents work on your behalf, on your mandate. And the best part is you can change these mandates on real-time basis, which happens just because of interaction finality. Agents check that, okay, is the set of rules same for me for every single instance, and based on that they can work on new set of rules. And yeah, you can of course revoke your agent whenever you're done. Of course, we'll talk about this when we will showcase our demo as well. So yeah, that's the reason we are coming up with MOI authority layer initially. And yeah.

Amazing. Yeah, I would love to see a demo if we want to get into that now.

Yeah, 100%. So I mean what we are showcasing is kind of a big demo. So I'll try to demonstrate more of like how we are going into this demo, what all things are there. So yeah, let me share my screen and let me know if it's visible.

Yes, visible now, yeah.

Awesome. So we are talking about MAL, or MOI Authority Layer specifically, which basically allow people to build safe, more of reliable, and you know, verifiable, especially when it comes to autonomous agentic systems. This framework is basically, of course, powered by the Contextual Compute stack, which is our core patented technology. Of course, before I dive deeper on the capabilities, I would like to answer the question why AI and what problem we are trying to solve. As we all know and recently also have seen, agents are moving from being passive agents to active operators. So they are not just like, okay, 'Hey, here is the restaurant, what would you like to do?' but they are more of like, 'Okay, I can order dinner for you, right? What all needs you have?' It should be like that. But today agents are not reliable enough. You cannot rely to share your socials to agents to do independently. This is, and there are multiple instance we have seen, right? Literally a week before there are many instance, but now as well, like some of the screenshots which I have shared here, it's more of like from Twitter, of course, where agents give unexpected outputs. Agent hallucination itself is a big problem, which provide any slate data. And we have seen this with ChatGPT as well, that when you ask something within a time-sensitive, ChatGPT respond with the data training set which it has had six months ago. So it doesn't make sense, right? And not only there are multiple instances, but people lose control of these agents is something we have to take into consideration. While we have seen this with OpenClaw recently—of course OpenClaw itself, the founder mentioned, I'm not sure if you have seen, that he's consuming 10 million tokens, oh god, without trust, doesn't make sense. So that's where OpenClaw get access to everything, right? We have seen like file systems access, resource access to database access, and everything and giving like any unwanted behavior they used to give, and it has access to all, which doesn't make sense. And the third part of it is basically, when it comes to agents, there is no way for us to validate, to review exactly that agent has done this, what is handed to it. The verifiability factor of agentic actions is close to zero, of course. These are exact problems which MAL is trying to solve. The moment agents start kind of acting on your behalf, the convenience is not just enough. The system needs correction, authority, of course accountability, and that's exactly MAL offers. So that's the core, sorry, I was on different page. Yeah, that's the core architectured layer we see, which is more of like that, okay, we have like kind of four capabilities around MAL as a platform or infrastructure which provides for agentic developers.

One is, of course, universal identity. The universal identity is more of like that, okay, every actor, whether it's a user, application developer, or basically agent, gets an identity powered by a public key infrastructure. This can be integrated into existing identity providers as well, doesn't mind. We don't mind. It's more of like a universal identity, once it's recognized for agent, it can be accessed on anywhere. Second is, of course, delegated authority, so one of the most important feature of this framework, which is more of like that, okay, you allow people to define fine-grained rules or mandate in general so that you can control and limit the actions and resources that the agent can access or work on behalf of you, and you can define whether the agent have access to particular resource or not, but also at what extent it will be utilizing those resources. Next, of course, the unified context, which I have talked about before as well, because the effectiveness of agentic outcome is basically derived by context, that okay, they are trying to operate on particular context so that they can get important agent to operate on the latest context so that they don't have to give any slate or unexpected behavior. And this platform allows to verify whether they are really acting on the latest agent's context or not. So that's the point of view when it comes to the unified context. Of course, we have verifiability, that all actions on the platform, whether the user is using delegated authority, whether the agent is accessed a particular resource or the policy. So these four are the capabilities. Now when it comes to the layered architecture which we see here, of course we see the base chain, which is more of like chain substrate, where okay, this is basically where core delegation authority or truth lies—credentials, authority sessions, or maybe even scoped tokens, policies anchored on-chain. All actions on these anchored on-chain acting on an evidence log. This layer basically gives you the cryptographic guarantee that okay, what you have given as a delegated authority to agent, it is giving only output what exactly you require, and it verifies all the actors there. Then of course we see the runtime environment. In the runtime enforcement, this is where policy defined, the user, the agent developers are enforced on particularly two sides: of course the gateway and the session manager. Gateway is more of like a middleware between agent and external resources, which is of course user-defined and enforced. When it comes to session manager, it is basically manages authority on multiple agents in multiple agent orchestration systems, because we always say that agent orchestration systems can be, be it LangChain, be it CrewAI, doesn't matter. Then, of course, we have the control panel, which is top layer. In control panel, we have identity service, which is more of like, okay, all the actors which are there in the system, you can see it there; policy service, which allows basically to define fine-grain policies on what agent can do or cannot do; the delegation service, of course, which is more of like a multi-agent delegation, so even agent-to-agent communication is easy with this kind of architectural way. And the best part about it is that it can work on the existing IAM stack, working with identity providers, be it Okta, Entra ID, or Ping, and the identity governance system, be it SailPoint, and API gateways can be anything like MCP, API, Kong, and of course any kind of monitoring or auditing systems.

Now what we are going to show today is called TrustClaw, which is basically a module on top of OpenClaw, which is stateless, permissioned, verifiable. Oh, okay, I forget to rename it. Sageo was the older name of MAL, but yeah, it is stateless, permissioned, and verifiable. Stateless, what it means is basically the agent needs to store the personal details of the user. It asks questions to the trusted service whether it's connected. Then permission-based, all actions need to be approved and authorized. The agent operate strictly within user-provided permissions. And verifiable, all actions are verifiable. What we are going to showcase is the food ordering and payment. So yeah, let's get into it, that how exactly it looks like. So we have the chat application, and chat application is literally the Telegram, and we can literally, you know, chatting in Telegram and communicating with our agent. Orchestration, we have chosen OpenClaw and built on top of it a module which is with all the external backend services. The services which we are using is more of like, for agent registry service is there, access control service is there, inference service is there, storage service, anything you can use it. So you can use any kind of these services. Of course, the user context dimension in the demo is much more important, where of course we will talk about that okay, there are four different applications which is Pulse, MealMind, and your address, calendar, everything is aligned. And now I will pass the screen to Gokul so that we can get into the demo and get started.

Cool. Thanks, Piyush. That was so in-depth. And yeah, I would like to start with the evaluation of blockchain. So it got started with direct P2P transfer, where you can transfer some tokens from account A to account B. And then came smart contracts. But nothing got resolved. It became centralized, because the smart contract became a bottleneck. So now all this information is present in the smart contract. So let's say if there are four accounts: account A, account B, account C, and account D. If everyone is trying to do a transaction between a couple of them—let's say account A is trying to do a transfer with account B, account C is trying to do a transaction with account D. Now one of it has to get completed first, because the smart contract state is going to get changed after a block gets finalized, and then the next one will get processed. That's the sequential process, or that is what the bottleneck is. And then we tried to solve it with MOI. That's where this participant-centric idea came in, where every participant will have their own chain. So we can take the same scenario: we have a smart contract, and when account A is trying to do a transaction with account B, at the same time account C and account D can do their own transaction. Because account A's chain, account B's chain is what is going to get affected based on account A to account B transaction. And similarly, account C chain and account D chain is what is going to get changed because of the transaction that is going to happen between account C and account D. So everything is stored under the participant. So that's the idea behind this participant layer. Right? So now, as this agentic systems started evolving, we understood that this layer, whatever we have built, will be very much useful for the current systems that are getting built. So we also see the gap there, and that's where we thought of building a layer on top of this blockchain layer, participant layer that we have built already. So that is what is called as MOI Authority Layer. So yeah, let's just get into some fun session now. All this time it has been too technical.

Don't be afraid to be technical on this show. Be as nerdy as you want!

Cool. So yeah, is my screen visible?

It is, yes.

So what I have now is I have four apps. One is called MealMind. It is like your food app where you order your food, or you have your food preferences like what you like to eat, all those things. Let's say I have my food profile where I have mentioned my dietary type, my cuisine preferences, and my spice tolerance level, calories that I would intake per meal, all those things, right? My breakfast, how would I want, whether it has to be light, medium, or heavy, lunch similarly, and dinner, snacks, everything. And I have my favorite restaurants mentioned, and favorite dishes mentioned, and some ordering notes where I specify what I want or what I don't want. So that's all it is. So this is a separate app where I set my food preferences here. And then I have my health app, which is called as Pulse, where I maintain my health profile. So health preferences, or health profile, where it has complete detail about my medical history, like what blood group I am, and basic details about my blood pressure, sugar, weight, height, all those things. And any medical conditions that I am already aware of, and my dietary restrictions, and the medications that I'm taking, allergies, and other emergency contact details, and some additional notes. Similarly, I do have an app for managing my day-to-day calendar activities. So I can get to see the details of each thing here, I mean each day I can get to see. It's basically like your Google Calendar or Microsoft Calendars, something like that. And I again have another app called Landmark. So this is basically used to maintain my address details. So what I do maintain here is my address, and I do also whether it is home, work, other location. So if you, let's say if I try to view my work address, I have some delivery instruction listed. So I specify a delivery time here. So what happens is when the agent is trying to place an order, it is going to look for these preferences once I give the permission, and it is going to take an action based on this. Let's say if I'm trying to order during my work timings, then it is going to place the order to my office location. Otherwise, it is going to order to my home location. So that's the idea behind these four apps. Basically, I have my health preference, I have my food preference, I have my calendar information, and I have my location information. So this is all it is.

These are four different Web2 applications.

Yep. So as Piyush mentioned, we will be using Telegram to demonstrate how it works on top of MOI. So we also have a Agent Explorer.

Yeah, we should showcase. Our Agent Explorer is at agents.moi.technology, where you can see every agent anyone have worked or registered on MOI. So yeah.

So this is our Agent Explorer. So here to see the list of agents that are already there in the MOI ecosystem. The agent that we are going to demonstrate is called as TrustClaw. So here is where it is. So it's basically a food ordering assistant on Telegram. Helps users discover restaurants, browse menus, place orders, and track deliveries, all within chat interface. So that's the idea behind it. And let's just get started. I'll open my Telegram now.

So this is the bot that we are going to use to place the order or interact with the agent.

And this is basically like, you know, you're writing prompts. So, yeah.

So yeah, I'm just getting started now, and I could see a hello message here. It says about TrustClaw itself and how it works. So it says, 'Your data lives with you on MOI, not inside this bot. I don't have access to your data by default. Instead, I request your permission. I ask only relevant questions. A trusted service uses your approved data to complete the task.' So this agent is not going to make utilization of whatever app informations that we have. So this agent is going to ensure whether we have sufficient permission, whether it has sufficient permission to act upon or not. So that's the idea behind it. And it says what we can try now. It says, 'Right now I can help you order food using your preferences, health profile, address, and schedule, all within your approved permissions. More workflows will be supported soon.' And it gives the list of comments it supports, and it asks me to connect to my MOI wallet. So let me connect to my MOI wallet.

So MOI wallet is like your other wallets: MetaMask, Phantom wallet, and few other wallets. Okay, it was successful. I am connecting my MOI wallet. I'll go back to Telegram. Says my MOI wallet is connected. What I'm doing here is I'm connecting my account that is there in MOI wallet with this bot. So all of my permissions still resides in the wallet, nothing goes to the app, but still I'm just casting that.

And this is basically representing the participant.

Yeah. So I'm saying this bot that I am this particular participant, I have my address, right? Once I connect to it, it will be able to identify my address. So now it is asking me whether it's me who's trying to do it or not. So I have connected my wallet, now it shows who I am. It knows who I am, but I still have to verify that I am the right person who's trying to portray that I am this owner of this particular account or not. So for that, I'm signing a message. It will verify. Once it is verified, it says, 'You're all set. Your MOI wallet has been verified and linked to your assistant. Your identity is secured on MOI network. Only you control your data. Now just say "order food" to get started.' So since this is a food ordering app, to get started we can just say 'order food'. We can go ahead and try different ways to order food later, but for now let me just say 'order food'.

Okay. Now it says browse by cuisine. So it says, 'Select a cuisine below, I'll surface the best available options for you.' These are all the cuisines available. I'll go ahead and choose Korean. Says searching for best Korean restaurant. So what happens in the background is it is going to search for a good restaurant. But before that, it doesn't have sufficient permission to do that. So it is asking us to give the permission that is required to read the food preference, health preference, delivery details, and our calendar schedules. So to do that, what we have to do is we have to create a grant. So we are going to create a grant. What does it mean? We are going to create a interaction which is going to provide the agent the grant it requires to act upon whatever we are asking it for. So now let me sign it. So it is trying to process this transaction.

Cool. So now the interaction got processed. It is now trying to curate the best restaurants for us based on our health preference, food preference, and other details like our calendar and address location. Okay, it brought in some options for us. So this is the restaurant that it has found based on our preferences. So I would just go ahead with Korean Fried Chicken. So it is checking my schedule now, whether there's supposed, the reason why it is checking the schedule is because let's say if there is a meeting for me during the delivery time, it would just deliver it after the meeting session. So there is no meeting that's clashing now, so it has just gone forward. Now it is asking me, it has also chosen the delivery address as my apartment location, since it has crossed the 9:00 PM timeline. So based on our instruction, it has now scheduled the delivery to our home location. Let me say pay using USD.

So now I can pay using the USD currency. So USD is nothing but a native token that has been created in MOI and utilized in the, utilized by this app and other apps. So it is like how Ethereum has USDT, something like that. This is a testnet, it's not actual token, but yeah, this is just to demonstrate. Now the transaction is happening. The transaction went through successfully. And also my order has been finalized. So this is one scenario. This is a happy case scenario.

So now what is happening in the background? This agent doesn't know anything, doesn't know anything about you until and unless you give this permission. We approved it to use our preferences, right? Until then, this agent doesn't have any idea about you. In the sense it can't read these preferences or your delivery details or schedule information. But now once after we approving this, a grant is created and stored under my identity, my account. So now what the agent does is it will try to check my account if there is any active session where it is allowing me to perform this operations of reading this preferences. So once that is successfully present, it takes the next step. Otherwise, it will be rejected upfront. So how is it different here?

So it has this concept called unified context. Now you have multiple apps. Let's say I had four apps now. All of this information doesn't know about each other. But still, when I'm using this particular agent, it is able to read all these preferences of me and act upon it. So it is because it is built on one common layer called participant layer, one common participant layer, MOI basically. So that's what we call as unified context. There is another case to consider here. You have an agent A where you have created a grant, as a user you have given a grant for that agent A to perform some action. It also has delegated some permissions to another agent B or C, let's say two other agents. But I am not aware of those two agents, and the MOI network is also not aware of the other two agents. It just knows only about the agent A. Now when I as a user go ahead and revoke that grant, revoke the permission, immediately the other two agents won't be also able to take any action because it is revoked.

So once it is revoked at the parent level, the other two agents, either I'm not aware of it or the MOI network is not aware of it, so both of it can't perform anything. So what do we get out of it, right? I mean if something goes wrong, let's say this agent behaves beyond my permissions, at this point we can easily identify that this is the level of permission that I have given you and you have crossed it easily. So we log all these interactions in the network. So we can easily get to know whether the agents have crossed the permissions or not. So that's the core idea. Now what we can try to experiment is I'll go back to my Pulse app. I'll do add chicken to my allergies.

I have severe chicken allergy. I'll add it.

And this is happening on real-time basis.

Yeah. So I'll just show this here. So I have my participant info here where it shows me the list of authorizations that I have granted. So I have granted an authorization for this particular Telegram agent sometime back, right? So this is the one here. If I want, I can revoke it. And can you also see this preferences, the context that I've been talking about—the food, health, and address, and schedule context. And if you see, we just updated the Pulse info at 9:39. So yeah, almost around 9:40, if you could see, it got updated. So it got updated on MOI participant layer. Now if I revoke this, the agent cannot do anything, and the agent could have delegated this permission to other agents that those agents won't also be do anything beyond our permission. So that's the idea behind it. And now since we have changed it, what I will try to experiment is now I'll try to order chicken burger. Since I am severely allergetic to chicken, it should now not allow me to order chicken burger. So let me write.

It is prompting on your, the agent is running and you are prompting.

So what it says is it already found an active session which we have already created, so it has the permissions, it verified that it has permissions to read all our preferences. Now it's checking our menu and finding a match to order burger. It found The Burger Joint from the list of restaurants. So it has now personalizing our order by going through our preferences. And now it says that, 'Found Crispy Chicken Burger at The Burger Joint, but it conflicts with your profile. You have a severe allergy to chicken. Want to try something else?' is what it asks. So it has identified that based on my preference, whatever that is there at the MOI participant layer, it has now identified that I'm not allowed to order this because my health preferences is not allowing me to do it. So yeah, this is the other case. And the other thing that we can try to do is now we can try to revoke it.

I am trying to revoke this token. I can do revoking in my Telegram bot as well, but I'm trying to revoke it with the WebApp. Let's try to see what happens. Okay, it got revoked. I could see it got marked as revoked. Now what I will do is I'll try to order food again. Okay, it gives me the option.

Okay. So what it has done now is it has given me the option, I have chosen it, but there is no session, active session allowing this agent to read my preferences. So it couldn't process my order. So it is asking me to provide a grant again. So what we are trying to demonstrate here is pretty simple: in the current systems, what is happening is you have your credentials like OAuth token, JWT token, your password, and different types of credentials which you directly give it to these agents, and they delegates it to other sub-agents. And you can never revoke it back until and unless that token gets expired. These agents can misuse it according to the way they want. You can never take control of it. But with respect to the layer that we have built, you can give the permissions, and until the permission is alive, until there is an expiry time for the permission—so if you see here, there is an expiry time for it—until then it will be active. Before that, if you want to revoke, you can quickly go ahead and revoke if you feel like some agent is misbehaving. So that's how this system is built, and I mean this particular layer is being built. So it gives users the full control to act upon and take control of their authority, unlike the existing models where you give the permission and that's all, it's gone, can never get it back until it gets expired by itself.

Yeah. That's the reason we say that information about authority is not authority, the authority should be the human primitive. And that's the authority layer, the SDK we are bringing to the market, that okay, you can change the things on real-time basis while agent is working on your behalf while you can do something else. And yeah, that's the beauty, the showcase which Gokul showed.

Awesome.

Yeah, sorry, just to add this point. So one another thing is the interaction logs. So whatever we have done till now, every action is recorded. If you see that preferences that the agent has read, so that information, can you see this here? Said categories here, right? All these things are available in the traces. So anyone can easily identify if the agent has misbehaved or not with the help of these logs very easily. Every action has been recorded here—the grant creation, the grant revocation. Let's say I have revoked the session or the grant, and the agent is still trying to access my data, I can easily get to know. So yeah, that is something that, yeah, that is the core idea behind what we are trying to solve. Yeah, up to you guys.

That's amazing. Thank you so much for that in-depth demo, Gokul. That was really cool, and it was like you're actually doing it live too. So demo gods were nice! Yeah, you pulled it through. So as we're kind of approaching time here, what would you guys say is the best way for developers watching today to start building with MOI?

I think many things. I think our docs are pretty fine. So let's say the SDK, you will be able to use it to build any kind of agent, just like in Telegram. We have something called as launchpad.moi.technology, which is a basic version, you can test it out on your Telegram. And the final version is more of like that, okay, with MOI Authority SDK, you will be able to make transactions happen on Ethereum, on Solana, doesn't matter on any chain, the authority being issued from MOI to your agent on your behalf, and you can change it on real-time basis as Gokul mentioned. So that's the beauty, and all the things which Gokul showed, be it from the Agent Explorer, the wallet—I mean it will be much more time-consuming, so we have directly showcased, but you can reference our docs. Everything when it comes to wallet is available. We have a wallet-specific app as well. You can check it out as Gokul mentioned. Everything is there. So yeah, the SDK is going live soon. It's I mean it is live, it is live on the docs, everything you can test it out. So yeah, let's start building together.

Amazing, amazing. And yes, for the audience watching, listening today, all those resources will be in the description of the podcast below. So if you're interested, definitely check those out. And yeah, I just wanted to say Piyush, Gokul, thank you so much for taking the time out of your busy days to come chat with us. It was amazing to see MOI in action, live demo too, and yeah, wishing you guys the best going forward, and yeah, excited to see how MOI evolves. And with that, I just want to wish everybody a very happy Friday, wherever you may be. Happy weekend, and that we will catch you back here next week for another great episode of DevNTell. Until then, have a good one, folks. Cheers.