AI agent authorization gaps are now the real IAM problem

At a glance

What this is: This is an independent analysis of why AI agents expose brittle authorization practices, with the key finding that runtime policy decisions, not login controls, are now the limiting factor.

Why it matters: It matters because IAM, NHI, and autonomous governance programmes all fail when access decisions are scattered, non-deterministic, or tied to human-paced assumptions that agents no longer follow.

By the numbers:

• Gartner tracked agent deployment in large enterprises going from around 11% in early 2025 to roughly 42% by late 2025.
• More than 95% of identities use less than 3% of the entitlements they have been granted.
• Only around 14% of organizations say they have adequate governance for agents today.

👉 Read Cerbos' analysis of AI agent authorization and runtime access control

Context

AI agent authorization is the problem of deciding what a software actor can do at runtime, not just proving who it is. In most enterprises, identity got the attention first, while authorization was left in application logic, service-specific rules, and fragile hand-offs between systems. That model works poorly when an AI agent can chain requests across services at machine speed.

The source article argues that the real gap is a centralized authorization layer that can evaluate principal, action, resource, and context consistently across the stack. As AI agents become more common, the challenge is no longer whether access can be authenticated, but whether it can be authorized deterministically, explained cleanly, and revoked fast enough to matter.

For IAM and NHI teams, this is the point where classic access management meets runtime governance. Agents behave like non-human principals even when they act on behalf of people, which means the policy model has to cover workloads, services, and delegated machine actors together.

Key questions

Q: How should security teams govern authorization for AI agents in enterprise apps?

A: Security teams should centralize authorization in a policy decision layer, keep enforcement in the application or gateway, and make the rules deterministic, versioned, and testable. That gives teams one place to govern delegated machine access without relying on fragile application code. It also makes audits, revocation, and incident response far more predictable across services.

Q: Why do AI agents expose IAM weaknesses that human users do not?

A: AI agents expose IAM weaknesses because they can generate high-volume, chained, cross-service actions at runtime, which breaks assumptions built around human-paced requests. Human identity controls often prove who the user is, but they do not reliably decide what a delegated machine actor should do in each context. That gap turns authorization into the real control point.

Q: What breaks when authorization remains inside application code?

A: When authorization stays in application code, policy logic fragments across teams, services drift from one another, and no single control point can explain or revoke access consistently. The result is inconsistent decisions, slower remediation, and weaker auditability. For agentic systems, that fragmentation becomes a security issue because access decisions happen too close to the business logic.

Q: Should organisations treat service accounts and AI agents under the same authorization model?

A: Yes. Service accounts, AI agents, and other workloads are all non-human principals that need centrally governed access decisions, even if their runtime behaviour differs. Treating them under one authorization model reduces blind spots, exposes overprivilege faster, and gives security teams a common way to enforce least privilege across delegated machine identity.

Technical breakdown

Centralized authorization vs application-coded access checks

The article’s core architectural point is that authorization should move out of application code and into a dedicated policy decision layer. Application-coded checks fragment quickly because every service implements the rules slightly differently, and each version drifts as teams change. A policy decision point evaluates the same request the same way every time, while a policy enforcement point applies the result inside the service or gateway. That separation matters because it makes authorization testable, auditable, and easier to govern at scale.

Practical implication: pull critical access rules out of application code and govern them through one decision layer.

Why AI agents stress runtime authorization

AI agents do not just increase request volume. They also increase delegation complexity because one actor can chain tool calls across systems in ways no human operator would manually perform. That means least privilege can no longer be treated as a static provisioning exercise. The policy system must evaluate the principal, the target, the action, and the live context each time. In practice, runtime authorization becomes the control that limits blast radius when agents explore paths that human reviewers never anticipated.

Practical implication: design authorization for delegated, high-frequency machine traffic rather than for human-paced access patterns.

PAP, PDP, PEP, and PIP in a modern authorization stack

The article frames the standard authorization model clearly. The policy administration point is where policies are authored and versioned. The policy decision point evaluates the request. The policy enforcement point blocks or allows the action inside the application. The policy information point supplies context such as identity attributes, environment signals, or resource state. This architecture is not new, but AI agents make it operationally necessary because every decision must be repeatable, explainable, and fast enough to sit in the critical path.

Practical implication: map each service to a clear policy flow so authorization decisions remain explainable and enforceable.

Threat narrative

Attacker objective: The objective is to use delegated machine access to reach more systems and more data than the original authorization intended.

1. Entry begins when an AI agent is granted valid delegated access and starts operating across services at machine speed, often through a workload or MCP-style integration rather than a human login.
2. Escalation occurs when the agent chains tool calls and reaches services beyond the original human user's intent, exploiting authorization rules that were never designed for runtime delegation depth.
3. Impact lands as overbroad access, data exposure, or unintended actions across multiple systems, with blast radius expanding because the policy model cannot keep pace with the agent's execution rate.

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 management is now the missing control plane for AI agents. Identity got the industry to the front door, but it did not solve runtime decisions inside applications, services, and delegated machine workflows. The article is right to frame the problem as an authorization gap because login success tells you nothing about whether a principal should be allowed to act in a given context. The practitioner conclusion is that IAM programmes now need a governed decision layer, not just better authentication.

Policy decisions must stay deterministic because AI is the wrong thing to place in the critical path of access control. The source article correctly separates AI-assisted policy authoring from runtime enforcement, and that distinction matters. If the decision itself becomes non-deterministic, audits, incident response, and control testing all degrade. The practical conclusion is that AI can support policy design, but access decisions need a reproducible control path.

Runtime authorization blind spots are becoming identity blast radius problems: once agents can chain actions across systems, the failure is no longer a single overprivileged account but the propagation of excess reach through a connected stack. The article shows why overprivileged policies that were tolerable in human workflows become load-bearing liabilities under agent traffic. The practitioner conclusion is that authorization scope now has to be managed as a blast-radius issue, not just a role-design issue.

Delegation chains make agent governance a cross-domain identity problem. The article moves from human-to-app access into human-to-agent-to-service patterns, which is where classic IAM boundaries start to blur. That is why NHI governance, workload identity, and runtime authorization now have to be treated as one discipline rather than separate teams. The practitioner conclusion is that access governance must follow the delegation chain, not the directory tree.

Policy propagation speed is itself a security control. When revocation or policy change takes a deploy cycle, the control lags behind the threat. In an environment where agents can create thousands of calls in a short window, delay becomes exposure. The practitioner conclusion is that authorization changes need to move at machine speed, or the control is already late.

From our research:

• Only around 14% of organizations say they have adequate governance for agents today, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• For a broader governance lens, see OWASP Agentic AI Top 10 for runtime risks that map directly to delegated authorization failures.

What this signals

Authorization will become the first control to fail at agent scale. As more enterprises delegate decisions to AI systems, the question is no longer whether identity can be verified but whether policy can keep pace with runtime behaviour. Teams that still treat authorization as a line-of-code concern will discover that the control boundary moved, but their governance model did not. For a useful standards lens, align early with the OWASP Top 10 for Agentic Applications 2026.

Identity programmes need a better view of non-human principals. Service accounts, agents, and workloads increasingly share the same privilege pathways, so governance should shift from directory-centric reviews to execution-centric policy design. That is why runtime authorization, workload identity, and revocation speed need to be measured together rather than in separate operational silos. The same logic applies whether the actor is a service account or an AI agent.

The next maturity step is not more login friction. It is tighter control over who or what can act, where it can act, and how quickly that decision can be changed when the environment shifts. In practical terms, the organizations that build a durable policy layer now will be better positioned to absorb agent growth without turning every new deployment into an access review emergency.

For practitioners

• Externalize high-risk authorization decisions Move privileged and agent-facing checks out of application code into a dedicated decision layer so the rules can be versioned, tested, and audited consistently across services.
• Map delegated access paths end to end Trace how a human request becomes agent activity, then service calls, then data access, so you can see where policy breaks as delegation expands across systems.
• Treat policy propagation as an incident response metric Measure how quickly authorization changes reach every enforcement point, because delayed revocation leaves a live window for agent-driven misuse.
• Register workloads and agents as first-class principals Include service accounts, AI agents, and MCP-connected workloads in the same policy model as humans so overprivilege is visible across the full identity surface.

Key takeaways

• AI agents expose a longstanding authorization gap that authentication-centric IAM programmes never solved.
• When delegated machine actors can chain actions across services, overprivilege becomes a blast-radius problem, not just a role-design problem.
• The control that matters most is a deterministic, centrally governed authorization layer that can be enforced and revoked at runtime.

Key terms

• Authorization Management Platform: A centralized layer for making access decisions at runtime instead of hard-coding them inside applications. It separates policy authoring, decision, enforcement, and context collection so teams can govern access consistently across services, workloads, and delegated machine actors.
• Policy Decision Point: The component that evaluates a request against policy and returns allow or deny. In agentic and NHI environments, the decision point must be deterministic, auditable, and fast so access can be governed in the critical path without relying on application-specific logic.
• Policy Enforcement Point: The place where an application, gateway, or service applies the authorization decision. It is the control that turns policy into action, which is why enforcement needs to be present wherever a principal can call a resource or tool.
• Delegated Machine Access: Access exercised by a non-human actor on behalf of a human or another system. The important issue is not only who requested the access, but how far the delegated actor can chain actions once runtime execution begins.

Deepen your knowledge

AI agent authorization and runtime policy design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for delegated machine access, it is worth exploring.

This post draws on content published by Cerbos: AI agent authorization gaps and runtime access control. Read the original.