Hi everyone. Good afternoon.
So, I'm Janak Amarasena. I'm with WSO2. I'm a technical lead over there.
So, I'll be talking on why IAM is essential for AI agents. So, we are deploying smarter, faster AI agents every day. There are autonomous agents that are running 24-7. Then there are agents working on behalf of you and then with MCPs.
Now, the barrier for the service providers and the agents we connected is gone. And now more and more capable agents are coming in.
So, are we really building the nearest security guardrails at the same speed? So, there's research I found online.
So, it says the global agents market generated a revenue of 5.4 billion in 2024. And it's projected to hit 50 billion at 2030.
So, with the pace, the innovative pace that's coming up, I think it'll be even more. I think we can all agree that agents aren't going away.
So, the only thing that will change is the nature of the agents. They'll keep on evolving.
So, we must build the necessary guardrails in place so that we can secure these agents. So, I'm pretty sure that you all know what an agent is. But just to put some context for the next set of slides I have, let's walk through what an agent is.
So, an agent, an AI agent, it's attached to an environment. Guys, I lost the screen here.
Okay, thanks. Sorry about that.
So, like I said, an AI agent is attached to an environment. So, at the core of it, you have your generative AI models. And it will have its own knowledge base. And you'll have access to a bunch of tools. And then maybe based on the behavior of the agent, you could segregate it to three categories. You have your autonomous agents. There are no users involved at that time. It's fully autonomous.
So, you tell the agent a task. It will keep on running until it's done. And then you have your interactive agents.
So, these are your users present at all times. So, these are like your chatbots, copilots, the users there. And then you can have your hybrid agents or semi-autonomous agents. What happens here is the user will tell, okay, do some task. But the agent will do it at a certain time in the future.
So, since we have the context. So, let's see. One of the most important things before you put in guardrails, you need to identify an agent.
So, when we were building these guardrails, we thought, how can we identify an agent in the system? So, we looked at the existing constructs.
So, some of these constructs could sort of match an agent itself. So, if you take a user.
So, the agent itself will need some identity. And it will have some entitlements. But it doesn't quite fit the other use cases of a user.
So, the user will have its own life cycle. There are different authentication mechanisms.
So, it doesn't really fit well. Then when you take applications.
So, this could quite fit an agent's profile. So, if you take from the traditional OAuth sense.
So, if you are dealing with a normal application, you are basically delegating your authority or delegating your access to an application to work on behalf of you. But it's a bit different.
So, in an application, you have a well-defined boundary. And actually, the end user is in control. But when it comes to agents, it's not quite like that.
So, you tell the agent to do something. It does its own reasoning. And it does some actions.
So, you need more tight access control needs. And also, agents itself will have some attributes, right?
So, you need to represent, okay, which model it is. And which version of it.
So, who owns this agent? What is the purpose of this agent? And you'll have more complex authorization policies.
So, then a workload could also fit in. Maybe for autonomous agents, it might fit in well. But it has runtime identities. But it doesn't really work with interactive agents.
So, what we believe is the agent needs its own class of representation. So, this will help you to identify an agent very clearly and visibly within the system. You can do all your tailor-made security controls. It will make it much more easier. It will have its own life cycle.
So, how you develop, deploy, decommission the agents. Then representing whether the agent is acting on its own behalf or on someone else's behalf.
Then, like I mentioned, you need to have very strict policies in place. And very, very important is you need to be able to identify the actions that were performed by the agent. It's actually by the agent and not by the user who was actually doing the prompt or who was in control.
So, since we have established now that we need to do a first-class representation, let's go ahead and see what sort of access controls are needed. So, the fundamental things that we need to think about when we are developing or deploying agents.
So, interestingly enough, I was a bit surprised when I saw this. This was announced last week.
So, MasterCard unveils AgentPay. So, at least for me, this is a significant milestone in agent adoption. Because now we are essentially trusting our financials with agents.
So, you wouldn't really go and give your credit card to some stranger and say, you know, I want you to do these purchases, but just that. But then, if he goes and does something else, maybe with a human, you could do some controls. But with an AI agent, you really need to have these guardrails in place.
So, again, it was very surprising at this stage that we are getting access to our financials through agents. But maybe sooner than we expect, we might see agents accessing critical systems as well.
So, guardrails are going to be very, very important. There are three fundamental things that you need to think about when you are developing agents. You need to give only just enough access, and just-in-time access, and you really need to be able to audit these things.
So, let's drill down these things. So, just enough access.
So, the agent itself is non-deterministic. So, it means you can say, okay, go ahead and do this.
So, what happens is the agent will reason on how to perform the action that you told, and it will exceed the rules. So, you need to make sure only minimum essential permissions are granted. And not only that, so, there's two problems here. The agent itself can be non-deterministic, and the agent can be compromised as well.
So, we have had, like, what, critical systems being compromised. So, agents itself is not shielded with that.
So, giving only the minimum essential permission is very important. And also, you need to use contextual access control as well.
So, let's take a little bit of example on this contextual access. Say now there's an organization. To enhance efficiency of the employees, they are building an organization's AI assistant.
So, this AI assistant could essentially access all your, what, records, emails. And it's built for the employees to, like, quickly search something, and it will give you directly what they need.
So, in an organization, you could have different user groups. You could have your employees. You could have your consultants. You could have partners. And even these user groups would have subcategories as well.
So, the partner should not have access to confidential data. Likewise, so, you need to make sure you're built in the necessary access controls.
So, how can we do this? So, one thing is, you need to grant only very needed scopes. It has to be very declarative. And the other thing, very important thing, is using access control models, like attribute-based access control or relationship-based access control.
So, there's no one-size-fits-all solution. So, it depends on the use case that you're using.
So, you need to have the proper access control models in place that will fit the particular need. So, even if you're giving just enough access, that itself is not needed. It's enough.
So, agent will be connected to many tools. Even if you give just enough access to all these tools, that's not really needed, right?
So, again, agents are non-deterministic. So, say, once you grant the access, we may not be able to really control it.
So, what needs to be done is you need to give access at the exact time that is needed and make sure that access is revoked after that particular task is done. Let's take another simple example.
So, you have a personal assistant available. And then it's connected to all these tools.
And, say, you want to do a holiday planning. And you say, OK, do a booking for me.
And, OK, the agent does its reasoning. And it goes and, OK, it finds out, OK, you need to do a flight booking, hotel booking, add this to your calendar. But what if, during its reasoning, it thinks, OK, I need to do some groceries, do some payments, all these things.
So, if you have already given the access to that, you can't really do anything. You can only react after the fact.
So, just-in-time access is very important. So, how can we do that?
So, this depends on the nature of the agent as well. So, in the beginning, we spoke that there can be, like, three sort of agents.
So, let's talk about interactive agents. So, these are the agents where, like your chatbots or copilots, where the use is always present.
So, there's no real need to give preauthorization. So, at the time the agent is accessing some particular tool, it can prompt you, and then you can give the access.
So, you can use protocols like OAuth 2.0 authorizing core grant. So, this is actually the protocol that's recommended and being used with MCP as well.
And then, if you take semi-autonomous agents, like I said, so you can say, for example, OK, during a certain period of time, check for the lowest available value and do a purchase for me. So, what happens is you give the prompt, and the agent is going to be active for a certain period of time. When it thinks this is the lowest value, it will say, OK, I found it. Authorize me.
So, you don't really need to authorize at the beginning, right? Because it happens at a certain period of time.
So, for that, you could use the OpenID Connect grant initiative back channel authentication as well. And it's very important to do the authorization.
So, you could use rich authorization requests in conjunction with it, and really lock that transaction to a very specific thing that you want to do. And when it comes to autonomous agents, there's no user present.
So, the agent is doing everything on its own. For example, you say there's an agent that is running a periodic task. And then you know that the agent is going to execute this at a very certain period of time.
So, you should have contextual authorization in place that the authorization is only granted at that very specific time, not before, not after. So, these are already things that we have in place available to us today. It's just incorporating them at the right place.
So, the next important thing is auditability. So, whatever agent does should be auditable.
So, if it's autonomous agents, we already know the identity of the agent. Everything that agent does is actually going to be that agent. But this becomes very important with interactive agents.
So, the agent is going to act on behalf of the user. So, the agent by itself could misbehave.
Like, it does its reasoning like we told, and it can do something else. And also the agent itself could be compromised as well.
So, end of the day, when you go through your audit trails, it could be the user that's liable for this. This also opens up an interesting vector of attack as well.
So, internal bad actors can do things and now blame the actions on agents as well, because now you can't really audit it. So, the closest thing we can have today from standards is OAuth 2.0's token exchange. You can have on behalf of flows.
And, as I know, the community is working on better standards that fit this use case as well. So, keep an eye out for that.
So, I truly believe we are still at the very beginning of things. So, not long while ago, we were just dealing with one-shot prompts, like ChatGBT.
And then, in some time, we had AI workflows. So, both of this, even when we had AI workflows, we had a control. We know what are the exact things that the agent is going to do, the workflow is going to do.
But, when it comes to AI agent, it does its own reasoning and we lose some of the control. So, that's the point where we are at now.
So, all these things happen maybe, what, three years? If you take the technology, it's a very short span of time, right?
So, we don't know what will come for the next month. I don't think it's years. It's going to be something in months, whatever the next thing is going to come up.
So, we need to make sure that we evolve the guardrails in lockstep as well. We must do that.
So, that's exactly what we are doing at WSO2. We are building the required guardrails such that anyone who's developing agents doesn't really need to worry about this. We will provide the guardrails for you, so you only need to worry about your business application side of it. Thank you. Thank you.