Identity Collapse in the Age of Autonomous Agents

Well, hello everyone. Good morning, good afternoon, good evening, wherever you are in the world. Thanks for joining us today. I'm John Tolbert, Principal Analyst and Director of Cyber Security Research here at KuppingerCole, and today I'm joined by Ayesha Dissanayaka from WSO2.

Hello, Ayesha. Hey, John. Welcome everyone for this very interesting topic of the day. Looking forward for this discussion. So I've been at WSO2 for 12 years solving identity and access management problem, and now it's a very exciting time for the identity domain with the agents coming into the play and changing the domain in a very interesting manner. Great.

Yeah, it's never a dull moment in IAM. Exactly. And today we're going to talk about identity collapse in the age of autonomous agents. I think it's a topic that's on everyone's mind and has been for weeks and weeks and weeks. So a little bit of logistics info before we get going. We're in control of the audio, so everybody's muted centrally. There's no need to try to mute or unmute yourself. We're going to run three poll questions today because we really want to see how you feel about some of these subjects. You have an opportunity to submit your own questions as you go along.

You'll see a questions panel in the control panel, and you can enter those at any time, and we will take those at the end. And then lastly, we're recording this, so both the slides and the webinar should be available for you to review or download in a few days. So first up, I think we should set the stage.

You know, every identity system we use today more or less assumes that an actor is a person. You know, one person, one individual, just acting as themselves with permissions or entitlements that might just change slowly over time. But agents kind of break all these assumptions. They don't act as themselves. They borrow authority from whoever's behind them. They don't have fixed permissions. They might even work out what they need, you know, at runtime. So one agent type isn't a single identity. It might run across multiple instances.

It might run across different AI models and even different vendor platforms. So the set of tools they use can change from day to day. So the real question isn't about how you make an agent log in, but, you know, how do you make our identity systems that we have today work with agents? What are your thoughts on that, Aisha?

Yeah, John. So at the very early days when the agents come into the play, one of the very questions that I've been hearing is that we've been solving the identity problems for long. Why can't we just point agents into the existing identity system? So you raised a very important point there. So agents are fundamentally different from what we have been engaging so far. So human is a decision-making subject. A service provider is a client that's invoking resources and they are a resource service that we need to secure and give protected access to.

But an agent is all three of them at once and most probably within a single request. And we don't have an inbuilt IAM construct that represents this agent's true nature as of now. And as you also mentioned, the same agent code will behave completely differently based on the AI model that it points to, based on the system prompt, or based on the tool set that it has access to. So even if it's the same software code, traditionally applications, we get the same output from them. But now we get different output based on different instances.

And also, as you mentioned, agents discover capabilities as they go along. So their permissions cannot be predefined. So those are very dynamic. They might decide to do and access a tool based on the human prompt that we provide. So today's tool catalog is the next day's tool catalog for that agent. So it's very dynamic in that sense as well. And our existing IAM systems are not built for that. So that's why we need to rethink the identity and access management model for agents.

Yeah, and to build on something you said there that's really interesting, and I've heard this from many others as well, is with agents, the behavior is probabilistic rather than deterministic. So like you said, what an agent does for you one day might not take the exact same path the next day. And that is what introduces the uncertainty about how agents might behave and why you need to get the identity part right, I think.

Yeah, of course. And so similarly, earlier the workloads and the applications were task-oriented and they have a script, but now the agents are goal-oriented. So getting to that goal, they might go through different plans, and they tried things, and they execute it. And so the tool access or the APS they call may differ. As you mentioned, it's not the same prompt. If you run it twice, it might go completely to different paths. And they learn as it goes along and optimize the execution part.

So yeah, completely agree there. You know, you mentioned workload IDs. That's interesting too. We've been tending to lump AI agents into the broader class of non-human identities or NHIs, and I think that's valid and relevant, but the behavior can be quite a bit different. It's not exactly like a workload ID. It's not exactly like a service account.

Again, because of the probabilistic nature of what they do. Yeah, true. So major difference is that deterministic versus entertainmentistic. So previous workloads, they adhere to a script, but now agents run as a workload in the background, in a VM or so, but they are different. Their behaviors are different. They execute differently. So let's just go ahead and start off with a poll. We're curious to know, is your enterprise actually using AI agents that you know of right now? So feel free to answer this as we go along.

And yeah, wondering what the current state of the agentic world is out there amongst our audience. So that will be open for you.

So yeah, before we get into the whole identity problem, I think it's good to be concrete about what we actually mean by agents. So the most common type of agent that you hear people talk about is a travel agent. You can set up a travel agent that acts like a human travel agent would, and it might look for specific flights for you, and you can configure it to know that you like aisle seats or something like that. But maybe that analogy has gotten a bit tired at this point, because there are lots of other kinds of agents that are out there too.

There could be things like co-pilots in your IDEs or your CRMs. On the top right, we see there's delegated authority, but it's running asynchronously. Things like triaging your inbox or prepping for your daily briefing or maybe auto-filling your expenses. Then you see bottom left shared service agents, the pretty familiar customer support chatbots or knowledge-based search. And then on the bottom right, I think is where it gets most interesting. These are the more fully autonomous workloads, document processing, fraud detection, AI agents for acting as fraud analysts.

So there's quite a wide range, and you can see the scale where you go from top left, it's more interactive. But then down to the bottom right, we're looking at more of the non-interactive, fully autonomous. Yeah. So I think we are just scratching the surface on this agentic AI, and the possibilities are vast, as you just mentioned. The places that we can employ agents are different, as we see in the slide.

At the bottom, horizontally, you can see that being being agents that are interactive and working along with the user, but still does not require use human authority, delegated authority from a human on the left side. But on the right side, we see the more interactive way, non-interactive, the workload kind of ones. And so the interesting part is that the ways that we need to ensure how these agents interact with our system, how users interact with these systems are different based on the behavior or the nature of that agent.

For example, the human interacting agents, we need more of a chat-like interfaces or CLIs that can authorize a human. But the workload side of ones that are running on the VMs or in the background, or the long-running asynchronous assistants, they might not have a browser interaction for the user. So based on that, how we delegate these authorizations, how we give them access to the system differ. So then one side, one identity or access management model fits all, isn't going to work.

So we need to find the proper model based on their behaviors, based on their, whose authority they're acting, and where they are deployed and which critical system they access. Based on that, we need to evaluate their security models. So are you and your customers seeing a wide range of these different kinds of agents in use today, or is it still early days and people are trying to get familiar with it and not quite ready to deploy, but wanting to become more aware of what it can do for them?

Yeah, surprisingly many people that I've talked to, customers, prospect, they are looking into all these different types of agents, like especially they want to start with internal processor optimization agents. They are like these agents that are running on CI-CD pipelines that are doing repetitive tasks that can easily be hand over to the agents. So we've seen that people needing to employ them, but one of the key factors that prevent them going into the production and unleashing them into the actual system is this, how to secure them properly and how to govern them properly.

That's one thing. Organizations are scared of the capabilities that, or rather if something goes wrong, how to prevent that. So very good pattern I see is that everybody wants to layer proper governance architecture before deploying them into production, but everybody's evaluating, deploying different kinds of these agents, customer facing, customer success agents, and both internal process optimization agents.

Yeah, that's kind of what I'm seeing too. I mean, co-pilots, note takers, those things are pretty common and sometimes whether you want to or not, you wind up talking to customer support chatbots or knowledge-based chatbots.

Yeah, I think we're still early days on the things on the right here, the non-interactive, more truly agentic stuff. So let's do another poll. Which best describes your primary agent use case today? Are you using customer facing things or are you doing, have agents for internal productivity? Are you looking at autonomous workflows, security ops, or are you just not deploying agents of this kind yet?

So again, the poll will stay open and feel free to answer at your leisure. So next up, everything we've been talking about agents, being non-human really comes down to four specific things. And fortunately, they all start with A's, so it makes a nice mnemonic device. So here on the left, we've got administer, and that starts with registration and life cycle management. Authenticate, we know authentication pretty well. And then we've got a number of non-human.

We know authentication pretty well, but authentication for agents is going to take a little bit of a different turn because it's not just authenticating the user behind that. Authorize, authorization's always been, I think, the hardest problem in identity management. And we've got lots of good concepts here, like least privilege or just in time, things that now need to be applied at the agent level. And over the last few weeks, I've heard a lot of interesting comments about we've had really good technology, good standards for doing authorization for many years.

And maybe the rise of AI agents is going to be what really forces everyone to focus on authorization and how to do it right. And then lastly, audit. You need to know what the agents were doing so you can figure out, you know, in case of a forensic investigation, what needs to happen as a result of that. What can you tell us about the four A's, Aisha?

Yeah, so these terms are not new to the identity and access management domain. So what's new is the scope that it needs to cover. So AI agents have surfaced different challenges in each pillar, each of these pillars that we need to tackle in order to securely deploy agents in scale.

So, for example, in the administrator side, so one thing is like how we onboard these agents into systems. If we take an employee, there's a like HR process that we would onboard a human employee into the organization. But for agents, those instances get deployed periodically or maybe daily, or they can even get spawned for a particular task and die away once the task is done. So the registration flows are different from for the agents.

And then one key concept is that this ownership, like for human employees, if you take the HR reporting order, but for agents, who takes the responsibility and who's liable for the action. But at the end of the day, if you deploy an agent for your organization, as organization, you are liable. So that liability has to propagate across departments or across human managers or so.

Likewise, having human ownership for that agent, then that ensures there's periodical review on that agent and then someone who's taking the responsibility and that agent is not stale and hanging there forever. And also having the visibility for CSOs and SecOps that who are the agents that are running my organization. That's important because shadow AI is becoming very prevalent now. Even the employees, they deploy agents into their system to get things done. But there are agents running in the enterprise system without CSOs knowing.

But having a central registry or administering them in a single control plane gives you the visibility for them. And as you mentioned, the authenticate side, this now we need just not need like we have humans and we have agents that both of them take decisions and they take action. So we need to authenticate both of them into the system. And sometimes there are agents that are running on their own. So then how those agents can get authenticated.

And there's a lot of trend on like bridging workload identity authentication mechanisms with application layer or world of identity or world of authentication system, which gives you a way to authenticate agents based on where they run. And as you mentioned, authorization start with the minimum privileges that the agent requires. And then based on the new capabilities or based on new privileges that it might need, then authorize them just in time and have mechanism for them to step up their authorization. And then not having broader scopes is again important.

Like usually what people or the developer starts with these creating API key or personal access token with all the possible scopes executions and then give it a loan. That's a standing liability and that's a that's a that's a and that will work for the POCs but it won't scale when you're going into production.

So the last pillar is one of the important pillars like if some how we trace back these actions, who did what and for what reason so that if we use these API keys or if you only authenticate and authorize for the human only then everything trace back to the owner of that identity human use only but the actual execution the decision might have been made by an agent so we can't distinguish user deciding to do something versus agent deciding and executing something. So that having that visibility is important when we are auditing and auditing agent actions in these enterprise systems.

I want to go back to a couple of things you said because I thought they were really interesting.

You know you said shadow AI that reminds me of shadow IT from years ago and you know the development of CASB to try to address that and also the fact that you know one user can have many agents so what we've been saying about NHIs for quite a while now is there are far more NHIs in a in your directory than actual humans and I think these two points that you made really emphasize the fact that this is this is identity sprawl for sure we're going to see more and more different kinds of agents as well as other types of NHIs and it's good to try to get a handle on these things now before they get out of control.

Yeah of course of course and another thing is like having this stale identity starting right like then again it becomes like we don't know which ones are used which ones are not used so that's also important like monitoring who what are the active identities and what are the like stale or not used identity so these periodic cleanups are very important that since when administering these agents in a proper system.

Yeah in IGA or life cycle management we talk about you know orphaned accounts and I think we're going to see an explosion of those two accounts that agents that may no longer be running maybe a user's not using them anymore so every account that has permissions out there is another potential attack vector so we're really going to have to be diligent about keeping our user roles our agent roles purged when necessary. So can you talk about how agent ID enables the forays for all agents?

Yeah so this picture shows how the external world interacts with an agent so now we have different callers, invoking parties, it could be users, it could be other application or even other agents that are incoming that are initiating request to agent and then agents talk to LLMs or AI models or that's their brain and then they talk to external tools like not only external but internal business system that the organization is having control of and also third-party system that the organization might have purchased for and also agents spawn other agents or sub-agents that do the same.

So every line that you see here that are coming into or going out of agent is a risk boundary that we need to properly govern and secure and apply access control and policies on top of that. So if you start with the left side so who are the people who are the parties that are calling the agent so having like when we establish agent ID so when we treat them as first class entity in our identity ecosystem and govern them it gives us the capability to write policies or apply policies who are the parties that can invoke this agent and have mechanism for them to authenticate to the agent.

If the agent is the application itself it could be going through MFF or if the agent is exposed as API like a chat API then it can go through the API access control model or else and when the agent is talking to the LLM so that's also important where we can apply different guardrails and so on.

So one of the patterns that we see here is that having an AI gateway in the middle between the agent and the LLM so that we can apply guardrails, apply monitoring and apply different policies but and having agent identity allows us to apply a more informed guardrails at that so that agent will authenticate using their identity to the LLM and then LLM or the AI gateway in the middle so that policies can be a special case for the different cases and also now cloud open AI they are also moving away from this API key based authentication to workload identity kind of federation integration so that we those tokens are moving towards more short-lived more identity aware tokens so that the federation policies and rules can be more sophisticated on this call channel and agent tool calls are very important so then they also now there are two parties who the invoker that invoked the agent and then who's the actual agent that makes the making the call so we might need to seal the permissions have a ceiling for the permission like even though the user has these permissions agent should not be able to inherit those permissions and it has to be limited to some level of authorization depending on the purpose of that agent otherwise agent if you give more than the privileges that it requires it might do something else that it other than something else that it was supposed to do and then that also important for the auditability as well knowing what agent did which which action or invoke which API or the MCP tool or which database or so on on behalf of which party that's acting in before that and this external system part is also very important so most of the existing organizations already have API gateways and authorization layer in between in front of their internal APIs but now with AI agents now we see the need for controlling the egress traffic so knowing what are the external systems that the agents are invoking if you are familiar with that one of the recent or a couple of months back there was a incident where an AI agent has gained access to a Google workspace through Vercell in Vercell towards AI agents so that's because there wasn't the visibility what are the external systems that the agent has access to through this agent so we see that pattern of having an egress gateway so that all the agentic traffic will be monitored and governed and authorized through that egress gateway and then flow into the external system and in the agent communication it's one important thing is preserving this delegation chain one agent may talk to another agent and that agent talk to another agent and eventually it will end up with the tool call but at the point that tool call is made tool needs to know the whole the delegation chain or it needs to know who the user or the subject at the top of that chain so having identities for these agents allows us to incorporate those identities in the tokens and then have it at the tool level have that visibility for those agents but otherwise if all of them share the same service account we won't see the chain coming through or if they borrow identity from the user we don't see any of the agents in the chain so having an identity for the agent and giving them a way to authenticate themselves and prove themselves and giving them ways to have access levels for themselves and ways to get authorizations from other parties delegate authorization from other parties allows us to have that control layer around the agents securing all these lines incoming and outgoing from the agents you know i think this is a good architectural picture because it actually kind of helps define agents you know on a different level too sometimes i think we forget or maybe we're lulled into thinking that agents are you know magical entities but no they're just code they're code that call llms and and this is why they need a really good robust identity infrastructure because you need to be able to do these four things and yes authorization is still going to be you know the most difficult part and there's multiple components even to the authorization piece and then you see how it all fits together with you know external systems here because every organization is already using lots and lots of different internal and external applications sas applications and each one of these can be a target or a data source depending on how your users are interacting with their agents so i think you know this really illustrates the complexity of what agents are and what they can do so time for one more poll question how does your enterprise manage identities of ai agents today and i'm sure is a perfectly valid answer or no formal identity management for agents is also a valid answer if you don't have that because you know honestly we're still kind of in the early days of figuring this out we will launch into a discussion in a few minutes here about standards so you know it's good to keep in mind this is definitely an emerging area yet so please feel free to give us your answer and this will stay open and we'll continue on so yeah standards we've talked about what agent identity needs to do now we have to think about how is this all plumbed together and aisha's mentioned mcp and a to a already i think these are two really important pieces in puzzle but we also have some tried and true standards that are being extended today you know things from oidc oauth2 we have authzen from the open id foundation you know this is a good way to standardize communication between the policy decision point and policy enforcement point those terms you might remember come from the exacto days we also have seba we have which is good for out of band human approval this is the human in the loop that we often talk about but then there's also dynamic client registration and pushed authorization requests and these different pieces can be put together to help an organization design you know a more comprehensive authorization system but as you can see there are multiple components what uh where do you see clients at right now in in this process with adopting standards or participating in the standards bodies um so yeah starting with mcp so it's it's very hot at this moment and we see a lot of adoption there as well even from our customers they've they're in the process of building up new mcp servers or converting the existing apis into mcps and so since it has given away a standard way of how agents can talk agents can talk to tools and simplified many integration through that mcp so it has gained a lot of adoption and so there's a lot so i was recently in this mcp dev summit in india so there was a lot of interest from the audience and from the dev community also on the mcp and 8-way as you mentioned so that defines how you talk between agents so these are very becoming hot topics and adapting well and not only this OIDC extension so we these are very these are also very getting gaining traction and there's a lot of well-tested OIDC specifications that we have like private key JWT for agent authentication and then token exchange importantly so when there are like multi-agent hops we then to downscope the token the permission that the token has or to change the audience of that token and of course to keep that delegation chain in included in the token so that that has that being developed into multiple different more scope proposals as well and as you mentioned the OATSEN one it's getting well adapted there's a profile for mcp also there's proposal for OATSEN profile for mcp as well because it's standardized how you check whether this agent has access to this particular resource or action under these conditions so it's that standardization is very powerful and it makes things interoperable as well so it gives you a standard way when an agent is hitting an API or a tool call or mcp endpoint for that tool to talk to a pdp and ask whether I should permit this or not so that gives you a more real-time validation on whether that we should allow it or not and they are even in the identity professionals there are multiple where multiple proposals that are going that are being discussed and standardization also important because now standards give us the way to interoperate and then without standard people will build something on their own and then they won't scale so they'll have to build everything proprietary for each and every integration but standardization is very important and there's a lot of traction from customers and organizations and within the dev community also towards these.

Yeah I often hear people mention you know we've got an mcp server and that's great but that sort of helps you do coarse-grained authorization between users and agents and the tools or resources they can get to but there are all these other standards that exist or are also in work that can help with the fine-grained part.

So intent is something we really haven't probably talked about that much before you know in the identity world or at least not in the same way as we have to now with agents so I mean we have to think about how do you capture the intent of what an agent will do there are mechanisms by which you can do that it also requires some honesty on the part of the user that's you know configuring that but this is just the starting point how do we represent that and then how do we use intent to do authorization. I think these are really interesting emerging questions that still require some extra work.

What's your take on capturing and authorizing based on intent?

Yeah so this being a very prominent question at the moment because once you give the access to the agent and then agent can do anything with that right I can give my give right access to my database to do delete one row but I can't prevent it deleting the deleting 50 rows right so validating my intentions versus what it did is important but there is no systematic way of doing it right now but I think that's one of the areas that many people struggle with as well because of this agent's undeterministic behavior we can't we we don't have a way to validate whether it will behave the in the same way behave the within the limits of that we expect it to do so but however there are some still we can have some construct around that like having policies on the other side to ensure that ensure that the agent doesn't behave doesn't go beyond what it was in there for example having like measuring like measuring intent was execution plan before executing the actual execution plan for example I use a give a prompt so that's a that's a the prompt is kind of a evidence that what I wanted to do what the user won't expect the agent to do and then converting is to a more structured purpose receive something similar to a consent received that we are familiar with and then then having a different model to validate the agent's execution plan against that purpose received so that we can have some level of temperature check on whether it's going to do the same going to do the thing that the user expected so some some we can use some kind of those approaches in order to validate the intent but this is a very emerging area so I'm also very excited to see where it's heading um yeah I agree I mean just to drill down a little bit more on that I mean there are bits and pieces that we use today OAuth 2 you know the scopes but the scopes bind to the tools it doesn't really take into account intent yet but then we can still use RAR authorization details uh token exchange the on behalf of um and verifiable credentials but we know that not all of these are actually widely used um today but there's also this work in emerging is the word we keep using um I think it's interesting to look at like the Google AP2 the MasterCard verifiable intent you know on the consumer side uh it's good to see that there is some work in place to try to help prevent fraud or you know things happening that the users did not intend I guess you could say it's and on the consumer side it's definitely going to be very interesting to see how all this evolves what are your thoughts on on this particular piece yeah so we have yeah we have bits and pieces uh so we which uh so we don't have a straightforward answer like or a framework that this is how you should do intent-based authorization but we as you mentioned we have like different bits and pieces that we can uh use reuse along with the new uh emerging technologies that we will find and reuse them and uh compose it to a solution that we can be more uh we can be more confident about this agent behaviors and we can be more confident about confident that our resource assets are protected so in the so there's a major part that goes to the resource server so the way other resources are exposed so having uh preventive measures and having policies on that side having this uh mfa verification or checking for these uh second factor authentications whether that to make sure that the user has came through a verified flow and then having this information about authorization passing through our request or having the delegation chain so that we know that it has gone through this uh these these hops and we can apply a policy on top of that likewise having uh these different policies at the resource side is important so that we have preventive measures there as well yeah maybe this is a good point to bring up at least anecdotally you know from recent conferences i've been to the enterprises are exploring how to use agents more so than consumers seem to be using agents for just making purchases so i think you know we we need to go quite a ways yet in developing mechanisms that can then themselves help provide trust uh both to enterprises that will be accepting agents and consumers that might be using those agents yeah so um this constant fatigue is very real thing right so when you bombard agents bombard humans with like same prompt again and again how many asking or every time whether you should whether you are athletic or not so we tend to overlook the details and they tend to approve everything or even like say don't ask me just go and do it right so that's the opposite of what we are expecting for high risk scenarios so we of course need the human in the loop verification as well so so as you have listed down here like having this tiering mechanisms or low risk one we can take the risk and even we can predict what predict the harm and then allow it to do so and uh for higher risk ones for like uh for example a transaction beyond might need to we might need to uh apply a deep apply or get a consent from the human user so um so you made a very good point here in this slide on that as well yeah i think again it kind of kind of comes back to trust because if you think about spending limits allowable actions lists i think industry needs to show that the agents themselves have trustworthiness uh it's probably okay if you can think of these low risk reversible actions but yeah at the same time you're going to want to have really good uh human in the loop kinds of decision making protocols so that if there is a high risk transaction for example you know that the appropriate human has the opportunity to say yes or no to that and that's that also like you said that's consent fatigue how do you manage that we've heard about various types of fatigue in the security and identity world for a while you know mfa fatigue now with agents you could wind up with consent fatigue and that in itself can become an attack vector so i think we have to be quite careful in designing how our agents are working on our behalf so that the right kinds of things do bubble up so that a real person needs to make a decision about it but you know simpler actions that can be simpler actions that can be reversed uh can proceed but again we still have to develop the mechanisms that that appear trustworthy i think before people are really going to be willing to roll this out en masse true um so um to add on to that uh yeah we can move on i think yes no we can go ahead yeah uh so next thing and you know we've talked about one of the four a's audit um naturally when you say audit the word log comes to mind right after that so i think that's really going to be one of the main ways that you find out what agents have been doing uh you know you've already you know you've already got we're already doing this for other kinds of nhis like service accounts workloads um we're gonna have to look for the exact same types of things but you know with with agents i think some of the differentiators you know between not only agent activity and human user activity but even other nhis is that agents will probably you know have bursts of activities it'll be short-lived you you know if they've configured it correctly you'll see these on behalf of delegation chains there could be a very high volume of activity in a really short period of time maybe a bunch of different calls to mcp servers and this will look faster than what a human can do and then it might go silent for quite a while so i mean you can already tell that that the behavior is going to look a little it may look similar but it's going to look different and that's where i think uh intelligence in the agentic ai security world will come into play what are your thoughts yeah so one of the key challenges uh right now is that most of the SOC teams cannot differentiate human user doing something in a regular app versus agent doing something versus uh and another workload doing something on the logs right that's because we people are using this api key so borrowed credentials so that we we don't trace back to the actual entity that caused that particular result and one of the key challenges with these api keys is that uh they always trace back to one entity and then most of the time sometimes the api keys are shared like the moment that two agents share one api key then you completely even you can't manual even you can't manually uh relate those logs into that the traces back to that agent right and then uh i talk about this borrowed credential so that will always trace back to someone else who didn't actually perform the actions and so now when the agents are acting on behalf of a user especially uh if the agent is acting on users credentials that that's a key problem and not being able to distinguish the agent doing versus human user doing through a regular app if something goes wrong we can't isolate that and we can't take mitigative actions or prevent or we can't do the damage control soon enough so uh so it's very important that we have all this information uh the who are the multiple actors in that chain that participated uh resulting in that particular uh result and also uh having monitors on top of these audit logs so that we can monitor the patterns and if one agent is making a frequent api call or a tool call uh so it might be a red flag that we need to attend to and because agents are working on the machine speed so we should have automated monitors and alerts there and for them to work properly we need to identify them individually otherwise we will get false alarms so and that i think that part is important um agreeing so next topic guardrails and hallucination detection um you know we often hear people talking about ai security they'll say you know put guardrails on well what do we really mean there i think it's important to understand what guardrails can can't do input guardrails prompt injection is a type of attack that we hear about um you know you can also maybe prevent out of scope tasks output guardrails maybe stop pii leakage or leakage of intellectual property those those are good basic things of course have to be in place for agents as well but then i think it's important to remember that depending on what source you look at and there are many tests that are going on at any given time lom output can have like a 5 to 15 error rate so how do you how do you accept what an agent does if the back end may have you know a somewhat significant error rate there are things that we can do by using you know retrieval augmented generation making it cite sources and then human accuracy checks you know look at what it's telling you does it make sense those are the sources that it's citing real so i think ultimately if you're using agents and the agents are using llms you need to be aware of the fact that they it may sound authoritative and that's i think one of the problems too is the answers that you get can be very confident but it may not be right you still need some human expertise and ultimately the human that's responsible for what the agent is doing needs to understand what the what the risks are what are your thoughts yeah so the here also that deterministic versus non-deterministic factor comes in as well for the for like regular workload so applications we could have a test suit that and ensure that if the test suit passes we can we we can be sure that the application of the workload is working properly but for agents we can't have something some deterministic test suit like that so that's why the evaluations are important as well so that continuously evaluate whether these agents are giving the output to the level to the satisfactory level that we are expecting and fine-tune it continuously so because agents performance may vary based on the ai model that it talks to the based on the system prompt based on the tool set that it has so one small change and all these or any of these parameters may give you a completely different answer so having that evaluations are very important and that and and keep monitoring them is important and so that also we need to consider when we when we are considering about agent governance and another part is that on top on related to guardrails like when we want domain specific agents we might go for specific purpose build language ai models maybe a small language model that's trained for that particular task so that so that we get more we get a more probabilistically correct answer than asking for a broader ai model so and also here another pattern i've seen is that having this ai gateway in between agent and the ai model so that additional to the these like language guardrails we can apply metering throttling these levels of other guardrails as well so that we have monitors there as well saying ai gateway is a good way to come into our last major topic here agentic ai costs under consumption pricing so you know we've all gotten used to over the last four years subscription-based pricing for you know let's say using a web interface but agents behave differently agents like we said call llms for every task they have various steps through those tasks the more agents use sub-agents the higher the cost will be and you also have to think about how can you economize what the agent is doing because in in many cases it can send that whole let's say history chat history or the history of what the agent's been doing along with the context of every step and you know the bigger the context the more tokens the more tokens the higher the price so i think we just really need to be aware as we're in a very interesting time right now where we may be moving you know on the commercial side to more usage-based pricing and that will probably directly impact what you can and can't do with agents so and additionally misbehaving agents may contribute a lot into this cost factor as well because they are stuck on on a loop to get something done because they want to get their target is to get is to achieve the goal that they are set with and like for example let's say you have mcb that connected to the agent but the agent does not have the tool access at the runtime but agent might keep working around that and contribute to eating up your token budget as we like so in terms of access management also we have a role how we set up these policies and how we make these tools available through the agent so that so we we don't end up misbehaving agents contributing to our cost factors and again so as you mentioned the ai gateways a good monitoring point and because we need and it helps us routing routing different the different types of agents into different types of models as well and then again it goes back to the agent identity as well so you when you have identity so that when the agents are making call a llm call we can intercept that at the ai gateway and by looking at the token you can get an idea about what's the agent that's acting at this point and then apply different policies as well as apply different routing to different agents as well and also monitor traffic patterns based on that you can rate limit agents as well so so ai gateway plays a major role in the in terms of cost test cost management as well so at our last major slide we'll just say in summary ai agents are really a new different type of identity we need to keep in mind the four a's administer authenticate authorize and audit and now is the time to do something about it before it really takes off and got a couple of minutes left i want to look at the poll results real quickly so um how does go back to the beginning are you using enterprise is your enterprise using ai agents today 60 say yes they're in production 20 say not yet but planning and then 16 say yes in pilot or proof of concept but i can't only four percent say no plans the next question was which best describes your primary agent use case 50 say internal productivity about 30 say autonomous workflow or process but interestingly only about 10 say customer facing like support or sales and then lastly how does your enterprise manage identities for ai agents today not surprising 42 really don't have a formal identity management plan 20 are unsure so that's i think that's good we're having this discussion today so we have a couple of minutes or a minute let's take the top question here we've got how does a developer know when there are enough standards and when they are consistent when built by different organizations you should you have a quick answer on that one at this moment it's very hard at this moment it's very congested and everybody is trying to figure out solutions as well but eventually i think we will like industry will settle keep innovating and land somewhere better but even right now it's a bit it's everything is moving around the domain yeah yeah i mean i get the point about enough standards we do have lots of standards in iam and security worlds and well the good news is there i think we can use some of the existing standards we see where some of the gaps are and then we can also there is work in progress right now to try to address some of these capabilities that need to be built and even though some of the work has been done by vendors themselves there are cases we've shown where the vendors have moved to neutral standards bodies and i think that's probably the best place to look at some of these neutral standards bodies for developments of standards that that are going to help us with agentic ai and with that we're out of time but thank you thanks to everyone who's attended if you have any further questions please feel free to get in contact with us and thank you aisha for being part of this today thank you everyone thanks thanks