Transcript
and I'm Director of Product Management for Identity Manager. Many of you may have watched a roadmap video where I walked you through how we will use AI to make identity governance smarter. So the most interesting piece of feedback came back as a question. And it was, you showed us how AI will serve identity and access management, but how will identity access management serve AI? How will identity manager govern the identities that AI agents themselves carry? So this is a great question, and this is the focus of my presentation today. So every identity leader is asking this question right now. It's not theoretical anymore. Agents are being built and deployed in production today, often without a governance process behind them. So three things make this hard. Agents get created in code at runtime, sometimes by other agents, and they don't go through HR or an IT ticket system. They act across boundaries on behalf of human users. So who delegated what authority becomes a real problem. And they run at machine speed, which means controls have to be automated. You cannot have a human reviewing every action. And this is the problem. And the rest of this presentation is how identity manager answers that problem. So a little bit of quick framing first. There's two different questions when you talk about AI and identity. So AI for identity manager is all about using AI to make our governance platform smarter. So our AI assistant in our web portal, AI assistant access reviews, smarter risk signals. This is really what the previous roadmap presentation was exploring. So identity and access management for AI is the other direction. How do we govern the identities AI agents themselves carry? Who owns each agent? What can it do? How can we review its permissions? And how can we shut it down when something changes? Both really matter. But today I'm just focused on the second one. So the first reaction is usually that agents are just another kind of service account. But I wanna push back on that. Look at this comparison. Human users are HR driven. They have a clear joiner, mover, lever life cycle. They act for themselves at human pace. Service accounts get created through tickets. They're long lived. They act for an application at a scheduled or event-based pace. AI agents are different on every one of these. Created in code. Life cycle that can be short-lived or long-lived. Acting for a human or another agent at machine speed. Treating agents as just another service account misses the point. Governance has to track who delegated what, where the authority came from, and how to shut it down quickly at machine speed. So here's the core of our position. And everything else from this presentation flows from it. AI agents are a category of non-human identity. Not a new product, but not a separate registry. It's a category within the broader non-human identity work we're doing in Identity Manager already. And this matters because it means an agent gets the same governance an identity already gets. Six things. An accountable owner. A defined life cycle. Scoped permissions. Attestation. Credential hygiene. And audit trial. These are not new capabilities. We've been building them for decades. Identity Manager 10.0, which was released in December 2025, already includes the data model and identity types you need to govern non-human identities like any other identity. What is new is applying these capabilities to a new identity type with risk signals specific to agents. Governance machinery itself is already built. So at the top, three categories of source systems where agents are created today. Cloud platforms. Microsoft Azure, AWS, and Google Cloud. Line of business applications such as Salesforce, ServiceNow, and SAP. And other enterprise apps that have built agent capabilities into their own identity model. And agent frameworks. LandGraph, Crew AI, and emerging orchestration tools. So in the middle, Identity Manager. One governance layer. Inside it, agents sit alongside employees, contractors, applications, and service accounts as another identity type. So this is available today. Identity Manager 10.0 has the data model, identity types, and the linkage to a responsible person. At the bottom, what do you do with all of that? Well, approval workflow, separation of duty evaluation, risk scoring, and audit trial apply to non-human identities today. So out of the box attestation templates designed for agents and service principles are part of our 11.0 release. The commitment is this. We're not building a second registry for agents. The source of truth lives in the system that created the agent. We extend our existing connectors and our governance layer. One layer, many identity types. So before I move on, I actually want to show you what I've just described. It's not just a slide deck. It is a real product. This is Identity Manager 10.0 governing an Azure AI agent today. So look at what's on the screen. The application is classified as a non-human process application. Service principle in red is the agent identity itself. The agent has an owner and an approver. Its entitlements are scoped, and it's available through the IT shop with an approval policy. An AI agent governed like any other identity, classified, owned, attested, and audited. And this is available right now. So the governance machinery, it's already there. It's already built. What is new is making an agent aware. And there are five risk signals specific to where agents go wrong. So orphans, no accountable owner, the biggest risk in agent environments. Dormant, created, but never used. Good candidates for removal before they become a forgotten attack service. Overprivileged, permissions exceed what the agent actually does. So least privilege applied to agents. Missing metadata, no classification, no business context. You cannot assess risk without it. Stale credentials. For agents backed by service principles, rotation really matters. These signals drive attestation priority, risk scores, and a review model that lets reviewers decide whether an agent should exist before drilling into individual permissions. So again, this foundation is all available in 10.0 today. And the day-to-day governance, including credential expiry monitoring and attestation templates, deepens in 11.0. So our integration strategy is organised by pattern, not specific vendors. And the reason is, is that patterns scale and specific products do not. So we group an agent identity where it actually lives and not by the company who provides the cloud. So let's have a look at pattern number one. So cloud platforms. So Microsoft Azure, Amazon, AWS, and Google Cloud. Agent identity lives in the cloud directory or the identity access management layer, but each cloud has taken a slightly different architectural path. Microsoft has gone further. Through Entra Agent ID, agents are a first-class identity in the directory. An agent built in Foundry or Copilot Studio appears in Entra automatically with a defined permission scope. Governance is therefore direct because the agent is treated like any other directory identity. Identity Manager 10.0 supports this today. AWS and Google have taken a slightly different path. So neither has a native agent identity construct. AI agents are modelled as workload identities, typically identity access management roles in AWS and service accounts in Google Cloud. This applies to services like Bedrock or Vertex AI, where the agent resolves to the underlying workload identity layer. So governance here means cataloguing and classifying roles and accounts using trust policies, tags, and metadata. So both ecosystems are starting to explore a more explicit agent identity model, and so we absolutely feel that this is going to evolve, and we're tracking this closely. And we'll deepen each integration as customer demand grows. So pattern two, line of business applications. So you may know them as Salesforce, ServiceNow, SAP, and similar platforms, and we already integrate with those today. These platforms are now embedding agent capabilities directly into their own identity models. So governance happens at the application layer and not the underlying cloud. Salesforce AgentForce is the clearest example with ServiceNow and SAP following. So we will be extending existing integrations to cover agent-specific identities as these models mature. So pattern number three are agent frameworks. So LandGraph, our crew AI, and similar tools enable developers to build agents in code. These frameworks still rely on an underlying cloud identity to authenticate. And that means that pattern one already covers the identity layer. So when enterprises adopt frameworks, the governance foundation is largely in place. So two protocols are becoming the standards in the agent world. Now the first is MCP, the Model Context Protocol. So this is how agents find and use tools. The governance platform that speaks MCP can see what tools agents are calling, authorize those calls, and logs them. And this is a protocol we're actively building on. Our AI assistant, which you'll see in the web portal, is built on MCP. So we're not just talking about it, we're actually using it. The second is A2A, agent-to-agent. And this is how agents talk to other agents. It started at Google and it was given to Linux Foundation, and it's now sitting at version 1.2 with Microsoft, AWS, Salesforce, SAP, and ServiceNow running it in production. So we're watching A2A closely. Our role is the governance layer underneath it. A2A needs agent identities to know which agent is talking to which agent. And those identities are what Identity Manager governs through intra-agent ID and other cloud sources. The point is this, protocols at the agent layer change quickly. Identity governance is the layer that stays because every protocol needs to know who the agents are and what they can do. So three reasons why an independent governance layer matters more, not less, as this ecosystem grows. First, the clouds are going in slightly different directions. So Microsoft has built intra-agent ID. AWS at the moment is staying with the standard identity access management role, and Google has its own approach. And so these are not coming together anytime soon. Betting on one cloud's agent's governance is a bet on that cloud winning. Second, no enterprise really runs on one cloud. Agents will be on Microsoft, AWS, Google, custom frameworks, and new orchestration tools. Governance has to work across all of them. Third, governance and runtime enforcement are different things, and they should stay different. Governance decides who owns an agent, what it can do, when to review it, and what gets logged. Runtime enforcement sits between the agent and what it's trying to do, enforcing the policy in real time. Some vendors are combining the two into one product. We think keeping them as separate best-in-class products with open integration is the better bet. Identity Manager does the governance, and it works with the privileged access tools our customers are already using, and that includes our own safeguard. That is our role, the governance layer above the clouds and above the frameworks, every identity governed in the same way, including AI agents. So thanks for watching. If there's one thing to take away, it's this. Agent identity governance, it's not a new product category. It's the next chapter of identity governance applied to a new and fast-growing class of identities. Identity Manager applies the same governance we've been doing for decades, and it works with the systems where agents get created and gives you a stable governance layer, regardless of which protocols or platform the industry settles on. So thanks very much for watching. I hope you found this video useful, and as always, please reach out if you've got further questions.
