Agentic AI security exposes the limits of identity and access management

At a glance

What this is: This is an editorial analysis arguing that agentic AI is exposing the long-standing split between authentication and authorization, with the key finding that governing agent behaviour after login is the real problem.

Why it matters: It matters because IAM, PAM, NHI, and human governance programmes will need different controls for identity verification and runtime access decisions as agentic systems become more common.

👉 Read Authzed's analysis of agentic AI security and authorization

Context

Agentic AI is forcing identity teams to separate two jobs that IAM has often bundled together: proving who something is, and deciding what it can do next. The article argues that authentication and authorization are not interchangeable, and that treating them as one discipline creates blind spots for AI agents that make runtime decisions.

For IAM practitioners, this is a governance question as much as a technical one. Authentication can be scaled with familiar federation and login controls, but authorization must handle dynamic actions, multiple systems, and low-latency decisions without assuming deterministic behaviour.

Key questions

Q: How should security teams govern agentic AI after authentication succeeds?

A: They should govern agentic AI as a runtime authorization problem, not as a login problem. Once an agent is verified, the critical question becomes what it may do, which tools it may invoke, and how its permissions are evaluated as conditions change. That requires policy that can react to context and request patterns, not just a one-time access decision.

Q: Why do role-based controls struggle with agentic AI?

A: Role-based controls struggle because agents do not behave like stable process actors. They can choose different tools and action paths at runtime, which means a fixed role often over-grants to stay useful or under-grants to stay safe. The result is either excess privilege or blocked automation, both of which create operational and security problems.

Q: When does authentication stop being enough for an AI agent?

A: Authentication stops being enough the moment the agent begins making repeated or branching decisions after it is trusted in. A valid login proves identity at entry, but it does not control future actions, tool use, or scope changes. For agentic systems, that post-login behaviour is where the real governance risk begins.

Q: What should organisations do when authorization logic lives inside applications?

A: They should treat application-level authorization as part of the identity programme, not as a separate development detail. If policy is buried in code, IAM teams need visibility into who owns it, how quickly it changes, and whether it can handle high-frequency decisions from agents without breaking business workflows.

Technical breakdown

Authentication vs authorization in agentic AI

Authentication answers identity proof, while authorization answers permitted action. In agentic systems, those are not the same problem because an agent may be verified once and then continue acting across many requests, tools, and contexts. That separation matters more when the actor can choose its own sequence of actions at runtime. The article’s core point is that stronger login does not solve post-login governance. Practical access control still has to decide what an agent may do after it has been trusted once.

Practical implication: teams should model agent governance as a runtime authorization problem, not as a login-hardening problem.

Why RBAC breaks down for non-deterministic agents

Role-Based Access Control works best when the actor’s duties are stable and predictable. Agentic AI does not fit that shape because the system may select different tools, paths, and requests in response to changing conditions. That makes fixed roles too blunt for the actual access pattern. The article’s point is not that RBAC disappears, but that it is too static to describe a non-deterministic workflow actor without either over-permissioning or blocking legitimate work. Practical control needs more expressive policy than coarse role assignment.

Practical implication: teams should test whether role design can represent real agent tasks without expanding access beyond necessity.

Runtime authorization must keep pace with low-latency decisions

Authorization at scale has a timing problem. If an agent makes many requests in quick succession, each decision has to be fast enough to avoid becoming the bottleneck. That pushes identity teams toward policy evaluation patterns that can operate continuously without assuming a human-paced approval cycle. The article highlights that authorization is embedded in application behaviour, so latency and consistency matter as much as correctness. For agentic AI, a slow decision path can become an operational failure even when the policy itself is sound.

Practical implication: teams should measure authorization latency and policy propagation as first-class operational controls.

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

Authentication and authorization are now separate governance problems, not a single IAM conversation. The article is right to split the two because agents can be verified once and still create repeated downstream access decisions. That means identity proof does not resolve post-login control, especially when the actor is non-deterministic. Practitioners should stop treating the login boundary as the end of identity governance.

RBAC is a starting point, not a sufficient model for agentic behaviour. Roles describe expected human or system duties, but they do not capture runtime tool choice or branching execution. When an agent can decide its own next step, fixed entitlement buckets become too blunt to govern actual risk. Practitioners should assume access models will need more expressive policy than roles alone.

Agentic AI is exposing the authorization debt hidden inside IAM programmes. The industry has long invested in authentication architecture while leaving application-level authorization fragmented and slow to evolve. That imbalance becomes visible when agents create high-frequency decisions that legacy business workflows never had to support. Practitioners should treat authorization modernization as a core identity programme priority, not a downstream engineering task.

Expressive runtime policy is becoming the named concept that matters most here. Agentic systems need policies that can evaluate context, action, and timing in motion, because static permission sets cannot describe every decision an agent may make. This is the control layer that sits between generic IAM and operational trust. Practitioners should evaluate whether their current access model can express runtime behaviour, not just assigned identity.

Authorization has become the decisive control plane for agentic security. The article correctly reframes the problem away from mere access entry and toward what happens after an agent is inside the system. That shift aligns with OWASP Agentic AI and zero trust thinking, where continuous decisioning matters more than a one-time trust event. Practitioners should anchor agent governance in authorization design, policy evaluation, and runtime enforcement.

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 shows how weak the control baseline still is, even before agentic systems are added to the mix.
• That visibility gap is why practitioners should also review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the offboarding and review processes that underpin runtime governance.

What this signals

Expressive policy is becoming the practical dividing line for agentic governance. Teams that still rely on coarse roles will find they can verify an agent but not describe its behaviour well enough to control it. The governance question is no longer whether the system can authenticate, but whether it can authorize dynamic action without drifting into excess privilege. For practitioners, that means policy modelling now belongs in the core identity programme, not in a side project.

The broader signal is that authorization ownership will spread beyond identity teams and into application and platform engineering. Agentic AI pushes enforcement closer to the workload, which means programme leaders need shared control definitions, shared logging, and shared response paths. Without that, identity governance becomes fragmented exactly where runtime decisions are most frequent.

For practitioners

• Separate identity proof from runtime access control Map authentication flows and authorization flows as distinct programme controls. Document where an agent is only being verified and where it is being allowed to act, then assign separate owners for each control plane.
• Test whether roles describe real agent tasks Run task-to-permission reviews for agent workflows and identify where coarse roles force either excess access or blocked execution. Replace role-only thinking with policies that can evaluate context, action, and request timing.
• Measure authorization latency as an operating risk Track policy decision time, propagation delay, and the number of checks required per request. If authorization cannot keep up with repeated agent actions, treat that as a governance failure rather than a tuning issue.
• Review application-level authorization ownership Assign explicit ownership for authorization logic embedded in applications, not just in central IAM tooling. Agentic AI will expose gaps where developers control enforcement but identity teams assume the policy layer is already complete.

Key takeaways

• Agentic AI exposes a hard split in IAM: identity proof and runtime permission are different controls with different failure modes.
• Static roles are too blunt for non-deterministic agents, because they cannot describe changing tool use and branching action paths safely.
• Practitioners need authorization models that can keep pace with repeated machine decisions, or login security will outgrow governance capacity.

Key terms

• Authentication: Authentication is the process of verifying that an identity is who or what it claims to be. In agentic systems, it establishes initial trust at entry, but it does not by itself govern later actions, tool calls, or changing scope during execution.
• Authorization: Authorization is the decision about what an authenticated identity may do, when, and under which conditions. For agentic AI, it becomes a runtime control problem because access decisions may need to be evaluated repeatedly as the system chooses new actions.
• Role-Based Access Control: Role-Based Access Control assigns permissions through predefined roles rather than evaluating every decision individually. It is useful for stable duties, but it becomes less precise when an agent can change tasks, tools, or request paths at runtime.
• Agentic AI: Agentic AI is software that can choose actions and act toward a goal with some degree of independence. In identity governance, the key issue is not just that it is automated, but that its runtime decisions can make static access models incomplete.

Deepen your knowledge

Agentic AI authorization and runtime policy are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are reworking IAM for non-deterministic systems, it is a useful starting point.

This post draws on content published by Authzed: securing agentic AI through the lens of identity and access management. Read the original.