Why do AI agents break traditional identity and access management models?

Why Traditional IAM Fails for Autonomous AI Agents

Traditional IAM was built around a stable subject, a bounded role, and a human-style workflow. AI agents do not behave that way. They can decide mid-task which tools to call, chain actions across systems, and expand the scope of a session in ways RBAC never anticipated. That is why static roles, pre-issued tokens, and one-time approval flows often fail to describe what the agent is actually doing at runtime.

For security teams, the issue is not just authentication, but authorization drift. An agent can begin with a legitimate purpose and still end up reading data, invoking APIs, or generating secrets-related side effects that were never intended. Current guidance from OWASP Agentic AI Top 10 and NIST AI Risk Management Framework treats this as a runtime governance problem, not a traditional login problem.

NHIMG research shows the scale of the identity gap: AI Agents: The New Attack Surface report found that 80% of organisations reported AI agents had already performed actions beyond intended scope. In practice, many security teams encounter overreach only after data exposure or tool abuse has already occurred, rather than through intentional design review.

How It Works in Practice

The practical answer is to shift from pre-authorization to intent-based, context-aware authorization. Instead of asking only “who is this?”, controls must ask “what is the agent trying to do, with which tool, over which data, and under what conditions?” That means policy evaluation at request time, not just at sign-in time. Policy-as-code engines such as OPA or Cedar are often used for this pattern, although there is no universal standard for which engine to choose yet.

In agentic environments, the identity primitive should be workload identity, not a long-lived secret tied to a vague service role. Cryptographic identity from patterns such as SPIFFE/SPIRE or OIDC-backed workload credentials can prove what the agent is, while JIT provisioning can issue short-lived access for a single task. This is where Ultimate Guide to NHIs becomes relevant: credential sprawl, poor rotation, and weak visibility are already major NHI failures, and agents amplify all three.

• Issue ephemeral secrets per task, not reusable credentials for the whole session.
• Bind each token to a narrow purpose, data domain, and expiration window.
• Re-evaluate access on every tool call, especially when the agent changes objective.
• Log every request, decision, and downstream action for audit and rollback.

The point is to make scope explicit and revocable. For threat modeling, teams can pair the CSA MAESTRO agentic AI threat modeling framework with OWASP NHI Top 10 to map where tool chaining, prompt injection, and privilege expansion intersect. These controls tend to break down when an agent can orchestrate multiple internal services with inconsistent policy enforcement, because one permissive hop can nullify the rest.

Common Variations and Edge Cases

Tighter runtime control often increases operational overhead, requiring organisations to balance reduced blast radius against latency, policy complexity, and developer friction. That tradeoff is especially visible in multi-agent systems, where one agent delegates to another and each handoff can multiply the number of authorisation decisions.

Best practice is evolving, but current guidance suggests that agent-to-agent delegation should never inherit broad standing privilege. Instead, each sub-agent should receive only the minimum context and capability needed for a single bounded action. This is where short-lived secrets and ZSP matter most: long-lived tokens become especially dangerous when an agent can cache, replay, or pass credentials to another tool. NHIMG’s Top 10 NHI Issues and NHI Lifecycle Management Guide both reinforce that lifecycle control, rotation, and offboarding are foundational, but agents make those controls time-sensitive in a new way.

There is also a boundary case with read-only agents. Even when an agent cannot directly write to systems, it may still expose sensitive data, infer credentials, or prepare malicious follow-on actions for a human or another agent. That is why “read-only” is not equivalent to “safe.” The practical pattern is to combine ZTA, PAM, and JIT with continuous monitoring and step-up approval for high-risk actions. This aligns with the NIST Cybersecurity Framework 2.0, which emphasises risk-based control across the full operating lifecycle, not just perimeter enforcement.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• Should companies develop centralized identity management practices for AI agents?
• Why do AI agents create a different access-risk profile than traditional applications?
• When is it crucial to implement least-privilege access for AI agents?