AI systems deployed in enterprise environments are actors. They read data from systems that require authentication. They take actions that require authorization. They operate on behalf of users and workflows in ways that require identity context. That's a description of how they're built.
Which means every AI risk in your accounts surfaces through the identity layer. Access, authorization, and accountability are mechanically how AI systems operate. Identity is where those controls live. If an agent exfiltrates data, it does so using a credential. If it takes an unauthorized action, it does so because something authorized it. If it impersonates a workflow, it does so by presenting identity context that a downstream system accepted.
The identity layer is the AI risk conversation.
The Question That's Actually Coming Up
For the past two years, the dominant AI question in federal agency meetings was capability-focused: what can this model do, how accurate is it, what are the hallucination risks. That question hasn't gone away. But a second question has arrived alongside it, and it's showing up earlier in the conversation than it used to.
The question is: what can this system reach, and who authorized that?
CAIOs are deploying agents into production environments. Those agents need to read from document stores, query databases, call APIs, and write outputs back to systems of record. Every one of those operations requires a credential and an authorization decision. CISOs are being asked to sign off on deployments where the risk surface is the model's behavior combined with everything the model can access, not the model's behavior in isolation.
That's your conversation. Your fluency in how access works, how authorization is structured, and how accountability is maintained is exactly what the room needs. The challenge is that some of what you know will translate directly, and some of it will mislead you in ways that matter.
Three Verbs, Three Identity Requirements
When an AI agent reads data, it needs a credential that grants access to the system holding that data. This is familiar territory. The question of which systems an agent can read from, under what conditions, and with what logging is an access control question. The vocabulary of least privilege, scope, and entitlement review applies.
When an agent takes actions — submitting a form, sending a message, modifying a record, calling an external API — it needs authorization to perform those operations. Authorization for human users is governed by role, context, and policy. Authorization for agents involves the same mechanisms, but the actor's behavior is harder to predict and harder to bound. A human user with write access to a system does a finite set of things with that access. An agent with the same access does whatever its instructions and tools lead it to do.
When an agent impersonates a workflow — acting as a stand-in for a human process, completing tasks on a user's behalf, operating within a system that was designed for human interaction — it presents identity context that downstream systems use to make trust decisions. Those systems were built to trust human principals. The question of whether they should extend that trust to an agent, and under what conditions, is an identity question with no clean answer yet.
Note: In identity, service accounts represent non-human actors with static, bounded credentials — a specific application doing a specific thing. The closest AI equivalent is the agent identity: a credential assigned to an autonomous process acting on behalf of a user or workflow. It diverges here: service accounts have predictable, enumerable behavior. An agent's behavior is determined at runtime by its instructions and the tools it's given access to. The credential is static; what it authorizes is not.
Where Your Mental Model Helps, and Where It Stops
Your IDAM fluency is the right starting point for these conversations. The concepts of least privilege, credential lifecycle, session management, and authorization policy all apply. Buyers who are thinking clearly about AI governance are asking questions that your vocabulary answers.
Where your mental model starts to mislead you is in the assumption of bounded, predictable actors. The access control frameworks you work with were designed for principals whose behavior could be enumerated and governed in advance. An agent's behavior is emergent. It depends on its instructions, its tools, the state of the systems it's interacting with, and the sequence of decisions it makes mid-task. You can bound what it's allowed to reach. You cannot fully predict what it will do within that reach.
This creates a specific gap. The governance patterns that work for human users and traditional service accounts assume that controlling the credential means controlling the behavior. With agents, controlling the credential is necessary but not sufficient. The rest of the section works through where that gap shows up and what the current state of tooling looks like for addressing it.
Note: In identity, delegation is a defined flow: a principal grants a limited set of permissions to another party, bounded by scope and time. The closest AI equivalent is an agent acting on a user's behalf — accessing systems, calling APIs, executing tasks under delegated authority. It diverges here: in OAuth, the delegated scope is declared at registration and constrains what the delegate can do. When an agent delegates further to a sub-agent or tool, the original scope doesn't automatically propagate as a constraint on downstream actions. Delegation chains in agentic systems can extend in ways that OAuth's trust model wasn't designed to govern.
What This Section Covers
The pieces that follow work through the specific intersections between AI systems and identity infrastructure. Where the concepts map cleanly. Where they diverge in ways that will come up in your accounts. Where the gaps are real, currently unresolved, and worth naming honestly rather than papering over.
The pieces that follow are built around a specific goal: enough structural understanding that when a CISO asks how an agent's credentials are managed across a multi-step workflow, you can answer the question, or at least ask the right follow-up.
Your existing fluency is the foundation. The section that follows covers what doesn't transfer automatically.