Why do AI agents break traditional IAM and RBAC models?

Why This Matters for Security Teams

AI agents do not fit the assumptions behind traditional IAM because their access is not tied to a stable person, fixed role, or predictable session. An agent can decide to call a different tool, pursue a new subtask, or chain actions in ways that were never enumerated when the role was designed. That makes RBAC a poor proxy for real operational intent.

Security teams usually feel this first as an over-permissioning problem, then as an audit problem. A role broad enough to keep the agent functional becomes difficult to justify, while a narrow role causes runtime failures that teams often workaround. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework points toward runtime controls, not static entitlements. NHIMG’s research on the AI Agents: The New Attack Surface report shows why this matters: 80% of organisations report agent actions beyond intended scope, including unauthorised system access and sensitive data exposure.

In practice, many security teams encounter agent overreach only after the agent has already touched data or systems that the original role model never anticipated.

How It Works in Practice

The practical answer is to move from role-first access to context-first access. That usually means treating the agent as a workload identity, issuing short-lived credentials per task, and evaluating policy at request time rather than granting a broad standing role. In other words, the question changes from “What job title does this tool have?” to “What is this agent trying to do right now, with what evidence, and against which resource?”

This approach is still evolving, but the direction is consistent across CSA MAESTRO agentic AI threat modeling framework, MITRE ATLAS adversarial AI threat matrix, and the OWASP NHI Top 10. The implementation pattern often includes:

• Ephemeral tokens issued for a single task or bounded workflow step.
• Policy-as-code checks that inspect tool, destination, data sensitivity, and time window.
• Workload identity primitives such as OIDC-backed identities or SPIFFE-style attestation, so the platform can verify what the agent is, not just what secrets it holds.
• Automatic revocation when the task ends, the plan changes, or confidence in the agent’s context drops.

This is also where The State of Secrets in AppSec becomes relevant: if leaked secrets are slow to remediate, then long-lived credentials create an unnecessary blast radius for autonomous systems. Short TTLs matter more for agents because their behaviour can change mid-run and their tools can multiply risk quickly.

These controls tend to break down in legacy environments with shared service accounts, brittle downstream APIs, or platforms that cannot evaluate policy at request time because the authorization layer is still tied to static directory roles.

Common Variations and Edge Cases

Tighter agent controls often increase operational overhead, requiring organisations to balance automation speed against stronger containment and review. That tradeoff becomes more visible in multi-agent workflows, where one agent may need to delegate to another, or in human-in-the-loop systems where a person approves one step but not the whole chain.

There is no universal standard for this yet. Best practice is evolving toward intent-based authorisation, but many enterprises still need transitional patterns such as scoped service principals, constrained tool registries, and approval gates for high-risk actions. The important nuance is that role design alone cannot express dynamic behaviour. A role can say an agent may read tickets or query a database, but it cannot reliably capture whether the next action is a safe lookup, a lateral move, or a credential-bearing escalation.

One practical edge case is retrieval-augmented systems that look passive but can still trigger destructive side effects through tool use. Another is vendor-managed agents, where the enterprise may control the data boundary but not the execution model. In those cases, governance must extend beyond IAM into workload attestation, logging, and explicit tool authorization. NHIMG’s OWASP Agentic Applications Top 10 and the published AI Agents: The New Attack Surface report both reinforce the same point: agents become dangerous when standing access outlives the task that justified it.

Related resources from NHI Mgmt Group

• Why do autonomous agents break traditional IAM assumptions?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more IAM risk than ordinary developer tools?
• How does the rise of AI identities impact traditional IAM systems?