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

At a glance

What this is: This comparison explains how IAM for agentic AI splits into runtime enforcement and NHI discovery, and argues that login-era controls fail when agents call production tools continuously.

Why it matters: IAM teams, PAM teams, and identity architects need to decide whether their gap is inline authorization, NHI governance, or both before agents reach production APIs and MCP tools.

By the numbers:

• At least 1,862 internet-exposed MCP servers were found running with zero authentication, creating a large unauthenticated attack surface behind agent tool calls.

Context

Agentic AI IAM is the problem of giving AI agents and workloads verified identities and then authorising each request they make to tools, APIs, databases, and MCP servers. The gap exists because controls designed for human login events do not automatically govern continuous machine-to-machine action.

Pomerium frames the market as two architectural responses: runtime enforcement in the request path, and discovery-and-governance platforms that inventory service accounts, secrets, and shadow agents. That split matters because a control that only discovers exposure cannot stop the next tool call, while an inline gateway cannot find identities it never sees.

The article also shows why agentic AI pushes IAM beyond static credential management. When an agent can act with standing access across production systems, the control question becomes whether each request is checked at execution time, not whether a user authenticated at the start of a session.

Key questions

Q: What breaks when an AI agent is allowed to call tools without strict scope controls?

A: The main failure is privilege expansion. A model can only act safely if every tool it can call is constrained by explicit scope, server-side validation, and audit logging. Without those controls, the agent can read files, trigger actions, or expose data far beyond what the user intended, turning a helpful assistant into an uncontrolled access path.

Q: Why do AI agents create more risk than traditional automation?

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: How do teams know whether they need NHI discovery or runtime enforcement for agentic AI?

A: If you cannot tell how many service accounts, secrets, or shadow agents exist, discovery is the first problem. If agents are already reaching production and nothing checks each call, runtime enforcement is the immediate gap. Many mature programmes need both, but the operational priority depends on whether the bigger failure is visibility or control.

Q: What is the difference between MCP server access and tool-level authorisation?

A: Server access answers whether a user can enter the MCP boundary at all, while tool-level authorisation answers which operations are permitted inside that boundary. Enterprises need both because coarse access without fine-grained enforcement leaves too much power attached to a single session.

Technical breakdown

Runtime enforcement vs. discovery and governance

The article divides the category into two control planes. Runtime enforcement platforms sit in the request path and authenticate the caller, evaluate policy, and allow or deny the call in real time. Discovery and governance platforms work upstream and find service accounts, API keys, secrets, and AI agents, then flag over-permissioning and lifecycle issues. These two models solve different problems. One governs live access decisions, while the other reveals how much unmanaged identity exposure already exists across cloud and SaaS estates.

Practical implication: Practitioners should separate inventory work from inline authorisation and decide which gap is operationally blocking production access today.

MCP security and tool-level authorisation

MCP expands the risk surface because a single server can expose multiple tools with very different privilege requirements. Tool-level authorisation means the gateway evaluates the specific method or function the agent wants to invoke, not just whether the server is reachable. This is materially different from coarse server-level access. If an agent can read a record and delete it through the same endpoint family, server-wide permissioning grants far more access than most tasks require.

Practical implication: Teams should map MCP tools to discrete access decisions instead of treating an entire server as one permission boundary.

Short-lived identity assertions instead of exposed secrets

The article’s enforcement pattern avoids giving agents reusable credentials. Instead, short-lived cryptographically signed identity assertions are injected into requests, so the agent process never holds a durable secret. That design narrows reuse risk and makes compromise less transferable across sessions. It also aligns with the broader NHI problem the article highlights: long-lived secrets are a poor fit for systems that can initiate many requests without human pacing or direct oversight.

Practical implication: Security teams should prefer request-bound assertions and ephemeral credentials over agent-held secrets wherever production access is unavoidable.

NHI Mgmt Group analysis

Login-era IAM assumptions collapse when agents can initiate production work continuously. IAM for humans was built around a stable user session that starts with authentication and then unfolds inside bounded workflows. Agentic systems break that timing model because access is exercised at the moment of each tool call, not only at login. The implication is that identity governance for agentic AI has to move from session establishment to request-time enforcement.

Tool-level authorisation is now the meaningful control boundary for agentic systems. Coarse permissions at the server or application level over-grant by default when one MCP endpoint exposes multiple tools. The article makes clear that the real governance question is not whether an agent can reach a system, but which method it can invoke inside that system. Practitioners should treat the tool as the unit of policy, not the platform.

Discovery and enforcement are complementary, not interchangeable, for agentic AI identity. One class of platforms inventories NHIs, secrets, and shadow agents, while another class sits inline and decides every request. That split reflects a deeper programme reality: visibility without enforcement leaves live access ungoverned, and enforcement without discovery leaves shadow identities unmanaged. Mature identity programmes will need both planes, not a single control layer.

Agentic AI exposes a runtime governance gap that deserves its own named control model. The core issue is identity blast radius at the request layer, where a single autonomous task can fan out across tools, databases, and APIs faster than human-era review cycles can intervene. That makes request-time policy evaluation the decisive control variable for agentic AI. The programme implication is to redesign governance around live execution paths, not static login checkpoints.

Identity does not select or combine tools dynamically mid-session; it operates within predefined constraints was designed for human-paced access review cycles. That assumption fails when the actor is autonomous because the system can choose actions, call tools, and complete work before a review cycle exists. The implication is that access review logic itself becomes structurally incomplete for agentic behaviour, not merely slower than the threat.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Identity Guide

What this signals

Identity blast radius: agentic AI forces teams to stop thinking in terms of session start and session end, and instead govern the scope of each production action. A request-time control plane is the only place where tool choice, context, and privilege can be evaluated together.

Runtime enforcement and NHI discovery should be designed as complementary layers, not competing programme bets. One finds and rightsizes exposure, the other prevents the next over-scoped action from reaching production.

Pomerium’s comparison reflects a broader market signal: security teams are still relying on static credentials even as agentic AI deployments expand, and that gap will continue to dominate control design decisions, according to the 2026 Infrastructure Identity Survey.

For practitioners

• Map your agentic access boundary Identify where AI agents, workloads, and MCP tools intersect in production and decide whether each boundary needs inline enforcement or inventory governance first.
• Treat MCP tools as separate policy objects Assign different access decisions to read, write, admin, and destructive methods instead of granting a single server-wide permission.
• Replace durable agent secrets with request-bound identity Use short-lived assertions or brokering patterns so the agent runtime never stores reusable credentials that can be exfiltrated and replayed.
• Inventory shadow NHIs before expanding agent access Enumerate service accounts, tokens, and unregistered agents across SaaS and cloud estates so runtime controls are not deployed blind to the existing footprint.
• Separate governance from enforcement in your programme design Use one control plane to discover and right-size identities, and a different plane to authorize live requests in line with policy.

Key takeaways

• Agentic AI breaks IAM assumptions that were built around human login events and stable session pacing.
• The article separates platforms that inventory NHIs from platforms that enforce policy in the request path, showing why one control plane is not enough.
• Practitioners should move governance toward live tool-call authorisation, short-lived identity assertions, and separate discovery from enforcement.

Key terms

• Agentic IAM: Agentic IAM is identity and access management designed for environments where AI agents make independent decisions and take actions. It combines authentication, authorization, delegation, monitoring, and revocation so agent autonomy is constrained by policy, context, and accountability rather than open-ended system trust.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Discovery and governance: Discovery and governance is the practice of finding NHIs, secrets, and over-permissioned accounts, then managing their posture and lifecycle. In agentic environments, it exposes hidden exposure but does not by itself stop the next call from an autonomous system.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.

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 building or maturing an IAM programme, it is worth exploring.