Jeroen de Kruijf - Building Trustworthy AI Authentication & Authorization for AI Agents with Auth0

In this session, Yun Grav discusses the complexities involved in building trustworthy AI applications, particularly in the context of agentic AI. The speaker highlights the transition from basic large language models to more sophisticated agentic AI systems that can execute tasks and interact with various APIs on behalf of users. He emphasizes the importance of addressing security risks associated with these technologies, such as prompt injection, sensitive data leaks, and excessive agency. Grav outlines best practices for authentication, authorization, and managing access tokens effectively to minimize vulnerabilities. He also introduces key frameworks and systems, including the Open FGA for fine-grained access control, as well as demonstrating a practical example of a banking assistant powered by these concepts.

That's super. >> Yeah. All right. Well, hello everyone. My name is Yun Grav. Uh I'm a solution engineer at Alzero and um today I want to talk a little bit about building trustworthy AI. I know I'm not the first one to talk about this today and I sure as hell won't be the last. Uh but there's a good good reason for that and that's because uh we

see a fundamental shift in the way we approach software and the way we communicate with our own businesses and with third party tooling. So how is this fundamental change happening? Well, of course, a couple of years ago, we saw the massive adoption of large language models, things like GPT, Gemini, CL. And at first, these were just fancy chat bots. You know, they're trained on a whole lot

of data. You can ask them a question and they will give you a summarized response back. Nowadays, especially the last couple of years, we see a massive shift happening towards agentic AI. Agentic AI can turn any human language into a programming language. It can help us eliminate repetitive tasks across multiple uh tools and APIs. It can run autonomously um with with or without user interaction. Um and

it it can coordinate multiflow uh work workflows. So this is what a common modern argentic AI architecture looks like. You have the user prompt uh that's going to ask something like show me this specific stock price. You have an agent orchestrator tool that is going to list the tools available to the agent and provide the one that it needs at that moment. uh tool execution proceeds. Uh

the third party tooling is either uh performing an action or retrieving data and the application then returns to the result and shows it to the user. This opens up a whole new world of possibilities but it also opens up a whole new world of risks. So what about security? Since the whole digital world is fundamentally changing, we also need to rethink security. We need to rethink what

it means to be authenticated and what it means to be authorized. And that's because it now don't won't just be people interacting with our software. It will be agents on behalf of those people. So this whole new world of risk is greatly shown in the OASP LLM top 10. OASP is of course a open source project that researches specific security topics. Um and out of this list,

these are the 10 most um uh urgent risks and important ones that we see around large language models. Things like prompt injection where attackers use uh special prompts to make it ignore previous instructions. Uh sensitive information disclosure where an LLM can unintentionally leak data uh from its training set. uh supply chain attacks where uh the LLM is compromised through ex its external dependencies, data model poisoning where

attackers corrupt the trading data to create security holes or biases. Um improper output handling where the LLM output is not properly checked uh creating vulnerabilities when used by other systems. Excessive agency where the LLM is given too much power leading to unforeseen and possibly harmful actions. system prompt leakage where um the LLM is tricked into exposing it own secret Factor and embedding weaknesses where an uh attackers

exploit the way LLM represents data to discover and abuse flaws. Misinformation. I think this is the one the one the most commonly known also outside of the developer community where an LLM can spread very convincing yet false information. And of course we have unbounded consumption where an large language model can use too much um you too many resources leading to either service disruptions or uh high operational

costs. Out of these a couple are inherent large language model and AI issues. These are not within the scope of a general uh AI app developer. Some of these issues though do arise within agentic AI applications and do need your utmost attention when building an application like this to make sure you're not vulnerable. Today I will be focusing on these two topics since they have a very

huge attack surface and can have a major impact on your business uh and on its users if uh done incorrectly. I will be showing some code examples of uh tools that we offer. Um and at the end if times allows that I have a simple demo I can uh can show. So what are the pillars of a secure AI application right? So how can we approach this

new form of identity to secure an application like this? There are four main engineering problems you need to face. This is first off with authentication. The AI needs to know who the user is. I won't focus too much on that today since I'm in front of a lot of front-end developers. So, I hope you already know. But, uh, what I'm I am going to focus on is

uh that the AI needs to call APIs on the user's behalf. So, it's going to need access to access tokens. Um, the AI might want to do something sensitive. Uh so you want some form of async user interaction in some cases and I think most importantly you need a good authorization model behind this agent to make sure that it considers the user's permissions before either performing an

action or returning data. So since the after the user is authenticated and you now want your agent to do something on your user's behalf uh in some third party software, you have to understand the right way to do this. And to understand this, we need to know what tool calling is. So when you build an agent, you basically provide the large language model with a list of

tools it can use. Uh and it's basically a schema of the functions that it's allowed to run. The LLM of course itself doesn't execute the code. Uh it just replies and says hey based on this user's prompt I need uh the Google calendar tool for example with these parameters. So it's your own underlying code your own back end that is supposed to execute the API call. And

this is the exo exact moment that you're going to need the access token. Right? You want just in time access. The agent shouldn't hold the token. uh the execution layer should fetch the token right before the request takes place. Why? Well, an approach we see some developers take uh is that they um the user logs in with Google for example, they grab the oath access token and

the refresh token. They hand them over to the agent memory or the app's local state. And this can have terrible consequences. And there are two main reasons for this. And that's both security and state management. From a security perspective, uh especially when you expose tokens to your agents memory, uh as the OAS top 10 LM list clearly shows, LLMs are suscept uh susceptible to um things like

prompt injection where they can convince the the agent or the LLM to start showing access tokens. Um you can imagine that if an thread actor gets access to some such an agent and it starts exposing its access tokens uh this is a a terrible uh situation um and they can have access to the external accounts. So secondly you you don't want to have to do the state

management especially if you're going to build an agent which we see more and more that have a lot of third party integrations. This means that you're going to have to manage all of these uh access tokens are inherently uh time bound most of the time. So this means you need also to store those refresh tokens. You need to keep track of the these access tokens and make

sure they stay active and up to date. To solve this, we've uh come up with a feature called Alzero token vault. Uh and what this does is that instead of your application doing these ooth handshakes, storing refresh tokens uh in your database, writing custom grunt jobs to refresh these tokens, you can abstract this away. So with token vault, the access tokens are stored at the identity provider

level. So when your agent when your agent's execution layer is actually uh or needs a to call a specific API, it simply makes a serverside request to the token vault saying hey uh I need a connection to this user's GitHub account for example. Um default then checks if the token is still valid, refreshes it if needed and it will return a shortlived federated token for that specific

use case. This means you can use the token in your execution layer dispose of it right away. uh which means you don't have to store it on your end for too long uh preventing a lot of these types of leakages. so this also means you have you you don't have to worry about the token handling yourself. So this is what it looks like codewise. Um, so instead

of having to first check if the token is still active, refreshing the token if needed, you can just call the uh get access token for connection uh endpoint in the Ozero SDK and you will get an access token for that specific thing you're trying to do. You can do the thing you're trying to do and then get rid of the token. So less code and zero token

handling. All right. like Reag the previous uh guy already told for some situations you want to make sure that what the agent is trying to do is actually what the user wants the agent to do. Um and if you're working with a front end like you have a a chat window which are often most uh agent applications you can ask it in the application itself but in

some cases these agents might run on the background. You can ask an agent to do something and it will happily crunch some data for you. You're going to do something else and in about 20 minutes the agent is going to come back and say, "Hey, I have summarized all this information and now I want to perform this specific action." So this is where you want to implement

something like a human in the loop framework for actions that have real life consequences if done uh incorrectly like sending emails, purchasing products or booking appointments. Um a great way to do this is using oath 2.0 uh the o 2.0 extension called siba which is client initiated back channel Um and if you think about a standard oat flow like the authorization code flow for example um they

rely often on a browser. So you have a browser, the user clicks a button, they get redirected to an authentication page. After they're authenticated, they get returned back. And so that makes it a front channel flow. Um AI agents, like I said, can run autonomously. So they can run on a backend server with no immediate uh need for a u for an interface. SBA's specifically designed for

this use case where the where it's a back channel flow, right? So the agent's backend server is going to uh talk directly to the authorization server and it's going to say hey I need this user to approve this specific action. Um it's going to reach out via an outofband device something like a smartphone. Um, and if you combine it with another OOT standard which is called rich

authorization requests, you aren't just asking to approve something. You are actually providing context about what the agent is trying to do and to check if that's uh in line with the user's expectations. This is a example of what it looks like codewise. This is again using an odd zero SDK. So it basically functions as a sort of wrapper around your sensitive action. You call this function and

it will wait until the user either denies the request or approves it sending a contextual information about what the agent is trying to do. This one is simplified obviously. This one is just going to wait indefinitely until the user approves. So you might want to add something like timeout but you get the idea. lastly, there's one more thing that's very important. That's the authorization part, right? So

how do you make sure the agent does not overreach the original user's permissions? So an inherent limitation of large language models are often that they are trained on public data. They often do not have hopefully a lot of private information about your specific use case. So if you're for example trying to build an agent for within your company to gather docs or to do certain specific actions

that are relevant to your uh to your specific use case, you have to provide it information on the fly. There's a very popular pattern used for this which is called rag retrieval augmented generation. And this is where you can enhance the initial prompt with your own information coming from either a CMS, a database or a factor store. Um, and you can provide this to back to the

LLM. The LLM can then based on that information that you're feeding it on the fly, perform a certain action and return a contextual response. This pattern itself does not inherently take into account a user's permissions, right? So you still need to make sure that the data that you're going to feed this LLM is specific for this specific user and does not go out of the bounds of

that specific use case. For smaller applications or smaller use cases, you could do something like role-based access control, right? So you can assign a user a specific role and based on that role, you can see specific information or get specific data. However, what we see in practice is that in a lot of the cases, this is way too coarse for something like an agentic application. They often

have access to a way a wider range of data uh with varying levels of uh of authorization like readonly uh commenter or edit editor whatever. So, this often requires a more fine grid solution. What you could do is implement relationship based access control uh or FGA which stands for fine grained authorization. I'm going to talk about open FGA today in particular which is an open- source variant

uh of FGA which we built which is free to use. Um so what it does it lets you uh control uh access at a granular level. So access can be granted per object by document or by hierarchy. Uh which is ideal for rax systems that have to access documents like uh from a file system or a CMS or a database. So you can use relationship based access

control for role based access control and attribute based access control use cases as well. But on top of that if in the future you're going to upscale or it's going to get more complex it's very scalable. So it will grow with your specific application. If you start off with something like rolebased access control, it can be very difficult to then build it to something that's more granular

when needed. how does this work? Um in FGA uh there are three main concepts which is the FGA store which is used to organize the models and tupils. You have a authorization model which is used to define the permission model of that specific system. And then you have relationship pupils which are either a base pupil or a triplet uh consisting of a user, a relationship and an

object. Um open FGA then comes with a couple of APIs. uh one is check which will just return true or false whether a specific object or a specific user has a specific relationship with an object. Um you have the list object endpoint which will return uh all objects with a given relationship uh that a user has a specified relationship with. And then you have the list user

request which returns all users of a given type that have a specific relationship with an sounds pretty complex um and it can get very complex but in essence it's not that difficult right so this is what an FGA model looks like this one is uh a very simple model to define different levels of permissions on documents u where users from different domains can have access to the

documents so first off you have the type definition of a document so this is the item you want to protect um it has a list of possible permissions like editor commenter uh uh viewer and um it can be assigned to either a specific user or a group of users. The group of users can be defined by assigning users to a specific domain. So you can say uh

it's a way to bundle users together. So you don't have to assign every permission to every specific user. You can also assign users to a specific domain. And then of course you have the user which is the the person you're actually trying to give access. Um in this type in this uh example it's called type user but you could also for example have a type like agent

if the agent needs to do something on its own. So this comes together in the bottom where you see a relationship tupil which is actually uh defining that user n is an editor of the document called new road map right so this is very flexible and this allows you for very fine grain uh control over your permissions. So you can use open FJ for this. So open

FJ is an open- source uh authorization system. It's it's built by Ozero and it's based on a very similar concept called uh Senzibar which is Google's authorization model which Google still uses for all its uh uh its larger products. If you think about it, you can really apply this to something like Google Drive where you have folders. If you have access to the top folder, you automatically

have access to all the folders under it. But you can also give specific access to a specific file in a folder, right? So it's very fine grained and you can give very specific uh authorization when needed. Uh we also offer a hosted version that is al zero FGA and this is where uh uptime redundancy and high availability is very important for use cases that require those specific

elements. So for the demo I built a little let's see I'm going to get my cursor over there. There it is. So what I built is a simple banking assistant agent in few I say built but I f coded it of course sue me. So, first I'm going to authenticate using Google. Um, and here we have the agent. And um, so the agent has has a couple

of tools listed, right? So, it has access to a couple of tools. In this case, I'm going to ask it to show me my accounts and it's going to happily return the accounts that I have few access to using ozero fa to determine what my uh uh what my permissions are. Um, so what I'm going to do now is I'm going to enroll myself in MFA. This

is where the SBA part comes in. Um, for this specific implementation, I chose to use um the Ozero Guardian application, which is an application we offer that supports push notifications. Uh, with SBA, we also have a Guardian SDK, which allows you to build your own uh uh notification system in either native applications. So we support things like uh iOS or or Android. Um we also support um

uh it in front end facing applications as well. I'm going to get to the application again. So now that I've uh enrolled myself, I'm now able to transfer money from one account to another. So, I'm going to ask the agent again to transfer 100 from my uh checking account to my credit card. As you can see, I'm a bit behind on my payments. So, um it's going

to send this request. It's first going to summarize if it understood it correctly on the front-facing side. Um we're going to say say yes, please continue. And then it's going to call that specific tool. That tool is protected using our SDK uh using SBA. It's going to send a push notification to my device also using that rich authorization request protocol that oat supports giving me the exact

thing the agent is trying to do in the application and the transfer can go right through. Now I can also be a little bit little bit cheeky. I know that my manager is not in the room today. So I'm going to try to transfer some money from my corporate credit card to my own to get a uh of my uh depth cleared. So, it's going to again

summarize first if it understood correctly what I'm And uh as cheeky as I am, I'm going to say yes. And then since I'm using al0 fga, it's going to check real time if I have that specific relation with that specific account. In this case, I don't. Thus, the request will fail. that was a very simple demo. Let's see. Uh if you want to build something like this

yourself, I have two QR codes here on the screen. Uh one is just for a quick start guide that's going to help you get started using Ozero uh for this specific use case. But the other QR code is for our virtual def cams. There are two scheduled. Uh one is just a general introduction to Alzero and what we do. Uh and the other uh one is a

specific agentic AI defam. So we are going to be there. We're going to walk you through what you can do to build such an application. It's actually very similar to the banking assistant that I built in few. And uh you can learn how to how you can protect that using both uh FGA token vault and uh and the uh authentication. All right. So yeah, that that's it.

Thank you very much for joining today.