Gartner’s IAM summit shows authorization is now the agentic bottleneck

At a glance

What this is: Gartner IAM Summit EMEA showed authorization emerging as the core control gap for AI agents, with analyst sessions converging on externalized, policy-based decisioning.

Why it matters: IAM teams now have to govern delegated machine actions in real time, which means the same authorization model must stretch across human users, service identities, and AI agents.

By the numbers:

• 13% of banks and 16% of insurers have already deployed agents.
• More than 95% of identities use less than 3% of their granted cloud entitlements.
• Through 2028, over 50% of AI initiatives will halt due to unresolved agentic identity challenges.

👉 Read Cerbos's analysis of authorization for AI agents and AuthZEN

Context

Authorization has moved from an implementation detail to the control plane for AI agents. In practical terms, that means teams are no longer just deciding who can log in or which role a user receives, but which delegated actions an agent can perform in context, at runtime, and across tool boundaries.

At Gartner IAM Summit EMEA, the message from analyst sessions was consistent: existing IAM programmes are still catching up with human access governance while agent strategies are already being funded and announced. That creates a structural mismatch between the speed of AI adoption and the pace of identity and authorization engineering.

The article’s core point is that fine-grained, externalized authorization is becoming a prerequisite for agent governance. Cerbos uses the summit to argue for a policy-based approach, but the broader issue is that identity teams need a runtime decision layer that can work across APIs, applications, and agent tool calls without relying on static roles alone.

Key questions

Q: How should teams govern AI agent tool calls in real time?

A: Teams should govern AI agent tool calls with a runtime authorization layer that evaluates the principal, action, resource, and context on every request. Static roles are too coarse once agents can chain actions or carry delegated scopes across tools. The control point should be policy based, deterministic, and auditable so that each decision can be explained after the fact.

Q: Why do AI agents expose gaps in existing IAM models?

A: AI agents expose gaps because they do not fit the assumption that access can be assigned once and then managed through periodic reviews. Their permissions are often delegated, contextual, and session-specific, which means the access decision must happen at execution time. That forces IAM teams to move beyond provisioning logic and into runtime policy enforcement.

Q: What do organisations get wrong about authorization for agents?

A: The most common mistake is treating agent authorization as a role design problem instead of a decision problem. Roles describe broad entitlement, but agentic workflows need context-aware checks for delegation, tool scope, and session state. If those factors are not explicit in policy, the agent will either be over-permitted or blocked in ways teams cannot explain.

Q: What should identity teams do before scaling agent deployments?

A: Identity teams should confirm that their authorization stack can support externalized policy decisions across APIs, applications, and proxies without custom rewrites. They also need a clear model for delegated authority, because agent governance fails quickly when nobody can trace who granted what scope. A deterministic enforcement path should be in place before rollout expands.

Technical breakdown

Why role-based access control breaks for agent tool calls

Role-based access control works when access can be mapped to stable job functions and predictable entitlements. AI agents do not behave that way. They act through delegation chains, shift context mid-session, and make repeated tool calls that may each need a different decision. That creates a mismatch between static role assignment and runtime authorization. Fine-grained authorization means evaluating the principal, action, resource, and context at the moment of the request, not at provisioning time. In agentic workflows, the policy engine must understand delegated scope, session state, and tool-specific risk before it allows execution.

Practical implication: teams should stop treating agent access as an RBAC extension and design a runtime authorization layer for tool calls.

What AuthZEN changes in PDP and PEP interoperability

AuthZEN standardizes the request and response contract between a policy decision point, or PDP, and a policy enforcement point, or PEP. That matters because externalized authorization only scales when different enforcement points can ask the same question in a common language and receive a consistent decision. Without that contract, every integration becomes bespoke, which increases implementation cost and makes replacement or portability difficult. In the article’s framing, AuthZEN is the connective tissue that lets authorization remain centralized in policy while enforcement stays distributed across gateways, services, and agent proxies.

Practical implication: teams should map where decisions are made today and identify every place a common PDP-to-PEP protocol would remove custom glue code.

Why deterministic runtime decisions still matter in AI-heavy identity stacks

The conference’s strongest architectural signal was that AI can support authorization, but should not make the runtime decision itself. Deterministic decisions are necessary because access control must be explainable, testable, and repeatable under the same inputs. AI is better suited to upstream tasks such as policy analysis, entitlement pattern discovery, and access drift detection. Once those insights are encoded, the authorization engine should enforce them consistently. That separation preserves auditability and reduces the risk that runtime access decisions become probabilistic, opaque, or difficult to certify.

Practical implication: use AI to improve policy quality, but keep the access decision path deterministic and auditable.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Authorization has become the missing governance layer for AI agents, not a feature inside IAM. The summit’s repeated focus on externalized authorization shows that identity teams are being asked to govern runtime delegation, not just user entitlements. That shift matters because agents change the decision surface from static access to dynamic tool use, and the old IAM stack does not answer that question cleanly. Practitioner conclusion: treat authorization as its own control plane, not as an extension of roles and groups.

Static role design is too blunt for agentic access because the principal, action, and context all shift at runtime. The article’s emphasis on fine-grained, context-aware decisions reflects a broader industry problem: a role can describe who the actor is, but not what the agent should do in a specific session. That gap becomes most visible in MCP-style workflows, where tool calls need immediate policy evaluation. Practitioner conclusion: design policies around delegated scope and session context, not identity labels alone.

AuthZEN is emerging because authorization systems need a common language between policy engines and enforcement points. The interoperability problem is structural, not cosmetic. Different vendors and deployment targets cannot coordinate runtime authorization if each integration invents its own request format, semantics, and response model. That is why a standard at the PDP-to-PEP boundary matters. Practitioner conclusion: evaluate whether your authorization stack can move across environments without rewriting the integration contract.

AI-assisted policy improvement is useful, but AI-driven runtime authorization is a category error. The article captures a line that many organisations still blur: AI can analyse access patterns and improve policy design, yet the enforcement decision must remain deterministic. That distinction protects auditability and avoids turning authorization into a probabilistic inference problem. Practitioner conclusion: keep AI in the advisory layer and reserve the decision path for rule-driven enforcement.

Authorization management platforms are becoming a distinct infrastructure category because identity programmes can no longer hide runtime control inside broader access management. That separation is a market signal as much as a technical one. It validates the need for specialized authorization tooling while also showing how quickly agent governance is forcing IAM architecture to mature. Practitioner conclusion: re-evaluate whether your current stack can support policy-based runtime control before agent rollout accelerates.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which makes runtime authorization harder to govern cleanly across machine identities.
• For a broader lifecycle view, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why entitlement control and offboarding need to move together.

What this signals

Authorization will become the test of whether AI adoption is governable, not merely whether it is possible. Teams that can externalize policy, trace delegated authority, and keep enforcement deterministic will absorb agent workloads faster than teams still embedding decisions in code. The pressure point is no longer identity proofing alone, but the ability to make and audit runtime decisions across a growing mix of human, machine, and agentic identities.

Runtime decisioning is now the control boundary that matters most for autonomous and semi-autonomous systems. That makes authorization the place where identity, application architecture, and operational risk converge. Practitioners should expect more scrutiny of delegation chains, policy portability, and decision latency as agent programmes move from pilots to production.

Ephemeral authorization debt: when agent access is granted faster than teams can model, review, and enforce it, the governance gap accumulates as hard-to-audit runtime permissions. With 91.6% of secrets still valid five days after notification in our research, delay is a structural problem, not an edge case.

For practitioners

• Map where runtime authorization happens today Inventory every place an access decision is made for human users, service accounts, APIs, and agent tool calls. Identify whether the decision is embedded in code, hidden in a gateway, or externalized to a policy engine, then classify the gaps by risk and maintenance burden.
• Separate policy authoring from enforcement points Move toward a model where policy is written once and evaluated centrally, while enforcement can happen in gateways, application services, or MCP proxies. That reduces duplicated logic and makes authorization portable across deployment patterns.
• Use AI for policy analysis, not runtime decisions Apply AI to entitlement mining, policy suggestion, and access anomaly detection, but keep the final decision deterministic and auditable. This preserves explainability and avoids introducing opaque authorization behaviour into production.
• Validate agent delegation chains before production rollout Document who delegated authority, what scopes were granted, and which tools the agent can call in sequence. If the chain is unclear, the authorization model is already too weak for production use.

Key takeaways

• AI agents are forcing identity teams to treat authorization as a runtime control layer, not a role assignment exercise.
• The practical challenge is interoperability, because policy engines and enforcement points must share a common protocol to scale cleanly.
• AI can improve authorization policy design, but deterministic enforcement remains the non-negotiable requirement for auditability and trust.

Key terms

• Authorization Management Platform: An authorization management platform is a dedicated layer for making access decisions outside application logic. It centralises policy evaluation while allowing enforcement to happen across APIs, services, gateways, and agent proxies. For agentic systems, it matters because access is decided at runtime, not just at login.
• Policy Decision Point: A policy decision point is the component that evaluates policy and returns an access decision. It does not enforce the decision itself. In agent governance, the PDP must understand delegated authority, request context, and tool scope so that each runtime decision is explicit and auditable.
• Policy Enforcement Point: A policy enforcement point is the control that intercepts a request and applies the decision returned by the PDP. It sits in the application path, gateway, or proxy. For AI agents, the PEP is often the last gate before a tool call is executed, which makes integration consistency critical.
• Delegation Chain: A delegation chain is the sequence of authority passed from one identity to another before an action is taken. In agentic environments, it can include a human, service account, API, and agent. The chain matters because the decision is only as trustworthy as the scopes, transfers, and accountability links within it.

Deepen your knowledge

Authorization for AI agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from human IAM into delegated machine access, this is a relevant starting point.

This post draws on content published by Cerbos: Gartner IAM Summit EMEA and the case for agent authorization. Read the original.