They complicate IAM and IGA because the actor can exercise access dynamically rather than through a stable, human-paced workflow. That means recertification, SoD, and exception handling may all occur after the action has already happened. The control issue is timing, not just scope.
Why This Matters for Security Teams
agentic ai changes IAM and IGA because the protected actor is no longer a predictable human account with stable, reviewable access patterns. An agent can decide at runtime which tool to call, which API to chain, and which data to retrieve, often faster than a review cycle can respond. That makes traditional access certification and exception workflows necessary, but no longer sufficient on their own.
The practical risk is not just over-privilege. It is the mismatch between how identity programmes are designed and how autonomous systems actually behave. Current guidance from the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 both point toward runtime governance, not just periodic review. NHIMG research also shows the scale of the problem: the AI Agents: The New Attack Surface report says 80% of organisations have already seen agents act beyond intended scope.
In practice, many security teams encounter excessive access only after an agent has already accessed data, called a downstream service, or exposed secrets rather than through intentional review.
How It Works in Practice
The control model has to move from static assignment to runtime authorisation. For agentic systems, that usually means pairing workload identity with short-lived credentials, then evaluating each request against current context: the task, the tool, the data classification, the approval state, and the agent’s execution path. A long-lived service account with broad API scope is a poor fit because an agent does not follow a single fixed workflow.
Practitioners increasingly use workload identity primitives such as SPIFFE or OIDC-backed tokens to prove what the agent is, while policy engines such as OPA or Cedar decide what it may do at that moment. That is the operational difference between a human directory record and an autonomous workload. The identity assertion says “this is the agent,” but the policy decision says “this specific action is allowed now.”
- Issue JIT credentials per task, not per environment, and revoke them automatically when the task ends.
- Bind access to context, such as approved objective, data sensitivity, and allowed tool chain.
- Log every tool invocation and policy decision so IGA can review behaviour, not just memberships.
- Restrict secrets exposure because autonomous systems can chain access paths faster than humans can intervene.
This aligns with NHIMG guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the OWASP NHI Top 10, both of which emphasize lifecycle discipline and exposure minimisation for non-human actors. These controls tend to break down when agents are allowed to discover new tools at runtime because the approval boundary moves faster than governance can reclassify the access path.
Common Variations and Edge Cases
Tighter runtime controls often increase operational overhead, so organisations have to balance stronger containment against developer friction and slower automation. There is no universal standard for agentic IGA yet, and current guidance suggests treating the agent as a dynamic workload first, then layering human-style governance only where it actually fits.
One edge case is delegated agent behaviour, where the AI system acts on behalf of a user but also retains its own tool permissions. Another is multi-agent orchestration, where each agent has a narrow role but the combined workflow creates emergent privilege. In both cases, SoD and recertification need to account for the full chain of action, not just the individual component identities. That is why the CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix are useful complements to IAM, since they model how agents fail under pressure or are manipulated into unintended actions.
For high-risk environments, NHIMG research such as the Moltbook AI agent keys breach and DeepSeek breach reinforces a simple rule: once an agent can touch secrets, assume those secrets may be used in ways the approval workflow never anticipated.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 | Agentic apps need runtime controls for dynamic tool use and emergent privilege. |
| CSA MAESTRO | M3 | MAESTRO models how autonomous agents expand attack paths beyond static IAM. |
| NIST AI RMF | AI RMF covers governance for autonomous AI behaviour and accountability. |
Threat-model agent workflows and add controls for tool chaining, delegation, and escalation.
