IAM for agentic AI exposes the limits of human-era controls

At a glance

What this is: This is a comparison of six platforms for IAM for agentic AI, showing that the category splits between runtime enforcement and NHI discovery and governance.

Why it matters: It matters because security teams now have to decide whether they need per-request policy enforcement, NHI inventory and posture management, or both for AI agents, workloads, and human access.

By the numbers:

• At least 1,862 internet-exposed MCP servers were found running with zero authentication.
• Cisco completed its acquisition of Astrix in May 2026, and standalone sales of new Astrix licenses ended June 30, 2026.

👉 Read Pomerium's comparison of six IAM platforms for agentic AI

Context

IAM for agentic AI is the problem of giving AI agents verified identities, checking every tool call against policy, and preventing long-lived credentials from becoming the real control plane. The article argues that human-era IAM was built for login events, not for continuous machine-to-machine authorization across MCP servers, APIs, and databases.

The central governance gap is architectural, not cosmetic. Some platforms enforce access at runtime, while others discover and govern the NHIs already spread across cloud and SaaS estates; the article’s value is in separating those jobs instead of treating them as interchangeable.

For practitioners, this is a decision about where control lives. If agents are already touching production, the question is whether enforcement, discovery, or both belong in the stack, and how much trust should remain in credentials that agents can reuse.

Key questions

Q: How should security teams govern AI agents that call APIs instead of using a UI?

A: Security teams should govern AI agents by treating each callable action as a scoped entitlement, not as a general application login. The key control is to limit which APIs, data sources, and write actions the agent can chain together in one session. That keeps machine-paced behaviour inside a reviewable boundary instead of relying on human-style session assumptions.

Q: Why do AI agents create problems for traditional IAM models?

A: Traditional IAM assumes stable identities, static roles, and access decisions that can be reviewed after the fact. AI agents can generate novel requests, chain actions, and reach multiple systems within a single session. The result is a governance gap where authentication succeeds, but the environment still cannot prove that the action was appropriate.

Q: What do security teams get wrong about runtime policy for agents?

A: They often assume runtime policy alone is enough. In practice, inline enforcement can block unsafe requests, but it does not discover shadow NHIs, clean up stale credentials, or fix lifecycle ownership gaps. Mature programmes need both request-time control and estate-wide visibility so governance and enforcement reinforce each other.

Q: How do organisations decide between NHI discovery and inline enforcement?

A: The decision depends on the failure mode. If the problem is unknown service accounts, secrets, or agents, discovery comes first. If the problem is live requests reaching production with no check, inline enforcement comes first. Most large environments need both because one controls the estate and the other controls the next request.

Technical breakdown

Runtime enforcement versus NHI discovery in agentic IAM

The article draws a clean line between two technical models. Runtime enforcement sits in the request path and evaluates each access attempt as it happens, which is necessary when an AI agent can make repeated tool calls against production systems. Discovery and governance work elsewhere: they inventory service accounts, API keys, secrets, and agents, then flag excess privilege or lifecycle gaps. These models are complementary because one answers whether a request should pass and the other answers what identities already exist. Confusing them produces blind spots either at the perimeter or in the identity estate.

Practical implication: decide whether your immediate problem is inline authorization, identity inventory, or both before selecting tooling.

MCP tool-level authorization and request context

Model Context Protocol changes the unit of control from a whole application to individual tools and methods inside an MCP server. That matters because a single MCP server may expose low-risk and high-risk actions side by side, and coarse server-level access grants far more than the task requires. The article emphasizes per-request evaluation using context such as identity and device posture, which is the difference between broad connectivity and actual authorization. In practice, the control plane must understand the action, not just the destination.

Practical implication: map MCP tools to privilege tiers so a read-only task cannot inherit administrative reach.

Short-lived identity assertions instead of reusable secrets

A key pattern in the article is replacing reusable credentials with short-lived, cryptographically signed identity assertions. That shifts trust away from the agent runtime holding secrets and toward a brokered request that can be verified at use time. This reduces the damage from a compromised process because the agent does not retain a reusable bearer secret that can be replayed later. It also aligns with Zero Trust logic, where identity is continuously asserted rather than assumed after initial authentication.

Practical implication: prefer ephemeral assertions and token exchange over hardcoded secrets in agent workflows.

Threat narrative

Attacker objective: The objective is to turn agent access into a durable path to tools, data, and production actions that were never meant to be broadly reachable.

1. Entry occurs when an AI agent reaches production APIs or MCP tools through exposed or over-extended access.
2. Escalation follows when the agent holds standing privileges or reusable credentials that let it continue touching high-value resources without fresh authorization.
3. Impact comes from repeated tool calls against databases or production systems, which turns a single mis-scoped identity into broad operational exposure.

Breaches seen in the wild

• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
• McDonald's McHire AI Chatbot Default Credentials — Default credentials in McDonald's McHire AI recruitment chatbot expose 64 million job application records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Human-era IAM assumptions break the moment agents become request-time actors. IAM for people assumes a login event, a session, and a stable operator behind the identity. AI agents calling tools continuously do not fit that model, which is why per-request authorization, not dashboard-era access management, becomes the relevant control boundary. Practitioners should treat this as a structural mismatch, not a feature gap.

Runtime enforcement and NHI governance solve different problems, and conflating them weakens both. Runtime gateways answer whether a specific tool call should happen now, while discovery platforms answer what NHIs exist and whether their privileges are sane. The article’s category split is useful because mature programmes will need both OWASP-NHI style visibility and Zero Trust enforcement, not one masquerading as the other. Practitioners should design the control stack around the decision being made.

Ephemeral credential trust debt is the right concept for agentic AI access. The article shows why short-lived credentials matter, but it also shows they are not a full answer if policy is still too coarse or if agent-to-tool relationships are not scoped at the method level. The governance debt builds when organisations let temporary credentials stand in for real least privilege. Practitioners should measure whether their agent identity model can survive a single compromised session.

Agentic AI pushes identity security toward tool-aware authorization, not just identity-aware authentication. Authentication tells you who or what is calling; it does not tell you whether that caller should be allowed to invoke this specific tool method against this specific system at this moment. The article’s comparison of platform categories reflects where the market is heading. Practitioners should expect architecture reviews to move from identity proofing to action-level control.

The category is converging on layered control planes, not one platform to rule all agent identity. The strongest pattern in the article is not a single winner, but the need to combine runtime policy enforcement with discovery, posture, and lifecycle governance. That aligns with NIST CSF and Zero Trust thinking: continuous verification plus explicit authorization across identities of every type. Practitioners should assume future programmes will be composable rather than monolithic.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which explains why discovery-first programmes still matter even when runtime controls are in place.
• For a broader lifecycle view, read the Ultimate Guide to NHIs and then test whether your agent governance model can inventory, scope, and revoke access cleanly.

What this signals

Ephemeral credential trust debt: temporary credentials reduce replay risk, but they do not eliminate governance debt if privilege scope and tool access remain too broad. For programme owners, the next step is to align ephemeral access with method-level authorization and lifecycle ownership, not to treat short TTLs as a complete control.

With 97% of NHIs carrying excessive privileges according to our Ultimate Guide to NHIs, the issue is no longer whether agentic AI needs identity controls. The real question is whether the organisation can enforce least privilege at the request layer while still tracking the identities that exist outside the enforcement plane.

The market is moving toward layered identity control, where one tool discovers the estate and another decides the request. That means IAM architects should plan for composable controls across human, workload, and agent access paths, with Zero Trust policy enforced where the transaction happens.

For practitioners

• Separate enforcement from discovery in your architecture Use a runtime gateway for per-request control and a separate NHI governance tool for inventory, posture, and lifecycle management. If the same product cannot do both, that is not a flaw, but you should understand which decision it cannot make.
• Map MCP tools to privilege tiers Inventory each tool and method exposed by MCP servers, then classify them by sensitivity so read, write, and administrative functions do not share the same access path. Keep the tool catalog aligned to business owners and review it as APIs change.
• Replace reusable secrets with short-lived assertions Where agents connect to APIs or services, prefer token exchange, cryptographically signed assertions, and ephemeral credentials over static secrets in code, configs, or agent prompts. Re-issue trust at the point of use instead of assuming the runtime is safe.
• Treat exposed MCP servers as a control failure, not just a deployment issue If MCP endpoints can be reached without authentication or with overly broad authorization, close the gap before layering analytics or governance on top. The first control objective is to prevent unauthorised tool invocation, especially for production-facing systems.
• Run a joint review of human, service, and agent access paths Look at one application or platform at a time and compare how a person, a service account, and an AI agent reach it. The useful question is whether the access path changes with actor type, because it should.

Key takeaways

• Agentic AI exposes a control gap in human-era IAM because tool calls need to be authorised at request time, not just at login.
• The article’s category split matters operationally: runtime enforcement, NHI discovery, and lifecycle governance solve different parts of the same identity problem.
• Enterprises should expect to combine per-request policy with secret reduction and NHI visibility if agents are already reaching production systems.

Key terms

• Access-Centric IAM: Access-centric IAM treats access as a lifecycle process rather than a static entitlement. It links issuance, renewal, usage, and removal so security teams can govern human and non-human identities with the same operating logic across hybrid environments.
• Runtime enforcement: Runtime enforcement is a control model that sits in the request path and evaluates access at the moment a call is made. For agentic AI, it matters because the identity can act continuously, so authorization has to be checked against current context rather than assumed from earlier authentication.
• Non-Human Identity: A non-human identity is any machine or software identity used by a service, workload, API, bot, token, certificate, or AI agent. These identities often outnumber human users and frequently carry standing privileges, which makes lifecycle ownership, rotation, and scoping essential.
• Model Context Protocol: Model Context Protocol is an open protocol that connects AI agents to tools and data sources. In identity terms, it shifts control from broad application access to specific tool interactions, so security teams must think about authorization at the method level rather than only at the server or application level.

What's in the full article

Pomerium's full blog post covers the operational detail this post intentionally leaves for the source:

• Platform-by-platform comparison criteria for runtime enforcement versus discovery and governance
• Details on MCP-specific authorization, including per-tool policy evaluation and request context
• The practical trade-offs between open-core enforcement, secret brokering, and NHI posture management
• Guidance on when to pair a governance platform with an inline gateway in a mature programme

👉 Pomerium's full post covers platform trade-offs, MCP support, and deployment fit across agentic AI use cases.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.