IGA vs IAM for AI Agent Populations

IAM's original purpose was authentication and authorization at a login boundary: prove who you are, present the right credential, get in. The model worked because human sessions are discrete. A person logs in, does work, logs out. The access event has a beginning and an end, and the entitlement that authorized it can be reviewed against a job function that changes slowly.

IGA asks a different set of questions entirely. Not "can this identity authenticate," but "should this identity hold this entitlement, given its current role, the business justification that approved it, and the risk it represents today." The four core IGA functions, policy definition, access certification, role lifecycle management, and audit and compliance reporting, answer the governance question, not the authentication question.

For human identities, IGA has always run on human timescales. Quarterly recertification campaigns. Annual role reviews. Managers approving access lists between meetings. Slow, but roughly calibrated to how fast human job functions actually change. Nobody loved the process, but it more or less fit the problem.

AI agents break that calibration entirely. An agent's effective role can shift mid-task as it acquires context, calls new tools, or chains to sub-agents carrying their own entitlements. An entitlement that was safe when issued becomes unsafe after the model changes context, because the boundary that made it safe was behavioral, not technical, and no static certification cycle catches behavioral drift at runtime. The policy question stops being "does the agent have access" and becomes "is that access still bounded by the original business justification that someone, somewhere, was supposed to approve."

Think of it like a temporary contractor badge that never expires and quietly learns to open more doors on its own. Approval workflows become non-negotiable for agent populations for exactly this reason. Someone must have authorized each entitlement, and that authorization chain must be reconstructable, not for bureaucratic reasons, but for the moment a regulator asks what data an autonomous system touched and on whose authority.

The IGA function that matters most disproportionately for agents is privilege creep detection. For humans, privilege creep is slow and at least partially visible: a manager notices a role change, an HR system flags a transfer. For agents, it is fast and largely invisible. Nobody watches an agent accumulate permissions the way a manager watches an employee change teams. IGA is where that accumulation gets caught, assuming an IGA program exists to do the catching. That assumption is doing a lot of work right now.

The Scale of the Non-Human Identity Population Most Enterprises Are Not Governing

Before AI agents arrived, the non-human identity problem was already significant and largely ignored. Service accounts, API tokens, bots, and automated pipelines already outnumbered human identities in the average enterprise by a substantial margin. In cloud-native environments, the ratio is considerably higher. AI agents are being layered on top of this existing population, not instead of it, and Gartner's April 2026 projections show agent counts growing by orders of magnitude over the next several years.

The 2026 SANS Identity Threats and Defences Survey identifies non-human identities as the fastest-growing identity category in most enterprise environments. The governance reality underneath that trend line is not flattering.

A large majority of organizations fail to rotate machine credentials on any regular cycle. Credentials issued for a task that ended months ago, still valid, held by a system nobody is monitoring: that is the "forever access" problem at scale. A majority of organizations report no designated team accountable for AI identity lifecycle, which means nobody reviews it, nobody catches drift, and nobody is around to be embarrassed when something goes wrong. Only a minority can reliably track and audit what their AI agents actually access.

The gap between organizations that say governing AI agents is critical and those that have implemented any policy to do so is wide. The acknowledgment outruns the implementation by several years in nearly every enterprise security domain, and something unpleasant fills that gap while everyone is still writing frameworks.

What makes AI agents qualitatively different from the legacy non-human identity population they are joining is not scale alone. A service account is passive. It holds a credential and waits to be called. An AI agent is autonomous: it sequences actions, calls external APIs, spawns sub-agents, and in some architectures can request new permissions dynamically. The emergent behaviors agents produce are frequently unanticipated by the teams that issued their credentials, and that gap between anticipated and actual behavior is precisely where ungoverned risk lives. Manual governance processes designed for quarterly human identity reviews cannot scale to this population. The math does not work.

Why RBAC Is Too Coarse a Tool for Agent Access Decisions

Role-Based Access Control works by assigning standing entitlements to roles and identities to roles. It was designed for predictable, discrete job functions: a finance analyst gets read access to the financial reporting system, a developer gets write access to the code repository. The role encodes an assumption about what the identity will do.

AI agents do not map cleanly to job functions. Their effective capabilities shift with every tool they can call, every plugin connected, every sub-agent they can spawn. A "viewer" role for an agent is entirely safe in one context and dangerous in another, and the difference between an agent summarizing project documents and that same agent exporting that data to an external API is invisible to RBAC. Both actions occur under the same role assignment. The label "viewer" captures neither the risk nor the distinction, which is a reasonably fundamental problem for a system built on labels.

Attribute-Based Access Control addresses this by evaluating context at decision time: who is the agent, what tool is it invoking, what data is involved, under what operational conditions. The access decision reflects current reality rather than a role assigned at provisioning. Relationship-Based Access Control, as popularized by Zanzibar-style authorization systems, expresses what an agent can do in terms of its relationship to specific resources, which is more granular than role assignment and more maintainable than sprawling attribute rules. Both models support the same underlying principle: access decisions for agents should reflect current context, not static credentials.

The direction emerging from current best practice goes further. Zero standing privilege for agents. Task-bounded secrets. Entitlements that expire when the task ends and are not renewed until the task is re-authorized. This is not a radical idea; it is privilege minimization applied consistently to a population that cannot lobby for convenience exceptions, which is one of the few advantages agents have over human employees.

IGA's role in this architecture is to govern the policy layer above the enforcement mechanism: defining valid ABAC attributes, specifying which relationships authorize which actions, determining who approves exceptions and under what conditions. RBAC does not disappear entirely; it remains useful for broad access categories. But IGA must layer contextual and temporal controls on top of it, because for agent populations, the role alone is insufficient evidence that the access is justified.

How Enterprise Identity Providers Are Extending to Agent Identity, and Where They Fall Short

Legacy identity providers were built for a world where a human initiates a session at a login boundary. Authorization is expressed as standing entitlements enforced at authentication time. That architecture does not map to agents, which operate continuously, chain across systems, and need fine-grained per-call authorization rather than session-level access. The vendors know this. The extensions they have built reflect it.

Microsoft Entra Agent ID became generally available in April 2026, extending Conditional Access, Identity Protection, and Privileged Identity Management to non-human identities. An agent identity under this model is a specialized service principal with no standing credentials; it acquires short-lived tokens through its blueprint when a user or administrator has consented to the relevant scopes. The blueprint concept is the operationally interesting piece: it defines an agent type's owners, sponsors, access envelope, and audit behavior once, then applies that template to every instance. For organizations managing large agent populations, governing at the type level rather than the instance level is a meaningful improvement over manual provisioning.

Okta has extended its integration catalog to cover agent platforms, giving security teams visibility into sanctioned agents and the ability to surface shadow agents from a single console. Its Cross-App Access protocol standardizes how one agent calls another application's data without a separate credential exchange at every hop, which directly addresses the audit trail problem in multi-agent delegation chains. At the token level, Okta evaluates agent access policy and returns a short-lived, one-time-use token downscoped to the task. That is the zero-standing-privilege model agent populations require. Okta also operates alongside non-Okta IdPs, which matters for the many enterprises whose human identity infrastructure and agent identity infrastructure are managed separately.

These are genuine advances. They are also insufficient for full IGA, and the gap is worth naming precisely. Authentication and token issuance are handled; ongoing recertification, policy-driven entitlement reviews, and access justification workflows are not native to either platform. Identity blueprints and policy templates are provisioning tools. They define what an agent should have at provisioning time. They do not continuously validate whether what the agent holds is still appropriate three months and a dozen model updates later.

Audit logging from IdPs captures authentication events. It does not capture the semantic content of what the agent actually did with that access, which is what compliance reviewers actually need. Only a small minority of organizations currently use their existing IAM infrastructure as an authorization server for agentic tool-calling infrastructure. Most agent tool calls are happening entirely outside governed identity infrastructure, and IdP extensions alone cannot close that gap.

MCP Servers and the Tool Call as the Atomic Unit of Agent Access

Anthropic introduced the Model Context Protocol in late 2024 as a standard way for agents to call external tools without bespoke connectors. By mid-2025, adoption across major AI platform vendors made it effectively the enterprise default. The public registry grew rapidly, and MCP compressed the timeline from emerging standard to entrenched infrastructure in a way that caught most enterprise security teams completely unprepared. Familiar story, faster cycle.

For IGA purposes, every MCP tool call is an access event. An agent invoking a capability against a resource, often touching sensitive data, often with the ability to write or modify system state. The governance question at the tool call level mirrors the IGA question at the entitlement level: should this agent be allowed to invoke this tool, against this data, under these conditions, right now.

OAuth 2.1 was added to the MCP specification in mid-2025, and Auth for MCP became generally available shortly thereafter. Implementation varies significantly across deployments. The standard exists; the enforcement does not.

An MCP gateway adds what a raw IdP cannot provide at this layer: policy enforcement at the tool and agent semantic level, not just the HTTP transport level. Contextual audit trails capturing agent identity, tool name, parameters passed, results returned, and the human authorization chain constitute the full evidentiary record compliance requires. Real-time blocking of unauthorized server connections and unapproved tool invocations prevents the problem rather than discovering it retrospectively. Visibility into which tools which agents are invoking, at what frequency, produces the telemetry IGA needs to run recertification and detect scope creep.

Speakeasy operates in this category, treating the MCP gateway as a governance layer that routes all agent connections through auditable infrastructure, enforcing access controls tied to existing identity providers and detecting unauthorized connections in real time. The operationally significant distinction is catching unauthorized action at the moment it occurs rather than surfacing it in a quarterly sweep.

The MCP gateway is where IAM enforcement and IGA governance converge at the point of agent action. Not at provisioning, where decisions are made in advance of behavior, but at the action itself, where behavior is actually occurring. That distinction matters more than it probably should, but here we are.

Shadow AI as an IGA Failure, Not Just a Discovery Problem

Shadow AI follows the same proliferation pattern as shadow IT: ungoverned tools spread because governed alternatives are too slow to approve or too restrictive to be useful. The difference in consequence is not marginal. A shadow SaaS tool holds data. A shadow AI agent acts on data, calling APIs, writing to systems, chaining to other agents under credentials that security teams did not issue and frequently cannot revoke.

From an IGA perspective, shadow AI is an entitlement that was never approved, a role that was never reviewed, and an audit trail that does not exist. When a regulator asks what data a system accessed and on whose authority, "we didn't know it existed" is not a response that survives the inquiry.

The organizations most exposed are those with active non-human identity populations and no IGA program covering them. Per available survey data, that describes the majority of enterprises. The NHI hygiene gap and the shadow AI exposure are the same underlying problem; they just show up on different teams' radar, which is itself part of the problem.

Discovery alone is insufficient because finding a shadow agent is only the first step. The IGA question is what it has accessed, whether those accesses were justified, and whether any of them require remediation. Without access certification history, organizations cannot reconstruct whether a shadow agent's actions fell within or outside sanctioned scope, and that reconstruction is mandatory when regulatory inquiries arrive. Answering "we found it eventually" does not satisfy the question of what it did before anyone was looking.

An MCP gateway that catalogs approved servers and blocks connections to unapproved ones converts shadow AI into sanctioned AI at the action level. Speakeasy's approach treats this as a structural governance problem rather than a periodic audit problem: a governed layer that requires agent connections to route through auditable infrastructure, detecting unauthorized connections in real time. Mature IT organizations apply exactly this logic to shadow SaaS. The application to autonomous agent populations is overdue, and the gap is not a technology problem.

The Practical Components of an IGA Program for AI Agent Populations

Building an IGA program for agent populations does not require replacing existing infrastructure. It requires extending it deliberately across several components, none of which are exotic, though assembling them coherently takes more organizational will than technical skill.

Agent Identity Catalog

Every agent needs a registered identity with defined owners and sponsors, including agents deployed by individual developers and shadow agents surfaced through gateway monitoring. Identity blueprints, as implemented in Entra Agent ID's model, are a useful mechanism for scaling this without manual provisioning at every instance. The ownership question is non-negotiable: most organizations currently have no designated team accountable for AI identity lifecycle, and that absence is precisely where accountability disappears and stays missing.

Least-Privilege Entitlement Design

Where agents need contextual, per-call authorization, ABAC or ReBAC should replace flat RBAC. Credentials should be short-lived and task-bounded, issued via token exchange (OAuth 2.0 RFC 8693) or workload identity federation. SPIFFE/SPIRE provides a strong anchor for cryptographic workload identity in environments where agents operate across heterogeneous infrastructure. No standing privileges should persist after task completion. The engineering inconvenience of implementing this is real and finite; the governance cost of skipping it is open-ended.

Continuous Access Certification

Quarterly review cycles designed for human identity populations are inadequate for agents whose scope changes faster. Policy-as-code can automate the recertification question at each tool call, evaluating whether the entitlement still matches the agent's current task context rather than its state at provisioning. MCP gateway telemetry, specifically which tools which agents are calling at what frequency, provides the signal automated recertification needs to detect scope creep before it becomes a compliance event.

Audit and Compliance Reporting

The audit record for an agent must capture more than authentication events. It must capture the semantic layer: what tool was called, with what parameters, against what data, under what authorization, in what task context. This is the evidentiary chain compliance reviewers require, and it is currently absent from most organizations' logging infrastructure. An MCP gateway is the most tractable place to generate this record, because it sits at the point where agent actions actually occur rather than at the session boundary where they were permitted to begin.

Policy Governance Layer

Above all technical controls sits the question of who defines the policies, who approves exceptions, and how policy changes are reviewed. This is the IGA function that most agent governance discussions skip, because it is organizational rather than technical. It requires designating accountable teams, establishing approval workflows for new agent entitlements, and building recertification campaigns that include agent identities alongside human ones. The technical components are necessary but insufficient. Without the governance layer above them, you have controls with no one responsible for them, which is a more sophisticated version of having no controls at all. The sophistication is cold comfort.

The organizations that will govern AI agent populations effectively are not waiting for a comprehensive platform that solves everything. They are assembling the components: IdP extensions for provisioning, MCP gateways for enforcement and telemetry, policy-as-code for automated recertification, and ownership structures that make humans accountable for what their agents do. The gap is not capability.