Why Classic IAM Collapses for Agents: Rethinking IAM for Agentic Systems - Parul Singh, Red Hat

This talk examines the limitations of classic identity management (IM) in accommodating modern autonomous agents and discusses the need for a new agent-centric identity management approach. The speaker highlights the distinction between traditional agents and the next-generation agents that operate autonomously, emphasizing that classic IM is ill-equipped to handle the dynamic nature of these agents that require contextual authorization and ephemeral identities. The discussion introduces concepts like token exchange, delegated authorization, and the importance of unique agent identities, illustrating how these elements can enhance security and functionality. The speaker also provides a matrix guiding the implementation of security measures based on agent capabilities and risks. Overall, this session outlines foundational principles for developing an agentic IM that supports dynamic agent behavior while ensuring robust security.

Today we are talking why classic IM collapses for agents and let's rethink how we can design IM for so let's start with the world has changed right uh anthropic research told or found that clot changes it behavior when it thinks it's under evaluation and Alibaba AI agentic system went on cryptomining it was wasn't instructed it was just an autonomous agent with access on tools that went on

a side quest. So the world has definitely changed and uh the reason is agents are not users and agents are not static services. They are something new and classic uh take into account how these agents behave. So if you look into this table uh L0 to L2 agents we have been writing these agents historically we they are usually fixed fixed scripts they are chron jobs they are

schedule jobs they are rule based new and classic IM works for it because it creates a service accounts and it distribute that service account to all the agents and that works fine but if you see from L3+ that is where things doesn't work in classic IM because these are agents that reason, plan, delegate and uh they just talk across organizational boundaries and for these agents you need

a full agentic IM that includes ephemereral identities on behalf of delegation semantics and contextual authorization and continuous evaluation. I'm going to talk on behalf of delegation and contextual authorization later on. But these are the new foundations for agentic uh a IM. So why does classic IM does not work? Well, classic IM has no good questions for the three things that the agents need. What is classic IM?

just creates one service accounts and it distribute amongst all the workloads and it does not even answer who triggered this. Is it an user or an agent acting on behalf of user or an agent acting like on its own like nobody asked it to do anything? And at last uh should access when agent behavior is changing midexecution because agents they just call other agents in their agent

runtime and they change behavior. So a training agent can start writing to a model registry. So uh in classic IM you validate or you authorize at the gate and that's it. And so that doesn't work in uh agentic IM. So let's consider the scenario. We have Alice who is a data scientist and she launches this ML training pipeline something she is just doing um all her data

scientist career. And it is nothing new. She has done this hundred of times. But uh here we have five agents. The orchestrator agents that plans and delegates, the data agent that reads the feature set and the training agent that trains the model, eval agent and deploy agent so on so forth. So there are five agents and have the same service accounts. They have the same identity. And

uh so let's see what happens when uh when five agents sharing the same service accounts but having different resource requirements and different permissions uh operate. Okay. So let me log in with Alice and uh I will run this uh ML pipeline. So I have a data agent uh feature set and let's see what if this agent wants to also wants to write to the model registry. Oh

my god, sorry about this. Yeah. So let's run the classic IM where the data agent that only needs read scope but it's tries. Yeah, this works. You can see you got 200 but this doesn't seems right. Something that is very off over here. And even though data agent is not supposed to writing to model registry, it's only supposed to read feature set model registry. And your classic

IM does not stops it. And why is that? Because there is just one service account that has all the scopes that Alice has and it's getting passed downstream the agent. Let's see what happens when you run this in agent. Well, this doesn't work. There is a 43 stops it. The cool thing is the agent code is same in both of them. In both the scenarios, the classic

IM and the agentic IM, we have the same agent running. The only thing different is how we have configured identity and how we are taking care of authorization. So let's go back to see why the classic well the first thing it breaks is we don't know who did it. All the agent have the same service account. So you cannot say uh was it the data agent or

was it the training agent that was trying to write the model registry. And I'm pretty sure some of you are thinking well if I give all the agents and fix their scopes this should fix it like we don't need to do something fancy right well it will solve part of the problem and it's a good step in the right direction but it doesn't solve everything because you

see all the scopes that you're getting every agent they are very overprivileged by default. So Alice uh scopes read, write, provision GPU, write to production and the orchestrator that uh just orchestrated this pipeline inherits Alice scopes but the data agent also inherits Alice scope so did the training agent and the data agent shouldn't have uh writing to the model and the system didn't stop it. So we

uh if a data agent becomes rogue a system has no check on that and at last we don't know who is acting on behalf of whom. There's no delegation semantics preserved. So this is why classic I am too good for agentic. Why? Because it assumes things for agent that is just not true. It believes in longived identities. It will create service account and it will share and

they will go on for weeks sometimes months and sometimes even years but that is not good enough and that we set we set at the deployment time and these are static permissions but in agentic when an agent is creating sub agent uh the permissions depends on the context of what is going on between agent A and agent B so we don't preserve that and as I said

we just authenticate once and then we just believe that but that's not the case. So uh agents are very different in fact they're opposite of what classic IM does. They need ephemeral per agent identity which is unique and it needs to be cryptographically verified by the platform and the second is it has away authorization and the scopes should be narrowed at every hop. uh when the agent

is calling the downstream agent, it should always call with narrower scopes. And at last, you need continuous evaluation. You need to not just see if the token is valid, you need to also check if the agent is still running boundary uh if it has crossed it trust boundaries or not. So we solve these three gaps by three pillars which is identity and delegation, discoverability and observability. And

let's fix identity first. So every agent times I will say the sixth time again every agent needs ephemereral unique identity that are short-lived and the platform should be able to cryptographically verify it so that an agent cannot just create self credentials or it does not uh forge other people credential and this is where comes into picture which is secure production identity framework for everyone. It's an uh

prod graduated CNC project and it defines uh a URI like identity. So you can see that every agent gets a URI identity over here and short-lived SV ID which are like secrets or certificates if you call it and it automatically gets rotated so you don't even have to think about oh I got to change it as certificates it already takes care of that and at last the

identity is not configured it is attested by the platform to prove the and know for sure that nobody is uh creating false or forging credentials. So in classic IM you see all the tra agents have the same service account but in agentic every of them have a different uh identity uh make a creating identity is not enough. You also need to register agents and every agents must

be registered before they participate. And for registration you need to make sure three things are happening. There is a registration entry that maps the agent workload to uh the ID that we created over here. And you need to have a key client uh that is bound to this PFY ID. And you need to sign agent card because agent uh declares their capability by uh at a uh

listing the known uh URL and if the agent card is not signed you cannot uh you cannot tell for sure that the the agent is claiming what its capa capability is and I'll come to this point later. So right now you just need to think that if the agent is not registered at all the three areas it should not be able to obtain token and it should

not be able to participate in and there's no way to sneak in. You cannot just sneak in and do something. Okay. So that fixes identity but still something is missing. How do we narrow scope and how on behalf of semantics and that is where delegated authorization comes into picture. uh there's an RFC8693 that list how you have to do delegated authority uh authorization and in the classic

IM you see all the service account had the same scope but uh what we do ination is we do token exchange and over here you can see that the subject or the calling principle is Alice uh the actor is the orchestrator agent that is acting on behalf of Alice and it requests for a narrowed scope scope of tokens which only has read feature and it is is

a data agent or the downstream agent is data agent. So orchestrator is using this token and forwarding it to the data agent and the data agent has a right scope to access whatever it is supposed to do in the pipeline. Uh but there is a gap in the real world over here. Keyclo does not implement delegated authorization the way it used to do. Uh it should be

it should be doing. So uh we created a custom keycloak plug-in and there's already issue open in keycloak and people are looking into it. So it's a known issue. So what we have done is we have created a custom keycloak plug-in and what it does it's narrow scope the requested scope with the available scope and this way the scope will always narrow it will never expand. The

next is we also inject the act claim like over here keylo does not take care of this this whole thing key click will just request a token and we will have the subject. So what we do is we claim and what actor claim is it preserves on behalf of semantics. So you always know who was the caller the principal and who is acting on behalf of the

caller. Uh and if agent A calls further agents then this part get nested. You will have multiple actors. So you can always reconstruct who is who is acting on behalf of who using uh delegated authorization. Um and as I said the thing that I like is we are not changing any agent code. So you can bring your own agents to the platform. All you need is a

sidecar proxy that does all this thing and I will show the uh archite don't get it's just like a very normal sidecar proxy that does a lot of stuff but your agent stays the same. Okay. So that solves identity and authorization. Now the next question is how do agents discover each other? As I said, agents do not discover each other by hard-coded DNS each other by asking

capabilities. Like if a orchestrator agents want to train something, it will say, "Hey, is there a training agent?" And a training agent can just say, "Yeah, I'm the training agent, but can you trust that?" So, it's kind of like a business card problem. Anybody can have a business card and say, "Hey, I'm a cardiologist." Prove anything. It's the same scenario in the agent case. Anybody can say

I'm a training agent. But how do you make sure that they are who they are? So to do that we have three step of defense. The first is you bind the agent card to the speedy ID that we have created and you sign that agent card with the spire. Somebody uh changed the agent card or puts wrong cap capabilities the sign will break and you uh the

whole system will stop at that very level because it's tempo evident. And at last at uh you have to enforce at the caller runtime the MTLS ensures that who you are proving what the agent card says you are. You cannot just uh create your self claim and everybody will start believing you. No, it has to be the agent card has to say who you are and it

has to match with your identity. So that's how we uh handle discoverability. We need to have observability and tracing because if you can't see the delegation change, you cannot trust it. So you need to have telemetry spans at every hop that emits telemetry data and using those telemetry data you can uh just reconstruct the whole delegation and why we do that so that you can things on

demand. So let's say something went wrong. After the fact we have enough audit logs that we can answer which agents was active in this workflow, who was acting on behalf of whom and what policy justified this workflow. So uh you get an accountability chain that is uh evident and this is how the delegation looks like. You have the principle that is Alice that calls the orchestrator and

you see over here that Alice has delegated to uh orchestrator has delegated to data agent with narrow scopes and then orchestrator to training agent with only the scope that training agent need create the whole delegation chain. So this is the agentic IM. Uh we have uh at the top we have the identity layer where spire issues identity and keycloak does token exchange and every agent has two

things in this scenario assigned a sidecar proxy that verifies and exchange tokens. So the agent codes remains unchanged but uh we are ensuring the other IM components using this sidecar. So if you see that the scopes are always getting narrowed it never expands. The orchestrator has the most scopes but all the downstream agent it calls it is being that they are needed. Okay so let's just go

over why agentic IM worked. It worked because every agent has its own unique ephemereral ID which can be cryptographically arrested. We are preserving on behalf of semantics. We always know who is acting on behalf and we always start with least privilege. We uh we uh in our agentic IM when the data agent is buggy or it is getting rogue or it's compromised or it misconfigured it cannot

write to model registry like it could in the classic IM and at last you can have a full delegation change. So yeah this is like the right model is not in the scope. So in classic IM this works but in agentic IM this will fail. Okay so this seems like a lot but not every agent needs a full agent take IM stack. So that's why we have

this matri matrix you need to see what your agents do and according to that you need to amp up the controls. So for example, if you have a low cap capability and lowrisk agent that only does FAQ lookup or only answers baked in responses, then you don't need a whole semantics and you don't need to preserve delegation chain. In that case, you just need very narrow scope

service account and basic logging. But if you have agents that are high capability and low risk like a data agent and eval agent so they act within a very constrained environment usually internal just need shortlive tokens and anomaly detection but if you have low capability and high-risk agents and these are agents that rarely do anything meaningful but they act as really sensitive thing like imagine healthcare data

or imagine PI data. So in those scenarios you need environment and just in time credentials and at last if your agent is high risk and high capability then you need the whole agentic stack. There's no another way around it. You need to have uh on behalf of semantics token exchange context away authorization and human in the loop also in caseical. So what this matrix does is it's

telling you what kind of control strength you need to apply but it does not rule away. You always need to have agents registered and monitoring that is non-negotiable. So if it all seems too much because just remember everything is already there. We have spire keycloak uh you can use open telemetry for telemetry and all these are a graduated project. So what we need to do is just

layer things in a way that we are preserving all these semantics. So if you uh are someone is someone someone new in agentic workflow what you need to do is as soon as you introduce agents in your workflow you need to make sure that they have identities and they are registered. You have to eliminate shared account. That is the first step and uh the outcome you are

thinking of that they all eight Uh once you do that each phase is cumulative. So you can move to the next phase which where you have contextual access or uh as I said you need to narrow scopes at each hop. You need to have a token exchange. you need to preserve uh on behalf of semantics and phase one phase two then you should just have the full

agentic IM where you are the outcome you should think about can I prove something on demand do I have enough information enough telemetry enough audit logs that if something goes back or I'm getting audited I have I can answer the questions so that should be your outcomes there should be workload outside the control plane and you need to sign the agent cards You need to bind agent

cards with identity. You need to provision automated discovery and anomaly detection and also have human in the loop for critical scenarios. So yeah that's it like we haven't solved everything we are of stuff. These are the open questions that we are still finding the answer to. And uh what I really want to emphasize that agentic IM does not create new stuff. It just builds up on or

extends existing infrastructure. If you want to get involved us in COSIA which is a coalition for secure AI um and please find the link to join COSI. It is where we make agentic design patterns, agentic security guidelines and we are also working to make the zero trust foundation of So you can uh read the blog uh it gives you very much in detail what other zero trust

principle you need to have and at last uh you can follow what aent tech IM work is getting done at Red Hat. Uh we have I have listed our project so yeah feel free to get involved and some time we can go for questions if anybody has. >> Yeah. That's what we mean by ephemeral it's for the same reason like we don't we don't want to uh

have long lives uh agent that started doing with something it can do something very different in the mid execution. So you only give it tokens or secrets for that particular thing that it's doing. As I said maybe the agent started with training feature so you gave it the training scopes tokens but mid execution mining as Alibaba uh agent did that so you don't want to do that

so that's why we have to rotate these uh identities or the tokens and you have to keep them shortlived so that the scopes are very limited and it's never overprivileged. Um so we are just rotating ID for the safety net but when we re-evaluate uh if the token or if the scope that was granted to the agent is it still boundary that's that's re-evaluation but the rotation

is just for extra safety. uh as of now you do that manually. You rotate your secrets manually or you create a new API token and you put them. So this is all manual but if you use spiffy this all is done automatically but I the the whole point of this talk is we are not trying to say use this or use that. These are the design concepts

that you need to be aware of and uh there are many tools that does the same but these are the most easy to work with. Yeah, I got to stop. Any more questions at the venue?