Because they can create continuous, machine-paced access demand that exceeds the assumptions built into most IAM systems. Normal automation is usually bounded and predictable. Agentic systems can vary timing, sequence, and tool use at runtime, which pushes identity services into a reliability and governance problem at the same time.
Why This Matters for Security Teams
AI agents stress identity infrastructure because they do not behave like bounded jobs. A script runs, completes, and stops. An agent keeps deciding, chaining tools, retrying actions, and changing its sequence at runtime, which turns identity into a live control plane problem. That is why static roles, long-lived secrets, and pre-approved access paths stop being enough once autonomy enters the workflow. The issue is not just access volume, but access variability.
NHIMG research shows this shift is already visible: 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, yet 67% of organisations still rely heavily on static credentials despite the risk. That gap matters because identity systems are being asked to absorb both reliability demands and governance demands at the same time. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 points toward runtime controls, not just onboarding checks.
In practice, many security teams discover the identity problem only after an agent has already created excess tokens, crossed trust boundaries, or triggered an incident through legitimate tooling.
How It Works in Practice
Normal automation usually has a defined scope: one service account, one pipeline, one repeatable task. Agentic systems are different because the exact next action is not fixed ahead of time. The better pattern is to treat the agent as a workload with a cryptographic identity, then authorize each request based on task context, policy, and current risk. That is the direction described in Ultimate Guide to NHIs and reinforced by CSA MAESTRO agentic AI threat modeling framework.
In practice, that means four controls matter most:
- Use workload identity, not shared human-style accounts, so the agent proves what it is before it can act.
- Issue just-in-time credentials with short TTLs per task, then revoke them automatically when the task ends.
- Evaluate policy at request time, using policy-as-code and the full context of intent, data sensitivity, destination system, and recent behaviour.
- Separate coarse role assignment from fine-grained authorization, because static RBAC alone cannot keep up with autonomous tool selection.
Teams often pair SPIFFE or OIDC-based workload identity with secrets brokers, so the agent never holds durable credentials for long. That reduces blast radius when the agent chains tools, retries operations, or drifts into an unexpected workflow. For threat modelling, the MITRE ATLAS adversarial AI threat matrix is useful when agents can be manipulated into making unsafe identity decisions. These controls tend to break down in environments where legacy automation, human admins, and autonomous agents all share the same privileged pathways because attribution and revocation become ambiguous.
Common Variations and Edge Cases
Tighter identity controls often increase operational overhead, requiring organisations to balance autonomy against revocation speed and policy complexity. That tradeoff is especially visible in legacy enterprise stacks, where one agent may need to touch SaaS APIs, internal databases, and cloud control planes in a single workflow. There is no universal standard for this yet, so current guidance suggests favouring short-lived access, narrow scopes, and explicit approvals for high-impact actions rather than trying to make agents fit existing human IAM patterns.
Edge cases usually appear when the environment is highly dynamic. Multi-agent systems can compound risk because one agent’s output becomes another agent’s input, which increases the chance of privilege chaining or prompt-driven misuse. Long-running agents also create a persistence problem: if the process lives for days, credentials that were “temporary” in theory can become operationally sticky in practice. NHIMG’s 52 NHI Breaches Analysis and OWASP NHI Top 10 both underscore that poor scoping and weak secret hygiene are recurring failure modes.
The practical takeaway is simple: the more autonomous the system, the less useful static trust becomes. When agents can choose tools, change sequence, and operate continuously, identity must move from a one-time permission model to a runtime control model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A01 | Agent autonomy and tool chaining drive identity stress beyond static IAM. |
| CSA MAESTRO | MT.2 | MAESTRO addresses agent threat modeling and control boundaries for autonomous systems. |
| NIST AI RMF | AIRMF frames governance for autonomous AI risk, including identity-related controls. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | Short-lived secrets and rotation are central to agent workload safety. |
| NIST Zero Trust (SP 800-207) | SA-3 | Zero Trust fits agents needing continuous verification and least privilege. |
Assign accountability and test identity risks as part of AI governance reviews.
