A Blueprint for IAM in the Age of Al Agents

All right, good morning. OK, my name's Adam Rusbridge. As per the introduction, I'm a group product manager at Ping. I've been with Ping for about 5 and 1⁄2 years now. And across that time, for the majority of it, I've been responsible for our authorization initiatives. But about a year ago, it was about 18 months ago that we really started paying attention to the Identity for AI activity. We were like, this is coming. About a year ago, I pivoted and expanded my role and took on the Identity for AI solution and offering.

And I've spent more or less the last nine months on the road talking to different customers about what they're seeing, what's happening, the problems that they're trying to solve. So today, I want to keep it fairly simple. I just want to share a little bit about Ping's point of view and how we're approaching this Identity for AI space. All right.

OK, so we can start super simple, right? What's an AI agent?

OK, I'm pretty sure everyone here will understand these things, right? An agent, it's an application. It's a workload. It's got a couple of characteristics around it. We've got a set of prompts, the persona of the agent. I'm an insurance agent finding the best deal for my customer. There's the LLM itself, the brains, the reasoning around it. There's the memory that makes it seem conversational in tone and in nature. Then most interestingly, there's the set of tools that connect out to a broader ecosystem, right? And the key thing here about this agent is the non-deterministic nature of it.

So historically, we've had an application. We've given it a set of inputs. We get the same set of outputs every time.

But here, we've got this non-deterministic actor. We give it a set of inputs. We get a different set of outputs. And that changes how we think about things like security. So to get smart, as I said, agents kind of expand their worldview. They need to start interacting with tools and data and services and so on, right? And it's this interactivity that means that identity is central to AI agent success. And so we can kind of see here, right? We need to make authentication decisions, authorization decisions, about what this agent can and can't do.

Straight away, that means that we need to be able to give this agent an identity, right? A unique agent identity.

Now, we've kind of moved from a two-actor model, where we had a user interacting with a resource, to a three-party model. So now, we've got an agent acting on behalf of a user interacting with a resource, right?

So now, we've got this notion of delegation that we need to put in place, OK? So straight away, all of these new identity-related aspects that we need to think about.

Now, in the MCP protocol, in the 808 protocol, they're aligning around OAuth as an identity mechanism that we can use there, right? That's great. That means that we can leverage the identity foundations that we already have in place. But we've heard over the last couple of days, there's a whole load of new enhancements, kind of elaborations, profiles, whatever else it might be that are needed to make this work at scale.

Now, one of the things that we see is a lot of organizations coming to us. And they're saying, right, we've got agents. We need to secure them. What do we need to do? And actually, we found that we needed to break down our approach to agents into this kind of taxonomy that I'm going to talk you through so that we could understand the appropriate identity problems that needed to be solved at a particular point in time. And the key thing here is that not all agents are created equal, right?

Depending on where they're coming from, what they're trying to accomplish, there's a different set of identity controls that we need to put in place. So we can start on the left-hand side with these personal agents here, right? So you can think of this as a chat GPT, like running on my phone and my device. I could think of it like OpenClaw, for example.

Again, running on my device. But the key point here is that this agent is outside the enterprise perimeter. It's unmanaged by the enterprise. It's unknown to you. And so there's a set of considerations we need to think about there. Then on the right-hand side, we've got these two forms of managed agents. So in the middle here, we've got this notion of digital assistants. We can kind of break this down into SIAM and workforce use cases.

On the SIAM side, we've got this notion of customer service agents, where into our apps, into our websites, we're building out these assistants that are going to help a customer get a task done more efficiently and more effectively, right? Or on the workforce side, we've got these employee productivity agents, where there's a set of tasks that have been done manually by one or more employees, and we're trying to automate, right?

However, digital assistants are always going to be acting on behalf of the user. Then on the right-hand side, we've got this notion of digital workers. And I think of this like an intern, right? I onboard an intern. I give it a limited set of responsibilities. I supervise that intern, OK? So this is kind of where we've got an agent acting autonomously under its own identity, but we need to think much more strongly about how we're going to supervise and monitor that agent's behavior over time, how its trust and our trust in it may evolve. All right.

One thing that was consistent that we found is a set of best practices that apply across the estate, right? So if we start on the left-hand side, it's really important to have an inventory of agents. A lot of organizations right now are struggling simply with the visibility of what's happening across the estate. It's like the Wild West out there. So we need to know your agent, know those agents. We need to have a kind of a canonical registry where we can identify and classify those agents of different types, either inside the estate, deployed and managed, or outside coming in, right?

We need to be able to detect and discover those agents. So again, perhaps that's computer-using agents that are coming in from outside the estate, or it's those agents that we've deployed across our infrastructure, like AWS or GCP or Azure or whatever, right? So we need to detect and discover those agents. We need to use methods like delegation and not impersonation.

So rather than sharing credentials and having the agent acting under our human identity, we need to, again, as I said before, use that explicit notion of delegation so that we can then enforce least privilege and differentiate between what an agent can do and what a human can do. And then finally, we need mechanisms to bring a human back into a loop at the appropriate time, right? And there's different ways of accomplishing this.

There's automation, there's guardrails, all of these things that we need to put in place so that we don't fatigue a human operator, but ultimately we need to bring that human back in the loop at an appropriate point in time. So delegation, what does this mean? I'm in a room full of identity experts, so I'm not gonna belabor this point, right? But we can look at the token on the left-hand side. We've got those first five claims that might be produced by a regular access token, right? The audience, the issuer, the subject of the human.

And when we go through a token exchange process, we exchange that regular access token for this on behalf of token, we put in place an actor claim with the subject of the agent. We do all of that so that we can make authorization decisions on the right-hand side there. Like digital assistants can access banking services. Maybe we want to limit that to the finance system and not the HR system. Maybe we want to make sure that we've got explicit mechanisms to assert consent, right? John has given this digital assistant consent to act on his behalf.

Maybe we want to downscope and narrow what this agent can do as opposed to what a human can do, okay? So we've kind of, here we've got this notion of getting tokens on the left-hand side so that we can use these tokens in front of the resource servers on the right-hand side.

All right, I wanted to talk through what we actually see in practice then. What does this mean as we start to think about this from an architectural perspective?

Now, the important thing here is this notion of the trust boundary that's running up and down here in the middle of that slide, right? And so on the left-hand side, we can see this agent that's outside the trust boundary. This is a personal agent's use case. This personal agent is trying to interact with a protected resource through the MCP protocol, right? So we make that access request in number one. We don't have a token at that point. We get redirected back to point to the authorization server.

And we can see in number two here this notion of dynamic client registration, client ID metadata documents, all of that kind of stuff, right? And that's important if you were to read things like the MCP specification. That's important because there is no trust relationship between the agents outside the enterprise boundary and the authorization server itself, right?

So that step there is necessary so that we can form that trust relationship between the agent and the authorization server so that we can then go through that OAuth code flow in step three, get a user's access token, so that then we can make a successful request in number five there, right? So that's kind of the personal agent scenario here. A lot of it's been sort of driven originally by this notion of agents living outside the estate. Then we can look at personal agents that can also interact with web estates, right? So if I was to go to ChatGPT, I can instruct ChatGPT to use Atlas, right?

ChatGPT Atlas, Perplexity, something like that, to navigate to a website, to authenticate, you know, as me, and start navigating around a web estate. And so the flow changes, right? Once again, the agent is outside the trust boundary. It's outside that perimeter. And so here, once again, we make this access request. Now we don't need to have that trust relationship between the agent and the IDP. We go through an OIDC redirect, right? What we're starting to see in step three is that, you know, at this point historically, organizations have put in place bot protection controls, right?

They would have detected a bot, they would have blocked the bot. That's what we did before, right? Detect a bot, block it. Now we need to discern between good bots and bad bots because we're going to increasingly see these agents interacting with our estate, and we need to differentiate between good bots and bad bots. So we're seeing this notion of computer-using agent detection emerge so that we can then direct the agent down an appropriate authentication pathway, right?

Kind of a distinct journey from what the human user would go through so that we can go through, for example, an out-of-band user authentication step where we're confirming with the user that they do actually explicitly want this agent to act on their behalf, right? So, you know, we do all of that. Then we get an access token or an ID token that we can see in step five there. All right.

Now, that's personal agents, okay? When we start talking about these managed agents, the scenario changes again a little bit, right?

So, again, folk have come to us. They've said, let's talk about agent identity. What's an agent identity anyway, right? So we need to think about the layers at which identity needs to be managed inside the enterprise estate. So we can start at the bottom, at the device and the machine and the network layer, right? I spent some time last week on site with a customer that has a multi-cloud strategy. They were like a large organization. They had a multi-domain, multi-cloud strategy. Across their different clouds, they had different IDPs protecting them, right?

So we need to have, again, this mechanism to express trust across these domains and across networks. What we did before was like IP address and poking holes in firewalls. That's not going to scale. That's not going to work here. Then we move up to the workload and the infrastructure layer, right?

You know, we're seeing an increased focus in how we can limit or explicitly allow actors in an agentic ecosystem. So using things like Spiffy, for example, so that we can manage the agents, the MCP servers, the APIs, the applications that we want to allow to participate in an agentic ecosystem, right? So we've got this layer of workload identity that's kind of coming to the foreground. Then we move up and we're starting to talk at the API layer, kind of inter-agent, inter-entity communication, right? So it's great.

There's a lot of great work around OAuth and how OAuth needs to change and evolve to support activities. But there's this legacy mess where a lot of service-to-service communication, right? Post-firewall, there was all this service-to-service communication where we had all kinds of communication methods. We're still relying on API keys, on client secrets. We can't have these agents having access to these things because of that non-deterministic nature that I was talking about before.

So again, we're going to need to manage these API keys, these client secrets. Ultimately, we want to move everyone to OAuth, but we need to recognize that we've still got this problem that we need to manage. And then finally, at the top here, we've got this notion of user and service accounts for digital workers where these autonomous entities actually explicitly need to have identities inside these systems that need to get managed, right? So we need to manage all of this stuff here.

So again, what does this look like, right? When we start thinking about digital assistants, the trust boundary changes a little bit, right? Now we've got the agent inside the trust boundary. The human user, the consumer of this agent, might be outside. So we start on the left-hand side.

You know, the human is interacting with the app, with the web estate. They authenticate. They get an access token. They invoke the agent, right? We can see here in number three, the agent now has a trust relationship to the IDP. So we can use something like Private Key Jot or Spiffy, sorry, SVJots to authenticate the agent to the IDP, right? That's kind of where this workload identity piece comes in.

We can go through a token exchange process where we're taking the user's access token in 3A, we're exchanging that for a transaction token or a delegation token in 3C there, where we've got these two identities inside our system. We can invoke the tools, right? And this is where we're seeing a lot of demand and purpose for an agent gateway layer that's either sitting in front of something like an MCP server or in front of APIs that this agent might be interacting with directly through its configured tools. And there's two functions that this gateway is really facilitating.

One is an authorization check, right? We're kind of making that fine-grained authorization decision in step five there. So essentially looking at those three actors in the system now, right? Can this agent act on behalf of this user when interacting with this resource? And that's important because it's frankly too expensive to recode all of our authorization logic in all of these services and systems on the right-hand side here. So it becomes very natural to sort of abstract this out and use a combination of a gateway and an authorization service to facilitate that.

And then we've got this last mile of authorization where we're connecting to these final backend resources that might have all of these different authorization patterns. We maybe need to perform credentials injection so that we've got this last credential that this sequence of interactions finally demands. And finally, there's this notion of the digital worker, right? Behaves similarly to a digital assistant. The difference here is that the agent, as I was describing before, the agent's autonomous, it's acting under its own identity.

So there's a much stronger notion of lifecycle management here, right? We need to onboard this agent. We need to give it a set of responsibilities. We may need to off-board it. We need to supervise it over time. We may need to escalate its privileges. We may need to go back to the owner, the human owner, or a set of owners in a much stronger way so that we can approve its actions, right? All right.

So, look, that's just a whistle-stop tour of the architectural patterns that we're seeing. And we have found that it's been really important to be able to break down those different architectural patterns as we talk to organizations and start saying, right, which of these problems are you actually trying to solve? Are you trying to enable agentic commerce, right, where you've got these consumer agents outside your estate coming in? Are you trying to facilitate employee productivity or introduce a customer service agent, right? Are you trying to automate your processes and activities, right?

And this then allows us to then think about not just one narrow slice of it, but really the whole architecture. How is the organization's architecture going to need to transform in order to support the new agentic era that we find ourselves in?

So, you know, really, across that, we can organize that into four key challenges that our customers are really asking us to solve. So the first is really around these concepts of authentication and authorization, right? Fundamentally, how am I going to authenticate agents to ensure the delegated access model that we're talking about? How are we going to have these agents communicate across trust boundaries, right?

You know, there's excellent work that's going on to support and evolve the standards in order to support this. How are we going to define these least privileged access controls for agents and users? There's the notion of agent and resource management. How are we going to register and manage agents inside our identity systems so that we've got this comprehensive registry of them so that we can map the access controls between them, ultimately building up this picture of users to agents, agents to resources, right? That's really kind of the goal that we need to have there.

We keep hearing that it's the Wild West out there in terms of MCP and resource security, right? People are creating MCP servers all over the place. How are we going to put a standard set of controls with low levels of friction in front of all of these MCP servers so that we've got kind of a standard security layer across the board so that we can secure the authentication and authorization controls for these agents at scale? And then finally, how do we have governance and audit and visibility across our whole estate, right?

And this straddles from both discovering agents all the way through to having observability across them at the right-hand side. So I'm just going to spend just a few seconds on this, right? We launched some capabilities earlier on in the year. At the heart of our solution is sort of what we're calling Agent IAM Core. It's handling all of the token provisioning, token minting aspects of it. We have a gateway component, like we heard about the gateway, along with Authorize. We've got Protect for the computer-using agents detection pieces.

And then we've got some additional capabilities coming around governance and the visibility piece, right? If you'd like to understand more about this, please pop by the booth. I'll be down there throughout the day today. But apart from that, thanks very much for the time and enjoy the rest of the conference. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Great.

Great, thanks, Adam. You did fairly well on the time. Just one quick question. I know you mentioned ownership, but in practice, who do you believe should ideally own an AI agent inside the enterprise business unit using it? The security team, the IAM function, the person who initiated it?

Yeah, it's great, isn't it? I think all of the above, right? And actually, there's three types of owners. I think there's the person who's accountable for it, which could be that business function. There's a set of administrators who are looking after the access controls around it. And then there's the users who are actually interacting with it. And all three of those have got a role in its ownership. Thank you.

Great, thanks once again for Adam Russbridge.