Identity for AI Agents - Patrick Riley & Carlos Galan, Auth0

• Auth0/Auxedo introduces new identity and authorization solutions specifically for AI agents, addressing emerging security challenges in autonomous and interactive agent modalities.
• Their framework is built on four core pillars: agents needing to know their identity, calling APIs on a user's behalf, requesting user confirmation for sensitive actions, and enforcing fine-grained access control.
• Key features like Async Auth enable AI agents to initiate requests requiring explicit user approval, while Token Vault provides secure management of upstream service tokens to facilitate API access.

• Adopt a multi-faceted approach to AI agent security, recognizing that agents introduce new challenges compared to traditional user-based interactions.
• Frame AI agent security around four pillars: ensuring the agent knows "who I am," enabling agents to call APIs "on my behalf," allowing agents to "request my confirmation" for critical actions, and providing "fine-grained" access control.
• Implement Async Auth to create a protocol where agents can trigger a notification to a human user for approval when an operation is deemed risky or requires explicit consent.
• Utilize Token Vault to securely persist and manage refresh tokens for upstream third-party services (e.g., Slack, Facebook APIs), simplifying token exchange and maintaining agent access without continuous re-authentication.
• Model AI agents within the identity platform as clients and external APIs as OAuth resource servers to leverage existing identity and authorization infrastructure.
• Differentiate between scopes, which grant specific API access permissions, and roles (often managed via FGA), which define broader identity personas.
• Leverage the Auth0 SDK to integrate authentication, token exchange, and user consent flows within your agent applications, simplifying the development of secure agent interactions.

AI Agents — Autonomous software entities designed to perform tasks, often on behalf of users, interacting with various services and data. Authorization — The process of determining what an authenticated entity (user or agent) is permitted to do, based on policies and granted permissions. Client-Initiated Backchannel Authentication (CIBA) — An OAuth/OpenID Connect flow where an application (client), such as an AI agent, initiates an authentication or authorization request directly to the authorization server, and the user completes the flow on their own device (e.g., via a push notification). Async Auth — A feature that enables AI agents to initiate an authentication/authorization request requiring explicit user confirmation via a separate backchannel, returning an access token to the agent upon approval. Token Vault — A mechanism for securely storing and managing refresh tokens for upstream third-party services, allowing agents to obtain new access tokens as needed without requiring the user to re-authenticate. Token Exchange — An OAuth 2.0 extension that allows an existing security token to be exchanged for a new token, often for a different audience or with different scopes. Scopes — Permissions used to define specific access rights to resources or APIs, typically requested by a client and granted by a user or an authorization server. Refresh Token — A credential used to obtain new access tokens after an existing access token has expired, allowing for continuous access without repeatedly prompting the user for credentials. Access Token — A credential that grants an application or agent permission to access specific resources on behalf of a user for a limited time. OAuth Resource Server — An API server that hosts protected resources and can accept and respond to protected resource requests using access tokens. IDP (Identity Provider) — A service that creates, maintains, and manages identity information for principals and provides authentication services to relying applications.

We're talking today about identity for AI agents and how we authorize agents and TP servers and the like. We've launched a new product actually this week so that made this presentation fun. Had a major release just a few days ago for several of these features in GA and these. Additionally, I should probably prefer by saying a lot of this workshop material has been repurposed and our architect, Bobby Schick, he goes by nickname, Siam Shrek, kind of prepared a lot of this and we've kind of massaged it into this presentation. Yeah, so we're going to cover each of these in depth and some of the core features of this new release whether it's token vault and async auth and we're not going deep on FGA but just know that there is another kind of sub product if you will that's all around roll-based access control. There's an open source project around fine grain-doth which really extends this feature set but that's really kind of another talk. So yeah that's some of the things we'll be talking. Quick intro's it's my first time at AI so thank you guys. That's been awesome week already wearing so much. Yeah, I'm from Raleigh not actually a shire but this is a little bit about me and yeah it's been great. I came over from two Otsura from Red Hat and we've learned a lot about the identity space in the last four years. I'm going to roll over to Carlos. Yeah hi, yeah I'm Carlos I'm co-host with Patrick for this workshop today. First time in New York, first time in the US. Thank you for the welcoming. I'm best seen in Spain in Mallorca if you know the places of beautiful island. I joined Alzira and Octaar. I did it a bit more than two years. A lot of two and well yeah a little bit of above myself. So I'm gonna I want to start this with a vision that Octaar and Alzira shared. This is to free everyone to safely use adding technology. And the fun fact about this is a vision that precedes the AI Asian era and still stands because of the entity there is what we do. We deal with identity for past present and future technology and yeah. Just to keep a little bit of what's the challenge. So I said that our vision is to to free anyone to use any technology but it doesn't mean that all the technologies are the same and all the technologies has the same challenges. It's obvious that agents bring new challenges new threats and just to illustrate this updated list of the OSLLF top 10. So you can see new things that they didn't exist before. So yeah obviously we need to solve new problems. So how we model for how we think about agents in Alzira. So we think yeah so far we seen interactive agents, chatbox, code editors but this is unlikely the future. We start to see other modalities where the agents doesn't run any more in an interactive way. That's runners or autonomous agents is something that is very popular this is. But beyond that we see a feature where fully autonomous agents can do things either on behalf of the users or maybe just because agents will start talking to other agents. So this is how these are four pillars that we believe will cover all these new modalities. The first one is AI needs to know Fuaia. So this is key. If the agent doesn't know Fuaia, it can't never apply any security or any interstiction or any authorization authentication because it's an unjusted anonymous source or actor in this and this is important. The second is obviously the agents will be autonomous enough but it doesn't mean that it will be alone. It will be doing things on its own. Eventually they will need to access other services to consume other resources. So AI needs to call IPIs on my behalf as a user. But sooner or later the agent will try to do something please care or something that I don't think as a user the agents should do on its own without any supervision from my side. So AI can request my confirmation. And lastly AI access should be fine-grained. So I need to give the agent control to access my resources but not any resource, not any collection or document or anything. It has to be on my hands to what the agent can access and what not. And just to also introduce where Octa and Auxedo can play our complement each other. So we talked about a user and it could be me, it could be you but eventually it will be an employee with an enterprise or company. And in this case the employee is not only acting on his own behalf is also representing their company. And in those cases the company needs also control what exactly those agents that are acting on behalf of those employees are doing. So that's where Octa also plays an important part. And in the other end Auxedo is what we the capabilities and features that we've implemented I think is where they connect. Yeah. It's not where you are. Yes. Where you are as one and the user and the permission. Is the subject of the operation that you are doing? It could be anything. It could be you as an employee, it could be you as an owner or something, as an administrator or something. But at the end it's a person, a human. In the scenario I was talking about. Is this what what what permission the agent have access to or who has access to the agent? Like I want to say both. Yeah. What's that? We're good. We are definitely touching on both. So yes, let's yes. And time for questions at the end absolutely. Let's make sure. Thank you. Thank you. All right, so let's get deep on exactly what we are going to present today. We talk about four pillars. Not in a particular order, but we are I'm going to introduce one of the three, which is how we made possible one of the three, which is AI can request my approval. For that, we implemented a sync auth as part of the auth for AI agents offering. And basically this feature, what it does is create some mechanism and a protocol for the agent to reach out the user when an operation needs to be approved by the human in this flow. It seems simple. It is in essence, but well, it's a security. But it's built on top of client initiative authentication. Sorry, trying to initiate a batch of authentication protocol. It's an RITC specification. And it's yeah, so in this scenario is the agent that it's initiating the authentication and authorization. So the agent is running, maybe it could be a long run autonomous thing. And at some point needs to make a purchase or make something that is flagged as risk. So with a sync auth and with a simple SDK code, it can initiate a not the recession request that materializes a notification to the user. The user receives the details of that transaction, well, structure. The user acknowledges that, approves that. And then that approval gets back to the the agent in formal from access token. And that access token contains the exact details that the user approved. And yeah, I'm going to hand over to Patrick for the client. Awesome. Yeah, I think you Carlos. Yeah, good question. Thank you for questions. The token vault is the other kind of like you know, major feature we're introducing with this AI, we're an AI targeted Ossia release. And token vault is a new mechanism for persisting your upstream resource refresh tokens. So I'm sorry, refresh tokens. And you may have used Ossia before, right, for social providers or Intangent with like other identity providers. This makes use cases with events much, much easier. So we have a really fine grain now flow, which allows you to exchange tokens. So on behalf of the user, so I can send my access token or my applications refresh token, whether it's for an API, whether it's for my application, and I can then request scopes for an upstream service. So whether that's accessing Slack API or Facebook API or any other identity, you know, scoped API. So yeah, and we actually persist scopes. We manage lifetimes of tokens. We do a lot of handling there to ensure that your SDK life is very easy. And that your agent stays online and it's available. And it's secure. And yeah, we've been testing this flow really extensively, but you can kind of get a picture of what is going on under the hood. And yeah, we'll talk more about token vault in the in the shop. It'll make a lot more sense when we get in there. I do want to kind of highlight a few flows though, where you know, I mentioned refresh token and access token. As we are digesting each of the agent frameworks, you can kind of see that, well, it may differ if you're using a single page app, right? And you know, you don't have a backend, which is as secure or you're wanting to access an external API. In these cases, especially like with Lengra, we use an access token. We have short lived access token. That's simply because Lengra stands up an external API. There's a Lengraff flow to call around the Lengraff CLI. So yeah, in this case, we kind of modeled that flow. Whereas other flows, you may just have a native app or a simple next JS regular web app, traditional web app with your agent running embedded. Then yeah, in this case, like refresh token mate fits your use case perfectly fine. And then I think as we're going to talk in later, there's also cases where, you know, maybe you have an asynchronous agent accessing other data. We have a new mechanism now called a custom API client, which can allow an MCP server, for example, to access remote data. So that's kind of the conceptually what we've done at off-zero. We've just taken agent. We've kind of modeled it as a client, and we've taken your APIs, and kind of modeled them as traditional OAuth resource servers or APIs in our platform. So yeah, that's a little bit what's going on here. I've kind of listed some details about token exchange on the slide. Yes, just know that the subject token type is kind of type of exchange, whether access or refresh, the subject token is your token. The user token may be an exchange for the third party token. And see, this is a really quick gif of our interrupt flow with Lengraff. Recently wrote this, so it just shows kind of what the mechanism looks like. If the prompt says, you know, I need access to my calendar. We have a Google social provider. We have an interrupt. You know, this part of our SDK, it will feed you back the mention that you need to request additional scopes. We then do the token exchange from token vault, get you a new access token, and then you can access your upstream provider. Really quite simple in our framework now. And quickly about MCP, and then we'll dive into the workshop. MCP is very new for us. We just launched a preview. But we've been avidly working on this for quite some time. But yeah, you can kind of see where we modeled the MCP server also as a client. And yes, there are cases where Agent is a client talking to MCP server, which is also a client, talking to upstream APIs. And that's actually where I'm going to show it today. But yes, the flow is quite similar and we'll talk more about MCP semantics. And you know, how we've implemented dynamic client registration and kind of what we have here. These are totally from our teammates. So just trying to pick our favorite slides. And yeah, and as far as the workshop, I think we're planning to just kind of high level high note each section. And if you don't want to work through it, that's okay. You can follow along. If you want to work through it, and you're more hands on, that's fine too. And yeah, we really, truly appreciate all your feedback. We do have time at the end for questions and all kinds of feedback. So we would love that. And yeah, this is what we are building today. Basically, we are building an agent next JS app. What's nice about ourselves platform, right, as we can build MCP tools alongside our agent in the same infrastructure quickly, we can then use the agent client to communicate with the MCP server and then leverage the MCP server to talk to third parties. So that's really powerful. And you know, it's secure and it's easy to build. You know, we feel quite good about several areas of the security stack there. But yeah, I think this is kind of the rough idea, like a lot of typical flows you might see in the industry. So we're going to, yeah, so we can pull it up and get going. Hopefully everybody is able to capture the link. All right. So yeah, yeah, well, Patrick is showing and kind of doing the workshop. I'll be available for anyone as a question or a problem with the workshop itself. Just try some hand. I will approach you. Awesome. Awesome. Yeah. And I'll do like a physical intro, then kind of showcase what it does. And we'll kind of step through this journey of building that topology. So yeah, but welcome is really just around getting your dependencies and getting a client. And so I guess the first step here, we have a root tenant upstream IDP for you. So this is kind of a little more of an enterprise use case. So let's say you have a core IDP provider that you know, you tap into for like upstream API management or upstream identity. So we have this like fictitious stock trade application, which looks like this. And this application, basically the idea is that, you know, consumers can come here. They can access a stock API. They can establish identity here. But this application also exposes an API for downstream consumers and downstream agent clients and additional consumers. So we have a basically a link, a federated, a linked access with our IDC connection to this tenant. So yeah, so the first part is really just getting your client. I already have a client, but where you would start here is basically just going through AuthSero's stack and getting a tenant and starting to get your client developer keys. So we'll add off as a subsequent step, but I'll show the like the first step where we just have a really simple agent. And then we're adding on identity and then authorization. So yeah, these are some prerequisites. Node, PN, PN, standard toys, AuthSero CLI. So we use the CLI for a lot of CLI management of our stack. It makes some things easier. We use a combination of Terraform and CLIs in this demo. And yeah, so that's kind of the conceptual overview and some of the like major dependencies. After you've created your client, kind of signed up here, we've got a link to it here. You should be ready to go for spinning up your tenant. But yeah, I'll talk more about that in step two. So yeah, let's start with the very beginnings here. So in this step, we're just, we're building our downstream chatbot. This is a downstream application that we're just spinning up. Hasn't connected to anything yet. And we're adding on this upstream provider and adding on access with agents and with tools. So yeah, I used OpenAI with my agent, but the AI you'll need an Open API access key. This is the repo which has the base template. I'll give you a branch at the end which has all of the changes we make in this workshop. And yeah, so let's take a look at what that looks like. Okay. So yes, standard chat box. So at this point, when you start, if you try to do anything other than just regular gen AI questions, you will get just the model, nothing else. But the important part is if we try to ask the model who I am, that's where the model says, okay, I don't know which day is, so I don't know. The same for in this case, this is a downstream of a trade app. If we try to consume data from that trading service, like again, the chatbot will tell you, I know nothing. So let's fix that. Let's give the chat box awareness first of the service and tools, and then also authentication. So let's authenticate and let the agent know who where. So that's okay. Yeah, keep going. I'll apply it. So, well, I'll try to sing with Patrick here. Yeah, this is based standard. I think you saw this in several workshops already just today and imagine several times in the last weeks. But yeah, we are in the Brazil AI SDKs. We will introduce the Get Stock Price tool and later the authentication part. So let's go for the simple thing. This guy's Patrick is cheating because he calls everything is touched. It won't be that easy for you guys. Rest assured that let's try it again. It's going to say rest assured all of the code that's here is in the stash. You don't have to worry about that. Let's go back to the chat box and let's ask again about prices. Do you guys want us to try to follow along? Okay. Yeah, that's hard, right? Let's let's let's complete everything, right? Yeah, okay. Yeah, good. Who call? You can tell it's the first time we run. All right, so let's let's let's make an actual or let's start with a trading questions or at least get info questions about it. Okay, cool. So now we've got the chat box and the Asian Connected to the upstream AI. Yeah, it's in this case is a public service is a public endpoint so no authentication as the decision was required. Right. Let's try. So let's let's move along. Okay. There are more info in that page, but yeah, no, no, no, it's okay. I was going to say that let's go back to the kind of important stuff. Okay. All right, what happens if we want to read not public data from the upstream service, but personalized data. So data that I as a resource owner, oh, in this case is we are going to use a token board. So basically when when we locked in, can you go back to the chat box? Yeah, yeah, yeah. So so far we didn't go through any login process. So there is no who I am or anything like so it's just a anonymous session so far. But at some point we will log in. We will log in in the Asian IDP. Yeah, right. And but that will give us a relationship a trust relationship between us and the Asian alone. We need to go beyond that. We need to establish a relationship also. It's kind of a three way thing. It's us is the upstream service and the Asian. So we need to establish this triangle relationship, right? We do that. We will do that through token board. We will first authenticate in the Asian doubt in exchange while issue an ID token and access token. An access token that basically authorizes us to use the Asian alone. But we can we talk about we can use once we establish the third relationship. We can use that access token to exchange to exchange it by an app stream access token. And that's what token board does. What it does is once we connect our upstream app in this case, the demo trade app, our data will start storing the refresh token and dealing with the issues of the access token. So we store the first token, we store the access token for us, long as it until expires and every time the agent needs to access this data, he runs the refresh token grant to obtain an access token. And that is issued back to the Asian. So and yeah, yeah, that's more or less to grab. Yeah, yeah, jump in. So yes, it's also going to show just adding the basic off for your user and and then then adding on these these token vault requests from the so SDK code here kind of walks you through like the sign up, the terraform, all of the tenant setup so that you can start to use these services, right, so that you can access token vaults so you can start using identity with providers. This is a very new feature set with some of these features. So you'll you'll notice like in some of our configuration, you're enabling a connected accounts feature with our new my account API, you're you know setting up grant types for your client application, your agent application, and you're configuring your LIDC connection. So yeah, let's keep moving and then we can kind of show the tenant. But these are kind of the steps we can apply to just add basic identity and yeah, I'll turn to you while I'm doing that. Yeah, still they are in all these steps are there references, links, everything you need. It's amazing when you want to do this later or at home. All right, so let's try to be so at this point what we're going to do is bring the login button to the agent. Yeah, just kind of show what that looks like. Yeah, so route. Yeah, so we use all data SDK for NICS that provides a mirrorware and a wrapper for a route. Sorry, one second. Yeah, I think it's that. Oh, it's complaining. Sorry, conflicts. There we go. Okay, there we go. Yeah, you change. Isn't it intimidating? But it's because it's dealing with a connected account. I think we are in the process of simply finding that in the SDK. Way more. But yeah, this is the next year's route for the chat. Yeah, so we've taken the page that has the chat client. So it's just your standard NICS page. And yeah, this is our wrapper which then makes totally like forces login or gives you a redirect. Yeah, yes, yes, yes, or does this fit in? This is an embedded agent within the next app. So yes, this chatbot is an embedded agent and we'll show other external agents. You do is have the existing deployment with additional components. You're sharing with me right now. Yes, yes, yeah, and what's out of the box? Yeah, so it's really these wrappers from the SDK. Which wrap an endpoint, whether it's a page route or something else. So yeah, then this is pretty standard with like our next JS SDK now. We established a session. So yeah, I'll show login, but there's really not a lot of magic here. We are however requesting this new connected accounts to see if you have a federated connection. So that's kind of the confusing part here because like, you know, the old school hot zero flows would not have that. Like, you know, we wouldn't be requesting upstream providers in many cases or other APIs. But in this case, yes, we are using a federated provider. And so yeah, it's a little more contrabagous. And yeah, we're creating a client there. You can kind of see the OIDC options we're providing, which are, you know, are specific for OIDC. And then this connect account endpoint is new. That's going to enable our new connected accounts API for managing all of your accounts. I think that's, yeah, so let me show that and kind of, yeah, go for it. Okay. That was code. I think, yeah, let me restart it. All right. Okay. Let's try it again. Yeah. Renate. It's awesome. I'm going to sign out and sign in. So we sign out. So at this point, it is absolutely you want to place a login button or whatever login UX is switched with you. In this case, just simply fire if you try to access the URL, it will just come through with a login screen right away. So we log in now. And this point, we are, well, we just show, but we are going to the upstream IDP. Yeah. So using just one credentials. And then, at least now, yeah, it knows that I've got a session. And who I am, let's see. So it got the profile from the IDP. It load that to the context. So now it knows who you want. Yeah. And in this big, just application, like this is also the same identity that's, I'm sorry, that's linked with the stock trader. Sorry. Yeah. This dashboard. So, yeah, your identities are now linked between, you know, these applications you're using an upstream provider. And you also see shortly that they'll be linked with your MCP tools as well. So, okay. So we've got identity for, we've got login. We've got an embedded agent running locally. What else do we want to talk about in the stepper? We ready to go on. Okay. So in our school, I am, but he doesn't know what I own. What is that? He doesn't have access to the trading service resources that I own. And so if you go back to the, yeah, demonstrate that out, one sec. Yeah. This one. Yes. So my balance is 10k. I've got these recent orders. Yeah. So once with what? So how can we give the agent access to all these things? Yeah. So the first step is as we said earlier, we need to connect the two accounts. So even if we are using the same credentials, we still didn't say explicitly or the user didn't said explicitly to the agent, a, I know I want you to know who I am, but I didn't give you permissions to access my account yet. So that's the step you are doing. We are connected to the accounts. That's when we promptly use it with these extra permissions that the agent needs, these extra scopes. All right. And that's when the relationship is established. So now the agent knows that I have access to these accounts with that exact permissions. Nothing more, nothing else. Yeah. Yep. And yeah. So next, I think it's just adding some tools, which can now leverage this account. So I'm going to jump into portfolio tools. And this is getting into that token exchange. And yeah, now we can start to ask more pertinquent queries. We can say, can you view my portfolio? Yeah. We're not going to give you access yet to create orders. That will be the next pieces. But yes, this kind of shows how our SDK models getting an access token for another connection, what upstream, how to leverage shared tools and typescript. I think what's really nice here is that these tools can be versatile. They can be shared between whether it's an agent tool or an MCP tool. Hopefully your framework has, you know, typescript support. That's also a really nice capability tool organization. And so yeah, if you want to keep going, I'm going to add the tools. Awesome. So the same as the same, the first step we did, we are going to load a key to the agent and new tool. So far, local tools, we will get to, we will get to into the MCP part, but it is a native tool that it does a simple HTTP request to the service. But the tool, we'll have a, so we can show. Yeah, sorry. So one of the other things that we provide in our SDK is this how we connect these two with the authorization part and authentication part. The tools basically again. So, so, the tool, yeah, not the tool, again, the auto, to show the, this one, tools or the get before you tool. Yeah, yeah, going. Yeah, sorry. So at some point, we create with a client and in the handler. Yeah, so yeah, just a get with include history, you know, query, brand, option, optional, addition there. Pretty straightforward. Yeah, I call once you have a client and the token, but yeah, the sweet sauce is the, you know, we can now leverage this get access token for connection really easily in our SDK. So yeah, let me show that. Yeah, it's everything it's organized. That's what I wanted to show. So our SDK for YT, you provide the connection. In case of the upstream name that is represented in your tenant. And that's what does all the dance with the token. I'll say, I'll say, my fourth audio. Oh, sorry. So we've got an agent with access to our data, so in our school, but also has access to what I have. I have to do access. It's up to you, obviously, that the tool implemented, but at least, that already knows exactly what we have. Okay. Okay. So so we have portfolio tools, which is great. I didn't show the scopes, but yeah, rest assured that like I'm not sure the MCPC are really quickly, so kind of what we've scaffolded and modeled. And then this may help with some of the questions, but yeah, here's the MCPC server, which we've modeled as an API. And we have scopes around accessing the MCPC server. We've kind of modeled those the same way as our upstream API. So let's see, permissions. We've got scopes around reading trades, reading our portfolio. And yeah, those are reference in those tools in the meta. That wasn't abundantly clear, but yes, we are representing those as like scoped permissions. Yes. If you work trade up for the volume, these are very applications specific. Yes. Yes. So how would it know what they are mean in the context of that application? You can take that one. What do you mean? So this app is a stock trading app. So the word trade app, which will have very specific meaning here. Yes. But I couldn't have another app where the word trade, or the word portfolio, maybe it's like a project management app, which will you would mean something else? Yeah. So how does it identify the meaning of the permissions? Let me take it. I think I understand, but at the end of the day, it's the upstream service that sets rules. Right? So if you want to access my resources, I need an access token with this scope. Otherwise, we'll reject your request. It doesn't matter if you're a nation, or if you're not just traditional rest type of app. And that's really that you as an implementer of the agent, you know that in advance. You know, if you are connected to an upstream, you know what's the shape of the request and what's the authorization layer that I need to implement. You can model your scopes as you want in your local tenant, but at the end of the day, the translation, this scopes to the upstream should be done. So you can tell. So what do I do that? It's in the connection. Yeah. Would you find the connection? Yeah. Yeah, so that the enterprise connection here to our upstream is here. And yeah, you can kind of see we're requesting those scopes from the upstream tenant. And it also, in this case, has those steps modeled around the stock API. So yeah. So these folks are getting on that service. Yes. So this comes out exactly. It's most likely publicly available or it's something that is part of the contract between you and the upstream. And that's exactly what the user will go into see on the front that you saw in the moment that they connect the account. Exactly. So we are here to simplify. We use the same names, but it could be different. It could be different scopes. The translation happens on talk and both. Yeah. And I should also worth mentioning, we model roles differently, right? Like around personas or their identities. Scopes are really around the API access. So if you're looking to kind of model more around the role, yeah, definitely check out FGA. We have role-based access controls, which you can apply around tools as well or around pages. But this is more just fine-grained access around an API. So all right, let's keep going. Yes. Yeah. A lot of this is very new. But connections has been around forever. But the purpose, and actually that's the name we chose, the purpose of a connection. We create a new one, which is stockable. All right, we're still doing pretty good on time, but yeah, it's okay, ready to jump into MCP. Yes. Any questions so far? Can you kind of switch in topics here? I wanted to ask you. Yeah. Similar to your question, the scope you can probably be able to get them from the well-known no idea is like that hard. It's a common way to get to use the right stuff. We fetch them. Yeah. Yes. Yes. Yes, exactly. So yeah, that's you've jumped right into the next flow. And yeah, so we are trained implement the current spec with MCP now. And that's kind of the next part of the exercise is adding the well-known protected resource metadata and point. And yeah, so we've been testing this with a lot of providers recently. And recently, we just EA our DCR feature like this week. But yeah, this flow is a little more involved right, because the MCP server becomes a client of the agent. And we're going to show how we model that in the versatile code. And you can see like all of the steps. There's obviously more involved. But it's important because we're actually securing MCP resources and tools. And kind of doing it in a granular way. But also enabling dynamic registration with many providers. So yeah, we'll showcase that towards the end here. Yeah, I can probably fire this up if you want. Yep, kind of see it first. So this kind of show, maybe I'll talk to you a little bit of this. This kind of shows some of the middleware. And how we apply like scope verification on the MCP server itself. And how we expose metadata. So yeah, that's exactly what you're alluding to. It's like we we advertise the supported scopes. When you go to register in that part of the flow and then, yeah, further down, I think it's in the transport. When we actually construct. So yeah, this is just more helpers. So it's like, you know, creating middleware to verify a JWT. We're still, you know, still a bearer token. Public private key encryption. But yeah, we reference those libraries. We have a lot of shared libraries for doing these things now. And then yeah, another important mention here is this is where we introduced this custom API client. And maybe I can show. So this is a separate client that we've modeled in this demonstration. You could really create any number of API clients. If you want to model them more independently or how you want to build your stack. But yeah, we've modeled this as a linked client, which is also a new feature, not zero. So now we can actually link APIs to clients and model them as basically you can think of them as an agent client or an MCP server client. So that's a really nice new feature. Those are now linked. And we have APIs support for those as well. So yeah, you can see like constructing an API client with the MCP server client ID and secret. And yeah, I'll run that in just a second. I want to see if this. So this is again, like monitoring these shared tools. So we've taken this like stock tool, portfolio tool from the agent over to the MCP server now. So we can expose it from there as well. And then the registration of the tools. And then yeah, this is where we create the transport. So this is where we create the MCPs endpoint and contract the server. And yeah, that's where we invoke our middleware. And so yeah, let me show that. And yeah, I don't have anything else. Yeah, so in this case, to add a certain attempt to show the whole journey, we decided to create the MCP as part of this workshop. But it could also be that you get your upstream MCP, not that you are building an MCP. But you still need to authorize to that, right? So in both cases, the session works. So it's not that we wanted to show both ends. So that's why there's so many. So so much code in that page is just because it's part of it is the actual MCP server. So I've unstashed all the changes in this that I just showed. And yes, like this is basically what's going to give us the MCP tools. So I mean, I will start this. All right. So yeah, when we turn this to the client, so in this case, in this the same next year server that the agent is running, it's where the MCP is served. But it's up to you which is your architecture, but same content applied. So I'm going to say yes, yeah, go for it. So you can try that, but it will take a no effect because the fact that you are asking scopes that are not part of the connection would be very nor or rejected. So it's very just ignore that. Yeah, it depends on the upstream, but yeah. So this scopes that are not part, correct me from going on, but it will not. Scopes that are not part of the connection can never end up in the access token. That's right. That's right. Right. So I think our policy most of the times is using what we don't recognize. So you just you will get an access token with value scopes, but not the one you try to inject. And also I don't think, now that you mention, I don't think we expose the out part to the LLM, meaning we expose the tool and we grab the tool, but the authorization happened before the tool execution. So I don't think the LLM will have any influence in what exactly, but I'm not saying it's not possible because many ways to do many things. But either way, even in our end, anything that we don't recognize shouldn't end up in an access token. Because we mean that the app will actually recognize what connections you have before it asks your instruction over to have an empty access key. That's right. Yes. So when you try to execute the tool, so the tool would say, okay, I need an access token because I need to do an API call. It's our grapple or our SDK tools that provide this access token to the tool. It's not the tool on command to the end from the LLM. That runs the authorization request. Let me say it's just all-fashioned code. It's not LLM. Okay. So now I'm going to show kind of step-per-step the DCR. So yeah, it's our I'm using MCP inspector, a common tool, and we'll show some others. But yeah, this will kind of just show now we can actually target that MCP server directly, you know, running on the same server under slash MCP now. So yeah, this will show our a lot flow and DCR happening. So we'll continue. This is a disclaimer. Open the CR is the same. But you see me as in early access, and I don't think we will. Yeah. That's some concerns about how this will scale. Yes. But there are other aspects for me that I think we'd better in this scenario. Absolutely. I agree. But yeah, you can see the protected resource metadata coming back, so we have the well-known endpoint. You can see the scope supported, and then we make a request to the authorization server. That returns more information about our tenant and no additional scopes out of the authorized. So yeah, I'm going to jump through that. And then we get a registration call. So now we're going to get a new client just for testing purposes with the MCP server. So yeah, now we're going to get, I believe this is PKCE. It's our authorization code flow with pre-key code exchange. So yeah, it's standard all-seeroflow, but it also works well with MCP. So I'm going to copy this. Okay. So yeah, now it's going to prompt me and give me an authorization code. And at the end of the line here, we should get an access token. So which is great. So now we can access the MCP server with these scopes from anywhere. That's the great thing. So now I'm going to hit connect. Let's see if we can get some tools. Yes. So now we have access to our portfolio. And you know, our right-and-any tools kind of access between the same upstream stock API. So yeah. And you want to add anything here, goes. Free-go. No, free-go. No, any question? Sorry. Yeah. That's good. Yeah. Sure. Okay. So yeah, this is really the most involved part of this flow. I'm going to show the Claude. So I've actually deployed it if you want to play around. And yeah, so that's really the most involved part of the MCP, rather. And yeah, I think we're hidden time. So let's go into the using goth. That's all right. Okay. Do you want to still driving the coding? Absolutely. All right. So we said that earlier. The fact that the agent has access to our resources, it doesn't mean that you should do anything in any time without my supervision. Right? I said this all the time. We don't want an hallucinating agent buying a stock in the middle of the night without my permission. Yeah. So that's where part of our, the bundle is provided a simple way. And I think this way to the agent to reach out the user and get the approval for risk cooperation. In this case, we can see their place and order either by yourself. A risk operation is something that we as a developer association define is up to us. So in this case, what we are going to do is we are, we are, we are, we'll bring the creator to but with some conditions. Yes. So that's conditions would be that before running the creator of the tool, we will call back channel off. That's the SDK name for for the else sync off. We will obtain an access token that contains exactly what the user is up. So let me go back. So we will create this request to back channel with the details, with the details of the transaction. In this case, it will be exactly the single I'm buying or selling quantity and the price for the user to see that in the screen, most likely not out of plan device. See that and approve that. And only when that is approved, we will place the order. Yeah. For that, in this case, in the sample, we will use Guardian. It's our NFA application. It's out of the box application you can use, you can install and use. But also we support Guardian SDK in case you want to implement your own. Not sure the user. Yeah. So, for the agent to be able to reach out the user, for this channel in particular, the user needs to be enrolled on NFA. There are several mechanisms to do that. Just for the workshop, we show you the backdoor. But it depends on the UAX, how you it could be in sign up, it could be a step up kind of thing, I don't know. It's up to you. But we need to enroll. So you will find using the docs, but you will find a way to send an email that contains all these instructions to enroll. So once we enroll, we can add this little helper here that just basically forwards the off to the UAX SDK. Let me undo and reapply here. Am I going faster than you? No, it's perfect. Catching up. All right. So in a second, I will show you exactly what we are going to send in this authorization. All right. So we can see. So I think it was in Austria. We add the... Yeah. So here is the helper. It's just a wrapper just for wrap the headers and all the stuff. But basically it's again this. It's line of code in our SDK. It's what we send and what we'll run all these steps internally. Show the tool. It will wait for the user response. So it's basically an sync operation. And when the user responds, the agent can presume. It's in tools. Yeah. This one too. Yeah. This one. So here we are creating a new client with... So we're specifying what we need in the authorization details. So we can provide that rich authorization request detail when the authorization request comes in. We're using this custom API client. In this case that we've already created, you could create others. But yes, we're creating a custom API client to then perform the back channel request. And then, yeah, in this case, it waits. You could do a number of things. You could pull. There's other mechanisms here. But yes, in this case for simplicity sake, we wait for the verification. So let me give this a go. All right. Okay. So we run again. Sort the chat box agent. We'll go back here. All right. So now we can ask to... I don't know. Yeah. Wait for another. What is it? Wain? Yeah. For example. Victitious stocks. Yeah. So in this case, yeah. Go ahead. Yes. Yes. Yes. Yes. I'm happy to share that towards the... Do you want me to share now? Or later? Okay. Yes. Yes. We do have a final state branch. Yes. In this case, the agent is instructed to inform the user that this is going to happen. So this is not yet the authorization request. It's just heads up the A. You're going to receive a notification. It's okay. It's just a really silly system from the client. So you can proceed. Then... Yeah, waiting. Hang on. Should be connected. Let's see. Oh. Okay. One minute. Give me a second. You want to leave it like a little time? Yeah. Turn that off. Oh, I'm sorry. Let me try again. Let's see. Yeah. Refreshing. Refreshing. Apart from ocean of notifications, we also support email as a download. Nope. And more channels, we'll be implementing more channels through each other. Yeah. Maybe I need to restart the application. in the organization. Is it my heart that the free authorized working users? In the Eurasian. Yeah, I mean, I guess it's up to you how you manage the session with Eurasian. No, I'm sure no one else can engage with the same engine. Yeah. Yeah. Can I be the free authorized agent for certain access? But also for the authorized who can use an app. Just don't understand what all the different use cases around that. Yeah, but this is kind of up to you how you manage your sessions and permissions to access the app as a resource. But once you establish that, it's yes, you can use the service and the policy is at one. At the end, I don't know if I'll follow the test. We can translate already. I approved it. So yeah, I had to reconnect here on this network. So, okay, let me try one more time. It did come in. Just an example for this agent saying, did it say that the agent was asking if it's allowed to go to that website. So I just want to make sure that the agent failed. Okay. So that's what I know about websites. That's what I meant about three particular sites. When you say website, you say that the service. We were threatened API or certain tools. Just trying to see what if anything could be on the event. Because right now the application has happened as interactive. Yes. So I'm just saying it can be, you know. I see. Yeah. So, you know, this is how I see. I know. I'm not. I'm not having access to any of the person. I understand. I understand now. I understand now. So yeah, I had similar concerns. I'm not in product. Sorry. But yeah, so imagine that your interface is not a chat box. It's like a task runner kind of thing. So I guess what I would implement as an engineer is I would attach my identity or at least a identifier of the user, the subject to that task in my database. So I enter the agent. I set up a task and I say, okay. I want to, I don't know, find me a good deal or advise me or buy Wayne stocks when it's below 70. Yeah. It could be a task, right? I think that task is modeled in your system, right? It has to be modeled somehow. I don't know if it's prompt and idea of the user. And that thing, that's when you establish that. So, and we use the user. That is the subject. It's what we use to identify if the user has a connection to that account. You know, so I need this account, this user to have disconnected this. I understand. And then I will only. And then it has an identity for the agent because I want to appreciate the connection of someone agent or comment from the user. But that's a thing. You are in our auth. The event is an agent performing the request to the service. It's in my account. So what I need. So. But I want to know for the app. So I want to differentiate. Is the event agent goes off? I want to know that agent goes off, right? So I want to know. Yeah, you can. You can do it. Yes. So in that case, because the agent is the client, your access token will have an authorization party. That's a claim that identify not not the user, but who is. Who the user is delegating the access to. And that's where you can say, okay, this is my ID as an agent. This is my subject. So I can now exactly, okay, this agent is actually going to be having these users. And you can go any policy on that that you need. Yeah. That's all. That's nothing new. It's been around forever. But now I understand. Yes. Also, yeah, I wanted to show kind of logs and also just. We did show the exchange in the last example for accessing portfolio, but this is the actual AC and cost see the exchange, which is slightly different in our logs. But I think it also kind of ties it together really well. And it shows, you know, I'm going to show like what an actual token payload it looks like. Again, fictitious and these tokens are not going to give you my. So this is the details I was talking about. We use an extension of all its reach authorization request. It's a specification. And basically we can describe exactly whether user is giving them center. And that gets record in the access. In a real scenario, most likely the resource server will want to verify that. But yeah, that's how to the stock that out of our. But yeah, that's the notification to. So yeah, it looks like. So yeah, that's what it looked like on my phone actually when I actually connected it to the network. And I got a slew of notifications. One of the challenges with reach authorization request is that the object is free for you. You can put anything you want. And that complicates the in terms of rendering that request. To solve that, we created a schema. So we support on on one schema is flexible enough to give you any opportunity to display anything. But it's known and we can it helps for our up in our case, but also in your ups if you are developing yours to render this dynamic. So our garden that up is able to render any details. We provide this schema for you. Cool. Good. Right. Awesome. So that's a little bit about our new asynchronous authorization features. Last piece and then kind of open up more for discussion. And yeah, I know we'll have a little bit of time. But I just want to quickly show and kind of practice with like some of the integrations which are testing. This is very beta and shipped very recently. But yeah, this is using that DCR flow. I'm kind of showing how again, how we did it with the inspector but also with Claude Code or with the chat. I'm sorry, the open API app SDK. So this is just kind of what I'm not going to do this now. I'm not sure it on time, but obviously like we can deploy this to Bersel. I'm using an upstash database, where I just database for handling the state on the MCP server side. And yeah, you can get running pretty quickly on Bersel. So you can take this agent and this MCP server and start sharing these tools, bring your tools right anywhere. So, yeah, so I'm going to show, I guess just, I've got a deployment that I mentioned earlier. I'll target that and I'll DCR with my deployment. Ironically, it's also linked to the same identity provider. So I'll get back my same information which is nice. And then I'll show kind of how in Claude Code this works. I'm going to skip over chat, GPT, app SDK. There is an integration that is starting to work here. There's some configurations needed, so reach out and let's talk if you need this today. But yeah, it will be pretty much readily available in the very near future. So we do have some integrations today that we've tested. But yes, this kind of gives you a rough overview of how you can quickly bring those tools to chat GPT. So yeah, I'm going to gloss through that. This is just me showing, like, oh, yes, I've connected it in GPT and I can access my tools there. Yeah, let me go ahead and wow, if you want to talk to the list and where that I will show kind of getting a new client with my deployed instance and then integrating it in Claude Code. Yeah, is this just to showcase that the client, the MCP client, should also run the same policies or policies that all clients should run the same. So should identify, authenticate me and authorize the appreciation, the same authorization policies should happen. So in this case, we embedded the MCP as part of the server, but in this case Patrick deployed that for us. Disconnect. So something we did before in this case, this is an production. Yeah, exactly. As you can see, it's asking for my application and he got an access token with the scopes that we requested. All right, so we're going to pull up Claude and yeah, we can jump into a little caught. If you've had the MCP. So yeah, I've got a command in the readney here that's in the final. All right. And then yeah, I need to replace the token. I'll save once. So in this case, I am going to use my inspectors token and Claude does support authentication. However, there is an open issue right now about specifying scopes. So yeah, I'm just going to use my inspectors access token. But yeah, you'll see you'll see that with Claude and then Claude will still initiate. Let me show that. Unfortunately, the spec is pretty neat and all the clients implement the same way. So yeah, that's, I expect that to stabilize. There's no copy in this tool. No, okay. Okay. Once again, my token is not going to do the match these are fictitious trades. All right. Okay. Oh yeah. Same thing as before. We're going to start asking about what we got in the up to some surveys. Is it connected? Okay. Okay. So maybe I sometimes I have to restart it. I don't know why. Okay. Now let's see. No. Let me try one somewhere here. That did not work. Yeah, I'm not seeing it. Okay. Claude ad. Yeah, it looks like it is there. Let's see. Can you mean time more questions? Yeah. How do I question before? I think I get the review when you're in a non-zero restaurant. Maybe the context here is everything in that. Or let's say your consumer or something. Maybe this whole flow will be at the case. Thinking that if you are in opta 10, you're using opta in your workspace. How do the two work together? Or is this thing also going to be available on the opta site? No. I think the idea that's called me, I'm going to I don't know exactly. So 100%. But what I think it is is we are going to create some sort of breach. That you can apply the same policies as opta as an employee to agents. And restrict those accesses to those services as you would do with 7.0. That's where I start your question, Marles. Kind of here. Yeah. So it also how does this concept of work together? Because it seems like a feature of ontino which is one of the things. It is. What are on my opta? Yeah, it is. It is a separate part. But as far as I know, we work together on products. But yeah, we can connect later if you want. I can dig into the box. Yeah, most likely that's. What I'm doing around here. Do you need to do this Claude command? Don't you have to run it outside the Claude session? Maybe. I don't know. Oh, in the terminal. Okay. Yeah, let's try that. Anything else? Yeah. It seems like if I were to point at agent one way I can start is just to use the user's croquet on behalf of the agent is actually as the agent itself. So what do you feel like to see advantage of this thing? Agent identity? What are the features that you have? So when you say I can just pass or you authenticate the user and just forward the access token to the agent somehow or that's the. Don't do that, please. So the access tokens are meant to pass. It will be of intensive of operability. It will be a cumbersome because access tokens will expire eventually. So at some point you will need to reach out the user again. Okay, login and do all the dance again. So how autonomous your agent will be in that scenario? So that's kind of what we try to solve. So we establish that connection, that relationship and we take care of this nasty complex part of refreshing tokens, storing tokens. And yeah, all the scope step up. Okay, so finally got it working here. I think that is like some of the interactions I might make with the agent or could save the chat assistant. And so whenever the agent is taking action, I'm. Not necessarily. As for some of the examples we're talking about before imagine like a task runner kind of thing. Log in, you have the identity, you have a like a kind of traditional dashboard where you list your connectable apps, Slack, Gmail, Google Calendar, whatever. And they use it just once. So once the these are connected, you give the Asian client. Not double code is the kind of agent client access to those apps. Every time so the user next time that connects to the chat, that's it. You don't need to run all this thing again. It's already done. It's the relationship has been established already. So the user will open the chat again. You don't need to do all this connecting scope, sproms, consent screens. That's it. That's all. Eventually can die. Depends on the policy of your upstream. So the first tokens may expire and that case, yes, you will need to deal with all. You need to reload again. You do that once on that. Yeah, so just an update was a finally able to send tax or my version of Claude, I guess. But yeah, I was able to off and kind of show. We went through the authentic eight screen and yeah, now I can access my same tools in a deployed instance. You can do this with several providers now, right? All of which any which support DC as as Carlos was saying, like any which support DCR, static client or pre-configured clients. And then yeah, soon to be client 80 metadata is the next spec I believe that's going to be implemented. So yeah, you'll have a lot of options to register new clients, new agents, and access your tools. Yeah, I don't know if there's anything else to return back to. Questions. Okay. I think that's it. Questions and feedback for whatever please reach out or. Yeah, yeah. Is here to like, the research that I showed that to his question is there a later branch? Yes. Yes, absolutely. And let me push that to his repository and let me show my final state now. And yeah, I'll pull that up and link it here. Also, yeah. Yeah, for the first time with the major release this week was like, we just shipped this like two days ago. So yeah. All right, okay. But yeah, the final state is in my branch here, finish state. And that should have all the applied changes. And I think I've like tweaked one of the like order history tools, but it's pretty straightforward. There's some other tools that are implemented there, but yeah, it's up to you. What you want to implement there. But yeah, can I, let's see, I don't know if I can, I can link this in the notes after. Yeah. And we'll make sure that you have this. I'll probably actually push it to our upstream workshop branch. And yeah, it's a little disclaimer, the virtual bar. Well, it can suffer some disruptions as we develop more things. So yeah, thank you. All right. Thank you. Awesome. Thank you.