Should organizations adapt their IAM strategies to include AI agents?

Why Traditional IAM Fails for Autonomous AI Agents

AI agents are not just another workload or service account. They act with goals, can chain tools, and may make decisions at runtime that no static role model can fully anticipate. That is why conventional IAM, which assumes stable job functions and predictable access patterns, becomes fragile as soon as an agent can browse, call APIs, open tickets, or modify records on its own.

This is not a theoretical concern. NHIMG research on the OWASP NHI Top 10 highlights the security implications of agentic applications, while the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point toward governance that adapts to behaviour, not just identity labels.

The practical issue is that an agent can pivot from one approved action to a materially different one in a single workflow step. A prompt, tool output, or external event may change what it tries next, which means a role granted at deployment time may be too broad, too narrow, or both. In practice, many security teams encounter agent overreach only after an unauthorized action or data exposure has already occurred, rather than through intentional control design.

How It Works in Practice

Security teams should treat AI agents as autonomous identities that need workload-level proof, tightly scoped privileges, and request-time policy checks. The current best practice is moving toward intent-based authorisation: the system evaluates what the agent is trying to do, what data it needs, what tool it is calling, and whether the action fits the approved context. That is a better fit than pre-defined RBAC alone, because RBAC cannot express every combination of task, dataset, and risk condition.

Operationally, that means pairing workload identity with short-lived credentials. For example, a service may issue a cryptographically verifiable identity for the agent, then mint just-in-time credentials for the exact task and revoke them on completion. This reduces blast radius if the agent is redirected or compromised. The same model supports ephemeral secrets rather than long-lived API keys, which is especially important when agents can act faster than humans can review. NHIMG has shown why this matters in AI LLM hijack breach coverage and in DeepSeek breach analysis, where exposed secrets created immediate exposure paths.

• Use workload identity as the primary agent identity primitive, not a shared human account.
• Issue JIT credentials per task with short TTLs and automatic revocation.
• Evaluate policy at request time using context, not only at provisioning time.
• Log tool calls, data access, and downstream actions for audit and incident response.

Frameworks such as the MITRE ATLAS adversarial AI threat matrix are useful for mapping attack paths, but implementation still depends on whether the agent can be constrained by policy-as-code and isolated tool permissions. These controls tend to break down when agents share credentials across environments because one compromised workflow can then inherit access to many systems.

Common Variations and Edge Cases

Tighter controls often increase deployment friction, requiring organisations to balance security benefits against latency, integration effort, and developer experience. That tradeoff is real, especially when agents must perform high-frequency actions or interact with legacy systems that were never designed for runtime policy evaluation.

There is no universal standard for this yet, but current guidance suggests separating low-risk read actions from high-risk write or credential-handling actions, then applying stronger approvals to the latter. For example, an agent that summarizes tickets may need only narrow read access, while an agent that creates infrastructure or moves money should be forced through a stricter approval path, step-up checks, or human confirmation. NHIMG’s Moltbook AI agent keys breach reporting and the Salt Typhoon US telecoms breach both reinforce the danger of exposed credentials and lateral movement.

Best practice is evolving for multi-agent systems as well. Shared memory, delegated tool use, and cross-agent handoffs can create hidden privilege transfer that looks harmless in isolation. That is why guidance from OWASP Top 10 for Agentic Applications 2026 and the Anthropic AI-orchestrated cyber espionage campaign report matters: agents should be isolated by task, bounded by policy, and instrumented for continuous review rather than assumed safe because their inputs look benign.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• When should organizations prioritize the detection of shadow AI agents?
• How can organizations prioritize high-risk AI agents?
• Why do AI agents create more IAM risk than ordinary developer tools?