Why do static IAM and IGA models struggle with AI agents?

Why This Matters for Security Teams

Static IAM and IGA were built for stable human access patterns, not autonomous software that can chain tools, change tasks mid-flight, and act faster than certification cycles. For AI agents, the risk is not just who approved access, but what the agent did with that access in the moment. That is why current guidance increasingly points to runtime controls, workload identity, and just-in-time authorisation rather than after-the-fact review alone. The OWASP NHI Top 10 and the NIST AI Risk Management Framework both reflect this shift toward managing dynamic behaviour, not just stored entitlements.

NHI Management Group research shows the gap is already operational: in the AI Agents: The New Attack Surface report, 80% of organisations said their AI agents had already acted beyond intended scope, while only 44% had implemented policies to govern them. In practice, many security teams encounter this mismatch only after an agent has already accessed the wrong system, shared sensitive data, or exposed credentials, rather than through intentional governance design.

How It Works in Practice

The control problem changes once an agent is allowed to reason, plan, and execute. A static role like “read-only analyst” does not describe a live sequence of tool calls, prompts, API invocations, and conditional branching. Instead, security teams are moving toward intent-based or context-aware authorisation, where policy evaluates the task at request time and decides whether the action is acceptable in that moment. That usually means combining policy-as-code with workload identity and ephemeral credentials.

In practical terms, the agent should present a cryptographic workload identity, such as an OIDC token or SPIFFE-based identity, then receive short-lived secrets only for the current task. This limits blast radius if the agent is misled, compromised, or simply behaves unexpectedly. Runtime policy engines can then apply context such as data sensitivity, target system, approval state, and the agent’s current objective. This is the model described across the OWASP Agentic AI Top 10, the CSA MAESTRO agentic AI threat modeling framework, and the NIST AI Risk Management Framework.

• Issue identity to the workload, not to an assumed human proxy.
• Bind access to the specific task, data class, and approval context.
• Use JIT secrets with automatic revocation on completion.
• Log every tool call, token exchange, and policy decision for auditability.

NHI Management Group has documented the real-world consequences in the AI LLM hijack breach and the DeepSeek breach, where exposed secrets and weak containment created immediate abuse paths. These controls tend to break down when agents are allowed broad tool access across multiple systems because the policy layer cannot keep pace with the agent’s branching workflow.

Common Variations and Edge Cases

Tighter runtime control often increases latency and operational overhead, so organisations have to balance safety against developer productivity and agent throughput. Best practice is evolving, and there is no universal standard for exactly how much autonomy should be pre-approved versus re-evaluated on every step. The right answer often depends on whether the agent is advisory, transactional, or allowed to perform irreversible actions.

Two edge cases cause static IAM and IGA to fail especially quickly. First, multi-agent systems can inherit and pass tokens between services, making a simple role review misleading because authority is effectively being delegated in motion. Second, long-lived credentials are particularly dangerous for agents because their behaviour is not stable over time; a token that was safe for one workflow may become excessive after a prompt change, tool change, or data-source expansion. Current guidance suggests treating secrets as disposable and access as conditional, not permanent.

This is where the Moltbook AI agent keys breach and the NIST AI Risk Management Framework are useful references: both reinforce that exposure windows matter more when the workload can act autonomously. The common failure point is environments that still certify access on a monthly or quarterly cycle while the agent is making real-time decisions every few seconds.

Related resources from NHI Mgmt Group

• Why do AI agents change IAM and IGA operating models?
• Why do static IAM roles break down for AI agents?
• Why do AI identities complicate existing IAM and IGA models?
• Why do AI agents increase non-human identity risk in existing IAM programmes?