Identity & Access Management (IAM)
Identity and Access Management (IAM) is the discipline of ensuring the right identities have the right access to the right resources. Learn how IAM works and why AI agents break it.
What IAM is responsible for
IAM is not a single product but a control plane that answers two questions continuously: who is this? and what are they allowed to do? The first is authentication — verifying that an identity is who it claims to be. The second is authorization — deciding which resources and actions that verified identity may reach. Everything else in IAM exists to make those two decisions reliable, auditable, and revocable.
A mature IAM program is built from several interlocking components.
Identity lifecycle management
Every identity has a lifecycle: it is provisioned when a person joins or a service is created, modified as roles change, and deprovisioned when access ends. Provisioning grants the initial set of entitlements; deprovisioning removes them. The gap between when access should be revoked and when it is revoked — orphaned accounts, lingering service credentials — is one of the most common sources of breach. Automated joiner-mover-leaver workflows close that gap.
Authentication and MFA
Authentication establishes identity at the point of access. Passwords alone are insufficient, so modern IAM layers on multi-factor authentication (MFA) — combining something the identity knows, has, or is — and increasingly phishing-resistant methods such as passkeys and hardware tokens. Single sign-on (SSO) centralizes authentication so that one strong, well-governed login replaces dozens of weak, unmanaged ones.
Authorization models
Once an identity is authenticated, authorization determines what it can do. Two dominant models govern this:
- Role-Based Access Control (RBAC) assigns permissions to roles, and roles to identities. A "billing analyst" role carries a fixed set of entitlements; anyone in that role inherits them. RBAC is simple to reason about but coarse — it struggles when access should depend on context.
- Attribute-Based Access Control (ABAC) evaluates policies against attributes of the identity, the resource, and the environment — department, data classification, time of day, device posture. ABAC is more expressive and context-aware but harder to author and audit.
Least privilege and privileged access
The principle of least privilege holds that every identity should have only the access required to perform its function — no standing entitlements "just in case." Privileged Access Management (PAM) applies this to high-risk accounts: administrator, root, and service identities that, if compromised, grant broad control. PAM vaults credentials, issues them just-in-time, scopes them to a session, and records their use.
Governance and recertification
Identity Governance and Administration (IGA) sits above the mechanics, providing the audit and oversight layer. Periodic access recertification forces managers to re-attest that each report still needs the access they hold. Segregation-of-duties policies prevent toxic combinations of entitlements. Governance is how IAM stays correct over time rather than drifting into accumulated, unreviewed privilege.
Human identities versus AI-agent identities
IAM was architected around a human sitting at a keyboard: a person authenticates once, holds a relatively stable role, and acts at human speed and scale. Non-human identities already strained that model — service accounts and API keys outnumber human users in most organizations. Autonomous AI agents break it further, because an agent is not just a credential but an actor that decides what to do with the access it has been delegated.
| Human identity | AI-agent identity | |
|---|---|---|
| Authentication | Interactive login, MFA, SSO | Delegated tokens, service credentials, OAuth scopes |
| Access pattern | Stable role, human-speed actions | Dynamic, high-volume tool calls at machine speed |
| Authorization | RBAC/ABAC tied to a person | Inherited or delegated permissions, often over-broad |
| Accountability | Named user, clear ownership | Diffuse — which human owns the agent's actions? |
| Primary risk | Stolen credentials, privilege creep | Excessive agency — misusing legitimately granted access |
The defining new risk is excessive agency: an AI agent holds permissions that are technically valid but far broader than any single task requires, and traditional IAM has no native way to constrain what the agent does with them. The agent authenticates successfully, so IAM waves it through — even when its sequence of tool calls amounts to behavior no human operator would be permitted.
Why AI changes the IAM problem
Traditional IAM governs access at the door: it decides whether an identity may enter a system. It does not govern what happens inside once a delegated agent starts acting. An agent granted read access to a CRM and send access to an email API has two reasonable permissions in isolation — yet combined, autonomously, they enable data exfiltration that no recertification review would catch, because each grant looked benign.
Closing this gap requires extending IAM principles to the agent runtime: scoping every credential to the narrowest possible task, issuing it session-bound rather than standing, and inspecting each action the agent takes against policy before it executes. Identity remains the foundation — but for AI, authentication at the perimeter is no longer sufficient. Governance has to move to the point of action.
Questions IAM should answer for AI
- Which AI models and surfaces is this identity allowed to use? — Per-user and per-role access control over models and tools.
- What permissions has this agent been delegated, and are they scoped to its task? — Least-privilege, session-bound credentials rather than standing grants.
- What did this agent actually do with its access? — A per-action audit trail of every tool call the agent made.
- Who owns the actions taken by this autonomous identity? — Clear accountability linking agent activity back to a human or role.
