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

At a glance

What this is: This analysis argues that AI agents have turned authorization into the missing layer in IAM because static roles and coarse access management cannot govern delegated runtime decisions.

Why it matters: IAM, PAM, and identity architects need to treat runtime authorization as a separate control plane for agentic AI, not a feature buried inside access management.

Context

Authorization is the policy decision that determines whether an identity can perform a specific action on a specific resource in a specific context. In agentic AI, that decision has to be made at runtime, because the agent’s tool use, delegation chain, and session context change continuously.

The governance gap is that most IAM programmes still centre on static roles, groups, and coarse access controls. That model can describe human access reasonably well, but it struggles once an agent is making context-rich tool calls, especially when security teams have not finished closing human IAM backlogs.

Key questions

Q: How should security teams modernize application authorization without relying on static roles?

A: Security teams should move authorization out of the application and into centralized policy decisions based on scopes, claims, and source-of-truth attributes. That lets access be evaluated consistently across many apps, supports finer granularity, and reduces the maintenance burden of hard-coded roles. The key is to enforce policy close to the application while keeping the logic externalized and manageable.

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 breaks when authorization ignores the calling application?

A: When authorization ignores the calling application, the API cannot tell whether a request came from the right actor, in the right workflow, with the right purpose. That leads to over-permissioned integrations, unsafe delegated access, and policy decisions that look correct on paper but fail at runtime. Application identity must be part of the trust decision.

Q: How do teams decide whether to use AI in authorization decisions?

A: Use AI to analyse policy patterns, detect over-provisioning, and suggest better scopes, but keep the live allow or deny decision deterministic. That preserves auditability, repeatability, and consistent enforcement across environments. If the decision itself depends on model output, the control becomes harder to validate and defend.

Technical breakdown

Why static roles fail for agent tool calls

Role-based access control assigns permissions up front and assumes the access pattern is stable enough to classify in advance. Agentic workflows break that assumption because a tool call may depend on delegation context, prior actions in the session, and the specific resource being touched. Fine-grained authorization needs a policy decision point that can evaluate current state at the moment of enforcement, not a role assignment created earlier in the lifecycle. That is why authorization management platforms and policy engines become a distinct layer rather than an access management add-on.

Practical implication: Treat agent tool access as a runtime policy problem, not a role-design problem.

How policy decision and enforcement points separate control from code

Externalized authorization splits the policy decision point from the policy enforcement point. The PDP evaluates policy, while the PEP sits in the application, API gateway, service mesh, or proxy and blocks or allows the action. AuthZEN exists to standardize that PDP-to-PEP exchange so different environments can share a common request and response pattern. That matters for agentic AI because the same policy logic may need to enforce access across several tools and runtime surfaces without rewriting the integration each time.

Practical implication: Standardize the PDP-to-PEP contract before agents proliferate across multiple tool surfaces.

Why deterministic runtime decisions matter more than AI-assisted policy creation

AI can help analyse access logs, suggest tighter scopes, and identify unused permissions, but runtime authorization must stay deterministic. A security decision that varies by model output is difficult to test, audit, and defend under operational pressure. The better pattern is to use AI upstream for policy insight and keep the final yes-or-no enforcement in a deterministic engine. That preserves auditability while still letting teams improve policy quality from observed behaviour and entitlement data.

Practical implication: Use AI for policy analysis, not for the live authorization decision itself.

Threat narrative

Attacker objective: The objective is to exploit weak or incomplete authorization logic so agent-driven access can reach unauthorized tools, data, or actions.

1. Entry occurs when an agent is given delegated access to tools or services and can begin making contextual requests on behalf of a user or workflow.
2. Escalation happens when static roles or coarse rules cannot evaluate the agent’s current context, allowing the agent to reach resources beyond the intended scope of the original delegation.
3. Impact follows when tool calls are authorized without sufficient runtime context, creating brittle DIY policy logic, mis-scoped access, and stalled AI initiatives that cannot move safely to production.

Breaches seen in the wild

• AI agent retail card theft campaign 2026: AI agents breached 27+ retailers for about $25 each, used cloud keys and a Secrets Manager dump, and stole 600,000+ payment cards.
• Spain's first AI agent data breach 2026: Spain's AEPD logged its first breach notification attributed to an attacker's AI agent, which altered personal data and accessed invoices.

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 control plane that determines whether agentic AI is governable at all. The article shows a category shift, not a feature discussion: analysts are now treating runtime authorization as its own layer because static roles and access management cannot express delegated tool use well enough. The practitioner conclusion is simple: if authorization remains buried inside legacy IAM, agent programmes will inherit brittle policy decisions and slow deployment.

Runtime authorization is now a distinct governance boundary, not a finer version of access management. Externalized policy engines separate the decision from the enforcement point so policies can be evaluated in context wherever the agent acts. That is the right architectural response to multi-environment tool use, and it is also the point where auditability becomes possible. Practitioners should stop treating policy logic as application glue and start treating it as infrastructure.

The old IAM assumption that access can be classified before execution is breaking under agentic behaviour. Static provisioning models were designed for identities whose permissions are stable enough to model in advance. That assumption fails when an agent’s tool choices, context, and delegation chain can change during the session. The implication is not merely more controls; it is that teams must rethink how authorization is represented, evaluated, and proven in real time.

AI should inform authorization policy, not make the authorization decision. The article’s strongest signal is that security teams need determinism at the point of enforcement and intelligence upstream in policy design. AI can surface over-provisioning and improve policy quality, but the runtime check must remain predictable, testable, and consistent. The practitioner conclusion is to use AI as an advisory input, not as the decision engine.

AuthZEN matters because interoperability is now a governance requirement, not a convenience. If authorization engines and enforcement points cannot speak a common protocol, every integration becomes bespoke and every agent deployment adds more policy debt. That is why standards around the PDP-to-PEP contract are becoming foundational. Practitioners should evaluate whether their authorization architecture can survive heterogeneous agent and application environments without custom rewrites.

From our research library:

• Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
• Read next: Agentic AI Identity Guide

What this signals

Authorization is becoming the governance layer that separates deployable agent programmes from experimental ones. When teams cannot express delegation, context, and enforcement consistently, they end up with brittle exception handling disguised as IAM. That is why runtime policy evaluation is moving from architecture preference to operational necessity.

Context-rich authorization: agentic systems force identity teams to move from precomputed entitlements to decisions made at the moment of use. The operational signal is whether your current stack can carry delegation chain, resource, action, and session context without custom code in every service. Teams that cannot do that will keep adding policy debt as agents scale.

More than one-third of enterprises may soon have agentic AI embedded in software, according to Gartner research cited by Cerbos, which means authorization architecture will become a scaling constraint rather than a niche design choice. The practical response is to decide now where the policy decision lives and how it is enforced across heterogeneous runtimes.

For practitioners

• Map agent authorization as a separate control plane Inventory where runtime decisions are currently hidden inside application code, API gateways, or ad hoc service logic, then identify which agent use cases need central policy evaluation instead.
• Separate policy decisions from enforcement points Use a policy decision point for evaluation and a policy enforcement point at each tool, proxy, or gateway that can block or allow the call in context.
• Define contextual inputs for agent decisions Require every authorization request to carry delegation chain, session state, resource, and action context so the policy engine can make a deterministic decision.
• Keep AI out of the live allow or deny step Use AI to analyse access patterns and recommend tighter policies, but preserve deterministic enforcement for production authorization decisions.
• Test interoperability before scaling agent deployments Verify that your authorization stack can work across applications, proxies, and service meshes without rewriting policy logic for each environment.

Key takeaways

• Agentic AI is forcing IAM teams to treat authorization as a distinct runtime control rather than a side effect of access management.
• The main risk is not just broader access, but policy decisions that cannot be evaluated consistently at the point of use.
• Teams that centralise policy evaluation and keep enforcement deterministic will have a clearer path to scaling agents safely.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.