TL;DR: Agentic AI security is exposing a structural split inside IAM: authentication verifies who a requestor is, while authorization governs what an agent can do after login, and those problems scale very differently, according to Authzed. The harder challenge is not access in, but governance after access, where non-deterministic agents outgrow static RBAC assumptions.
NHIMG editorial — based on content published by Authzed: securing agentic AI through the lens of identity and access management
Questions worth separating out
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.
Q: Why do role-based controls struggle with agentic AI?
A: Role-based controls struggle because agents do not behave like stable process actors.
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.
Practitioner guidance
- Separate identity proof from runtime access control Map authentication flows and authorization flows as distinct programme controls.
- 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.
- Measure authorization latency as an operating risk Track policy decision time, propagation delay, and the number of checks required per request.
What's in the full article
Authzed's full article covers the operational detail this post intentionally leaves for the source:
- How the article separates authentication from authorization in practical architecture terms
- The reasoning behind multiple authorization systems across partners, products, and application teams
- Why low-latency authorization matters when agents generate repeated checks per request
- How non-deterministic agent behaviour changes the assumptions behind RBAC and policy design
👉 Read Authzed's analysis of agentic AI security and authorization →
Agentic AI security: what IAM teams are missing about authorization?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Agentic AI security exposes the limits of identity and access management