Building Trustworthy AI Agents Through Modern Identity Control

Good morning. Good afternoon, everyone. I'm John Tolbert, Director of Cybersecurity Research at KuppingerCole, and I'm joined today by Michael Pattison of Okta.

Welcome, Michael. Welcome. Thank you. Our topic today is Building Trustworthy AI Agents Through Modern Identity Controls. So a bit of logistics info before we begin. Everybody's muted centrally, so there's no need to try to mute or unmute yourself. We're going to do two poll questions during the webinar, and we'll discuss at the end. You can enter questions at any time in the Livestorm Control Panel, and we encourage you to do so. And then lastly, we're recording the webinar, so both the recording and the slides will be available in a few days.

So I will start off and then turn it over to Michael, and we will do the poll results and the questions at the end. So I thought I'd begin by talking about AI agents and AI browsers, what they are, what they do, and no better place to start than with a definition, I think. It's always important to remember that AI, AI agents, it's all code. It's code that's designed to do tasks for you, in the case of agents, and even make decisions on behalf of users. And they can use different forms of AI.

They might include large language models, machine learning, natural language processing, to interact with the environment, and then process information they receive, and then to do specific things. The features included here, and I think it's important to distinguish between traditional philosophical or psychological definitions of perception, and reasoning, and planning, and what we mean in the AI world. So perception here is processing context that arrives, not necessarily, you know, responding to physical stimuli through the senses.

Same thing with reasoning, it's applying logic rules that have been, you know, programmed into the agent or the AI program. And then planning, what is that? That's going through a bunch of if-then rules.

Of course, there's memory, and memory can take the form of configuration files or preference files. And then ultimately, it's about the actions that the AI solution or agent can do on your or other user's behalf. So what are some of these actions that they can take?

Well, they can have context-aware task automation. I think a good example here would be like a document processing agent. It can be configured to go look on Monday morning at nine o'clock at various folders to see if files have been uploaded, and if so, then process those documents, summarize them, and send a report to the user who the agent is acting on the behalf of. We have natural language query resolution. I think this is one of the more helpful things where companies are building in natural language portals for, let's say, admins to be able to run queries against logs.

Certainly, it can be easier than doing log searches or using regular expression searches. It can certainly speed up investigations where needed. They can create personalized recommendations. Secure identity delegation is kind of a key conceptual component here. I think the emphasis is on secure, but in many cases, we're not quite there yet. These agents do have to be able to act on behalf of the user, so there are a lot of questions about how does that get implemented, how do permissions get transferred, what permissions are appropriate.

So, there's a lot of work that needs to be done in order to make sure that agents have identities and they are properly secured and not over permissioned. Autonomous form filling. Think about how browsers have, for quite a while, been able to save user information and then present that to web forms. This is a more sophisticated version of that. You can have multiple sets of information. You can even sort of pre-program what your consent management preferences are.

So, if you go to a website that has cookie pop-ups and questions related to what your preferences are, the AI agent can help sort of auto-fill that. There's anomaly detection and personal data use. It may be able to detect where your personal data may be used in a way that you don't agree with, which is related to privacy policy interpretation. As you all know, when we go to a website, maybe for the first time, or when terms of service change, there'll be an update to the privacy policy.

The agent can read that, summarize it, and present you as a user with a summary of what those changes are, and maybe even give it a risk score, whether or not you should accept those changes. Related to secure identity delegation, there's secure transaction authorization. In this case, I think of agents that are maybe procurement agents operating on behalf of a human procurement agent.

So, how much money do you want the agent to be able to spend on the behalf of your human procurement agent? Maybe you can tell the agent that I want it to go look at five websites once a month and find me the best deal for a certain widget that the company needs, and it's authorized to spend X number of dollars or euros to acquire that. Then there's also personal health monitoring and digital footprint minimization that the agents can assist with.

So, in a B2B context, what can agents do for you? Well, I think we've all encountered chatbots of one kind or another, help desk support agents, procurement agents I just described, or also financial advisor agents that can, maybe on the personal side, look at where to invest money, but also help manage corporate accounts. The document processing agent I mentioned already, there could be appointment scheduling agents for, let's say, doing sales appointments that can maybe look through your CRM system and help figure out when you might be able to meet with prospective contacts.

There are voice assistants and legal assistant agents. Again, those are agents that can help process information, let's say, in the legal context.

Of course, as we've probably all heard stories about some of the risks involved with hallucinations, which we'll get into more in a minute. So, I thought we should also distinguish between AI, LLMs, natural language processing, and agentic AI browsers. I won't read through the list, but there are some agentic AI browsers here. The key difference would be AI browsers have built-in AI agent capabilities that can do things like summarize the webpage you're reading or summarize multiple webpages and then help you answer questions that you might have about it.

But fully agentic AI browsers kind of try to take that one step farther by incorporating agent features, such as the ability to fill out those forms, of course, based on preference files that you've pre-populated and help manage consent. So, as you may know, AI is being used in IAM more broadly. I've tried to list out a few things here that I think are interesting. And where it's machine learning, I've sort of noted that in the dark font and LLM or NLP are things that are in the red font.

But, you know, we've been using machine learning for anomaly detection in cybersecurity for many, many years already, you know, both supervised and unsupervised machine learning detection models. And this is to simply be able to sort through the mountains of data that otherwise it would be impossible to. Just think about all the different kinds of malware that are out there, being able to sort through and figure out which ones are potentially dangerous.

So, that's just one example. ML for anomaly detection can also work on IAM systems to look at potentially anomalous or suspicious logins and then alert based on those. And that we have seen implemented in ITDR tools in the last few years as well. We have AI in identity verification processes, looking at document matching, document matching, selfies, facial recognition, looking at context around identity verification attempt events, trying to help sort out and prevent deep fakes. We have behavioral biometrics.

This is how we interact with our devices, whether it be keystrokes, mouse usage, or touchscreen pressure. Again, that generates an enormous amount of data and behavioral biometrics are used. ML is used in behavioral biometrics to determine when the behavior becomes suspicious. We have been using things like deep learning for password lists and risk-based authentication, again, looking at different metrics like device intelligence, network information, IPs.

And again, this is to help sort out what might be suspicious or malicious behavior. All that kind of rolls up into AI-driven fraud prevention through fraud reduction intelligence platforms. This is where you combine many, many different kinds of signals and try to evaluate whether or not a particular transaction is risky. In the last few years, we have seen this roll into identity governance for things like role mining, peer-based entitlement assignment, and up to a certain point within access recertifications. But it's always good to keep a human in the loop for things like that.

Where we see NLP and LLMs being involved in IAM are around helping to build access control and authorization policies. Natural language processing for building policies is a great idea because authorization has been one of the more difficult parts of the overall IAM infrastructure to get right. And there have been a number of different policy frameworks and languages, things like Exactable, that are quite powerful but can be difficult for administrative users to accurately capture what they want in an Exactable policy.

So if you can have a natural language interface for that, it certainly could make defining your access control policies easier. Same thing for consent and privacy management, being able to use NLP to determine what the user's preferences are, and then also to assist with compliance. And then lastly, as I've already mentioned, there's AI-powered chatbots for user support. You've probably encountered these a time or two, even with changes to credentials or password resets. Some sites will use chatbots to help facilitate that. So let's take our first poll question.

Do you know, is your organization using AI agents yet? And we run the gamut here from no, no plans yet, considering, or just started, or yes, we've already implemented this, or it's always fair to say, I'm not sure whether we are.

So yes, please go ahead and give us your opinion here, and we will continue on, and then we'll take a look at the end. So now I think we might want to move into talking about what are the risks of AI agents and browsers. So we all have security concerns about AI agent usage. I think number one that often gets mentioned are prompt injection attacks, including indirect, you know, using the prompt itself as a way to interfere with processing.

Many are concerned about sensitive data leakage, you know, employees perhaps entering sensitive, company-sensitive information into a prompt, and then how does that get incorporated into the model? Would an attacker be able to sort of reverse engineer that by getting information out of the model that contains sensitive data? There's also the concern about unauthorized use of confidential data. Regulatory compliance, if you're uploading PII, then you're definitely going to have trouble with regulations like GDPR. They may have over permissioned agents.

Simply allowing an agent to take on all the permissions or entitlements that the human user has is probably not a good idea in most cases. Since AI agents are a different type of identity but related to a human identity, the tokens that are generated on their behalf can be misused. They can be used in replay attacks. Those themselves can be taken and used for session hijacking and even impersonating the user agent. And then there are rogue agent plugins that might be available that your unsuspecting users might download and use.

Well, the good news is there are organizations like OWASP and MITRE up next here who have been working on how to categorize and help prevent some of these threats that we see. And I won't read through all of these, but we've talked about memory poisoning, data model poisoning, cascading hallucination attacks, hallucination where in the interest of providing information, it may inadvertently make up information that's not quite true. They may actually do deceptive behaviors. There's the notion of repudiation.

How does, if an agent does something that the human user didn't really want, well, who's responsible for that? How can that be traced? There's identity spoofing. You see things like overwhelming the human in the loop, human in the loop where maybe you give permissions to an agent, but you require it to come back and query the human whether or not a particular transaction should be allowed to go forward. So overwhelming human in the loop, I think is kind of like MFA fatigue attacks where malefactors will trigger MFA events, maybe a push notification to a user's phone.

And eventually they just get tired of getting the pop-ups and they say, yes, I think the same thing can happen with AI agents trying to contact the responsible human user. And then lastly, over here, we see different kinds of human-based attacks.

Of course, malicious users are going to try to attack multi-agent systems and manipulate AI agents directly. And I mentioned MITRE. MITRE Atlas is looking at how are AI-related attacks, how are they categorized, what are the tactics, techniques, and procedures here? You see the Atlas is very similar to MITRE ATT&CK. It has almost all of the same categories across the top here, everything from reconnaissance and resource development to persistence and privilege escalation and command and control and exfiltration on the right side. What's really different here, though, is AI ATT&CK staging.

But you can see that there are tactics all across the MITRE Atlas that involve either AI agents or AI systems that have very specific tactics and techniques for manipulating AI, everything from automating the scanning for recon, getting victim IDs. It can be used for phishing. I think we've probably all seen many examples of that already. For defense evasion here, just for example, corrupting the AI model, evading the AI model are things that you need to watch out for. Then the AI ATT&CK staging, these are the ones that are very specific to AI ATT&CKs.

Creating adversarial data, deepfakes, deepfakes we've been talking about for a few years, the rise of AI tools has allowed malicious users or fraudsters to far more easily create deepfake photos, deepfake audio, video that can be used in different kinds of fraud attacks. And then exfiltration, and you see here that the AI agent itself might be an agent for exfiltrating data. So I would encourage you to take a look at both the OWASP AI ATT&CK or AI threats and MITRE Atlas to get a better understanding of the AI specific attacks.

And here with MITRE Atlas, they have both theoretical attacks and those that have already been observed in the wild. I've only chosen to represent here the ones that they say have been observed in the wild. So I think it would be a good idea for those who are implementing AI agents right now to understand how and what the threats are and what the possible mitigations are. So with regard to IAM itself, what are our concerns about AI?

Well, prompt injection corrupted those agents. It maybe can change configurations of the agents or maybe even approve malicious access requests.

Again, thinking about those IGA use cases, agents with too broad of a scope. Think of an administrative user. I don't think you'd want to delegate something like approving federations or IGA updates to an agent. That would just be too risky. Maybe there's poisoning of identity analytics training data. We look at joint remover lever records, peer analysis, things like this, again, to maybe help do role mining, understanding what users have access to and what they should and shouldn't have access to. But that in itself could be an attack surface.

Sensitive data leakage, remote identity verification failures. Again, talking about deep fakes and presentation time attacks there. That's one way in which AI tools, and not even necessarily tools that were designed to be malicious, but there are tools out there for creating photorealistic images and video that fraudsters are using to get credentials issued. And then lastly here, we've got opaque automated decisions. If it's a black box and it can't be explained, that certainly can raise questions about how it can be used within IAM. And then supply chain risks.

How do the third-party models, if you're using third-party models and accepting agents from other companies or consumer users at large, what can go wrong if you're doing that? I think these need to be fully appreciated and worked out in order to secure your system. Moving on here, the last thing I want to say about AI agent dangers is the UK NCSC says there's a good chance that prompt injection will never properly be mitigated. Because when you think about it, prompt injection can be wide open.

It would be very difficult for an AI solution provider to code every possible permutation of malicious instructions that could be given to an element. So I certainly understand why they say that. So prompt injection, whether you're talking about that for AI solutions in general or specifically how they're used in IAM AI agents and AI technology, definitely has risks we need to be concerned about and working to mitigate. Another quick mention here for NIST on their AI risk management framework.

We need to think about are these agents and AI solutions that we're putting in place, are they valid and reliable? Are they safe? Do they not actually cause harm? Are they secure and resilient? Do they adhere to privacy regulations and are they fair? So there's the link there. There's links in there for OWASP and MITRE as well. In the interest of time, I'll continue quickly here, but I encourage you to take a look at these links. So lastly here, I wanted to talk about how do we mitigate these. We must try to secure agent identities.

We've been living with the principle of least privilege for quite a while and zero trust. There are also technical standards around dynamic client registration and push authorization requests and using continuous email powered assessments against what you might find in the logs of what agents are doing within your systems. There are LLM aware firewalls. This may be able to help with validating the intent to help prevent some prompt injection.

DLP, it's an old term, but a data security platform might be able to help with preventing data exfiltration. Always minimize data. Use SBOMs to help mitigate supply chain risks.

ITDR, including ISPM, Identity Security Posture Management, should be AI agent aware such that it can not only distinguish between AI agents and their responsible humans, but understand what is allowable or what should be allowable for both the humans and their AI agents. We need guardrails for those IGA use cases. Drilling down a little more on that. Recertification assistance, yes, but certainly I don't think we'd want to use it for automatic attestation. And then lastly, just monitor and analyze all the logs, as I said before.

So last poll question here is what is your top concern about using AI agents? Is it data exfiltration or improper use of data for training the AI model? Do you have concerns about regulatory compliance? Maybe PII that gets put into an AI system? Is it over permissioned agents maybe doing more on behalf of the user than they really should be able to? Or is it model poisoning?

So again, we'd encourage you to take the poll question. And if you think of any questions for us, please feel free to submit them. And I'm going to turn it over to Michael now.

Thank you, John. So now with having heard all of that, let me tell you a little bit how we can actually try to mitigate some of those risks when we build our own agent. So a quick heads up, this session is under safe harbor, so any forward-looking statements might change. And this is obviously general advice and not legal or security or anything other than that. Now with that having said, I'm Michael Pedersen.

I'm a Senior Solutions Consultant with Okta and R0 and have a strong focus on the R0 platform and going to talk a little bit more about how we can actually build AI agents in a secure manner and what is the problem. So now we all know that identity isn't just a lock-in box.

Today, identity is mission critical. It's how you secure your business. It's how you personalize every digital experience. And most importantly, it's how you earn trust with your customers or your users. And now we are entering this new era, one where AI is starting to power products everywhere, and we just heard earlier about all these help desk systems and others that are already utilizing it, our own AI products. So what we as builders want to do is from here on, that every application we build, whether it's customer-facing or it's internal, it needs to be built with AI in mind.

Now, we believe AI will unlock incredible new opportunities, but it also introduces a lot of new risks. And as we'll see today, identity will help solve at least some of them. So if there is one important thing you take away from this session, it is to get AI right, you have to get identity right. So identity is a really key part here, and let's talk about the shift and how it impacts builders. So that's where us zero comes in.

We have always helped builders to manage human identities, and now we do the same for AI agents, so that you can stay secure and keep building what's next, without having to do all the heavy grunt work when it comes to identity and security. So let's talk about what building in the AI area really means. So every builder faces two new mandates.

First, bring AI into products, and that's not just as a feature, but as a new experience with agents, with internal co-pilots, and smart workforce. But secondly, make sure that your products are AI-ready. So they need to be ready for other agents and systems to interact with them securely.

Now, this is a massive shift in how we architect systems. Identity can't be bolted on after the fact anymore. Agents need to be secure by design. So securing agents with identity is fundamentally different from securing traditional apps. There are two big differences.

First, AI agents need to be able to communicate with AI. Second, AI agents are unpredictable. They accept open-ended input, and they are not deterministic. So summarizing public data, well, the risk might be low, but handling sensitive data or taking action on their own, the risk increases significantly.

So second, the old three-tier architecture model doesn't hold anymore. AI is reshaping your stack. Agents become the presentation layer, your APIs, and sometimes the data become exposed surfaces. So this risk when dealing with your own agents, and even worse, when exposing your products to third-party agents, is real.

Now, put those two things together, and you have a new set of serious risks to tackle. Every API call and every permission check must be secured, and identity is how you can do that. So here's the challenge. Moving fast while staying secure. We've been working with a lot of leaders who are facing it head-on. To build AI, you need identity that's easy to integrate, flexible, and secure by design. That's our zero. It's who we've been from day one.

We've made it easy to have identity in web and mobile apps, and now we're doing it again for AI systems, because to get AI right, you have to get identity right. So what are the pillars of a secure AI application? The first one is obvious. It's authentication. AI needs to know who I am, so it can build the user profile, get the user context, and also offer personalized content. So Gen-AI agents aren't just answering prompts. They're making decisions and calling APIs, and context tells them who they represent, what they can access, and how cautious they need to be.

AI agents need to access APIs on behalf of a user. So for example, they might need to access a Google calendar to schedule an event. They send messages via Slack. Maybe their personal ID is a user. They might need to access a Google calendar to schedule an event. They send messages via Slack. Maybe they purchase stock. And they can perform async operations autonomously. But to complete critical actions, like booking something or purchasing something, they should require proper human authorization.

So for example, a travel agent AI, a user needs to consent and approve an operation before the agent proceeds. So the booking should be confirmed by a real person. AI also needs to control the data, so that the agent itself can only access data that the user has permissions to. So in summary, AI needs to know who I am, to perform tasks on my behalf, be able to ask me for permission, and act on my responses, and comply with the same constraints that I have too. So that means that an AI agent that's acting on my behalf should not have access to more data or more power than I have.

Without identity, the agents become blind to the context, risky in actions, and really unusable in enterprise settings, to be honest. So, to understand how gen AI applications work, and how we get from a user's prompt to the models, to the planning, to the calls, and even human approvals, we have a little bit of an overview. When the agent decides to take action, like calling a calendar, for example, or retrieving a document, or submitting a request, we need a way to ensure that the action is scoped to the right user, it follows the approved access, and when needed, involves user confirmation.

So that's where OSIRO comes in as an identity security layer. We are not part of the model or the agent logic itself.

Instead, OSIRO enables these systems to operate with clear identity context, user consent, and enforced access controls. So we handle the authentication, so the agent knows who it is acting for. We manage the token exchange for external tools, and all of this is done securely and behind the scenes. We support asynchronous user approvals, allowing users to review and approve sensitive agent actions, and we enforce fine-grained authorization to help ensure agents can only access the resources they're permitted to.

So this gives the team the tools and control points to meet security and compliance requirements in an agent-powered workflow. So whether you're building for individual creators or collaborative workspaces, we can create a user journey for B2B or B2C experience, and you can obviously customize logins, pages, and the whole flow according to your needs. So now that we have these agents that can access different data, we obviously need to ask ourselves, how can we enforce this at runtime? And we heard some of the risks earlier already.

A lot of them can be mitigated by ensuring the agent itself cannot expose, even if you wanted to, more data than the user has access to. So as an example, if we take a medical scenario and we have an AI agent that can access patient records, then we should make sure that this agent is scoped to the proper user he's acting on, and he has not generic access to all patient records, for example. And then the agent could be convinced in some way by prompting to expose maybe more data or more information than they should. So how can we do that?

One way to do this is with a fine-grained access control, where we can create a model that represents how maybe patient data is linked to medical records, is linked to agents. And based on this authorization model, we can create these relationship graphs that tell the system how different pieces of information can be accessed. And then we can fill this system with what we call permission data or tuples that give a clear linkage between, for example, a user or an AI agent and the data that he can access.

And by doing so, in the next step, we can have a rack pipeline, a retrieval augmented generation system to enforce this. So this allows us to more accurately combining the model's reasoning data with real data. So instead of relying only on what the model already learned during the training, you can pull the documents from your own data or give them access to the model when they're generating the answers. So when the user sends a prompt, the AI agent kicks off a search to find the documents that might help to answer it.

It does so by queries to a vector store, and the system then retrieves the documents that most likely have the correct data in them or the required data, and uses these so-called embeddings into the context for the answer. But what you want to make sure here is that we actually control the data or the embeddings that are actually returned by these systems. So R0FJ applies a post-retrieval application layer filter. So we're not filtering inside the vector store itself, and that's by design, because the vector stores today aren't built for dynamic user-by-user access control.

They're optimized for fast search and not for making real-time permission decisions. So trying to push fine-grained access rules into the vector layer would slow retrieval down and make your system harder to manage as you scale. So instead, the retriever, like a lang chain retriever or something like that, pulls a broad set of documents first and then applies FJ access checks before handing anything over to the LLM. So this keeps retrieval fast and open, but locks down what the AI can actually see and use based on each user's permission. And here's the good news.

With just a few lines of code, you can integrate FJ checks right into your retriever logic. So there's no need to re-index your data or change how you embed documents. And we have actually a full working example that's posted in the Auth0 for AI Agents Quickstart documentation if you want to have a look at that.

Now, to give you an idea how this all works together, we have this fictitious application. It's a stock market application, and if I'm querying for stock prices as a user, I will get some generic information. So it shows me a forecast. It gives me some more or less public information that is available.

But now, as a user, I can register. I can join the newsletter, for example. And by doing so, I can actually get more access and more permission internally. So if I'm asking the same question again, I will actually get a more detailed answer because now the FJA system will give me a broader access to documents to my LM.

Now, if I want to maybe book a calendar invite for some events, my agent needs access to my Google Calendar. So now what we can do is we can use our token world to get authorization of the user to access this calendar, and we can securely and safely store this in our system so you don't need to mess with these tokens by yourself. And now we can actually use our Google Calendar and now we can create this calendar invite on behalf of the user.

Now, lastly, if we want to buy some stock or we want to let the agent automatically do this, we obviously want to get confirmation when this is done. So we can actually enroll into our push notification system, and now when the agent is trying to book some stock on our behalf, we will actually get a prompt on our mobile phone to approve or deny this. And so this gives us full control on this human-in-the-loop flow and allows us to confidently let that agent do its work.

So with that being said, the four pillars, again, that we identified for AI agents that we can help and we should secure is, first of all, ensuring that we understand the identity of the user, so we authenticate users for the AI system. We securely store tokens on behalf of users and provide them to the agent just in time when he needs them. We allow for a synchronous authorization to keep the human-in-the-loop.

And finally, we use fine-grained authorization for rack systems to ensure that user data is always protected and the agent can only access data that he or the user he's acting on behalf actually has access to. And if you want to get started with this yourself and you want to have a look into how to implement AI agents with Auth0, feel free to visit us at auth0.com.ai and have a look for yourself. And with that being said, thank you very much for your time and attention.

Well, thanks, Michael. That's a lot of good information there.

So, let's start by taking a look at the results from our poll questions. First question was, is your organization using AI agents? 39% said considering, 26% have said already implemented, 17% say they've just started, and 9% each have said either no plans yet or not sure. And then the second question, what's your top concern about using AI agents? 57% said over permissioned agents, 35% said data exfiltration, and then 4% said regulatory compliance and model poisoning. Any thoughts about the poll results, Michael? Yes.

So, sorry, I couldn't find the button. Yeah, one of the key things we identified as well is obviously the improper use of data. And that's where I think FGA comes into play to really ensure that agents don't have more access to data than they should have. And I know this is a very big problem at the moment where developers just go the easy way, right? And they just give agents access to everything and then hope that a system prompt will fix it. But in reality, that's usually not working reliably. Okay.

So, we have a question in the chat blank. We'll start with that one. How about more autonomous agent concepts not running in the context of a human end user, but for example, in the context of a specific application or business process instead? That's interesting. I guess we have those in place already today.

I mean, code is what makes up applications and the applications often have service accounts associated with them. So, maybe in this way, a service account sort of acting as an agent on behalf of an application.

Typically, when we talk about non-human identity bundle things like AI agents and, you know, service accounts as examples of NHIs. What are your thoughts on this question? It's in the chat window, Michael. Yeah.

No, it's true. So, there is obviously a whole chapter or a whole area on how to control and monitor, manage agents that are not linked directly to a user.

So, that run like a service account that run autonomously. But the base issue is still the same. They need to have some kind of identity to be able to be controlled and restricted properly. Because if they run as a service account, it's like some kind of all-seeing eye, then it's bound to fail.

And so, things like FGA that can very effectively restrict permissions of what HE can do are obviously a good way to mitigate that. Agree. Next question. Agent should not have more access than the person using it. A lot of users have more access than they really need because we have trusted humans to a degree.

So, how do we limit or mitigate that risk? I think that's a really good observation. And I think we're both in agreement with you that agents don't need the full set, but rather a subset of permissions that the user should agree to before the agent can act on behalf of that user. And I think to reiterate Michael's point about fine-grained authorization, you know, that starts with selecting the appropriate permissions for that particular agent that would be, you know, a reduced set of what the human user has. Yeah.

I mean, to add to that, maybe one thing that did not become clear is that FGA by itself, right, it's not something like a system to limit access to files or data per se. It's like a concept of getting permissions and authorization for all kinds of actions.

So, A, you don't need to limit it to something. You can also maybe restrict tool usage or other access to systems. But also in our system, by using this model approach, we can actually very easily create an entity of an agent that can act on behalf of a user, but maybe has a limited access.

So, even if the user is over-provisioned for some reason, it doesn't mean that the agent has exactly the same authorization as a user, but it can actually already build into the system or in the model only access a subset of what the user can. Another question is, the human-in-the-loop concept is interesting. Can you provide a concrete example of a workflow where this would be critical? The screen just refreshed on me. And what would the user experience look like for the person who needs to approve the action?

This would be, you know, a case where some of the emerging standards around dynamic clients registration and pushed authorization requests could come into play, where the agent itself could be configured, maybe in the case of, like, you know, transaction authorization. If a transaction is going to exceed a certain amount, then the human user can get a pop-up asking, you know, is this, in fact, something that you want to authorize? How have you seen this implemented, Michael?

Yeah, I mean, one example would be what we've just seen, right? An agent that buys stock on behalf of a user, but obviously before I do this financial transaction that's affecting me in the real world, I want to be the one to press the button. So that could be a push notification to a mobile phone, it could be something via email or Slack, it could be email or Slack. It really is up to you how you, for your use case, what's the most reasonable approach.

If it's, for example, maybe an, I don't know, an HR bot that's doing some work and it needs to get some approval to do something, maybe it's not that time sensitive to require a push notification, maybe an email is good enough or a Slack message to the HR manager. So there's many different ways on how this could be implemented, but the key thing is to have it, right? To make sure there is, at certain points that are important, there is a human still there that makes the decision and it's not just the agent autonomously decides to give everybody in the company a 200% pay rise.

One more has just appeared here. Are there any real production experiences integrating Okta FGA with Amazon Bedrock Agent Core Gateway? That's a very specific question. I'm not sure if we have something that we would call a real prod experience. I know we internally, we build some demo applications with that already for our own usage. I couldn't say if there's a customer production system in place for that at the moment. Okay.

Well, I don't see any more questions in the control panel. So I'd like to say thanks to everyone for attending. Thanks to Michael and Okta for being here today. If you would like more information, feel free to reach out to us and the slides and the recording will be available shortly. Thanks again, Michael. Thank you for having me.