How does the rise of AI identities impact traditional IAM systems?

Why Traditional IAM Breaks Down for AI Identities

Traditional IAM is built around predictable users, devices, and service accounts. AI identities, especially autonomous agents, behave differently: they can decide what to do next, chain tools, and pursue goals across systems. That makes static RBAC, long-lived secrets, and pre-approved access lists too blunt for the real risk surface. Guidance from the NIST Cybersecurity Framework 2.0 still helps anchor governance, but it does not by itself solve agent autonomy.

The main impact is that identity decisions move from “who is this user?” to “what is this workload trying to do right now, and should it be allowed?” That shift exposes weaknesses in PAM, JIT, and approval workflows that were designed for human-paced activity. It also raises the stakes for secret handling, because an agent with broad tool access can turn a single exposed token into rapid privilege expansion. NHIMG research on the DeepSeek breach and JetBrains GitHub plugin token exposure shows how quickly secrets become an operational problem once they are reachable by automation. In practice, many security teams encounter agent identity failure only after an exposed secret or overbroad role has already been used.

How It Works in Practice

The practical response is to treat the agent as a workload identity first, then layer authorization around task intent. That usually means short-lived credentials, per-task scoping, and runtime policy evaluation instead of static entitlements. The industry is still converging on implementation details, but current guidance suggests combining zero standing privilege with context-aware controls so the agent receives only the access needed for the current action.

• Use workload identity primitives such as SPIFFE-style identities or signed OIDC assertions to prove what the agent is, not just what secret it holds.
• Issue JIT credentials with short TTLs and automatic revocation when the task completes or the policy context changes.
• Enforce intent-based authorisation so access is approved at request time, based on the agent’s goal, tool chain, data sensitivity, and environment.
• Keep secrets dynamic and scoped to the smallest possible blast radius, because long-lived tokens are especially dangerous for autonomous behaviour.

That model is reinforced by NHIMG research showing that 88.5% of organisations acknowledge their non-human IAM practices lag behind or merely match human IAM, and only 19.6% express strong confidence in secure NHI management. Pair that with the governance lens in NIST Cybersecurity Framework 2.0, and the operational takeaway is clear: discover the agent, prove its workload identity, authorize the task, then revoke access immediately after use. These controls tend to break down when agents operate across hybrid and multi-cloud estates because policy consistency, token propagation, and revocation latency become difficult to maintain.

Common Variations and Edge Cases

Tighter control often increases orchestration overhead, so organisations have to balance autonomy against operational friction. That tradeoff is especially visible when agents are allowed to call external APIs, trigger workflows, or hand off between multiple tools.

One common variation is the difference between a narrow assistant and a goal-driven agent. A chat-style assistant may fit a simpler access model, while an agent that can browse, query, execute, and retry needs real-time policy checks and stronger guardrails. Another edge case is delegated access inside multi-agent systems, where one agent’s output becomes another agent’s input. In those environments, trust can compound faster than teams expect, so identity, approval state, and provenance need to follow each handoff.

There is also no universal standard for how much autonomy should be permitted before human review is mandatory. Best practice is evolving, but the safest pattern is to reserve irreversible actions, production changes, and sensitive data movement for explicit approval. The same applies to secret distribution: insecure sharing methods remain common, and NHIMG research found 23.7% of organisations still share secrets through email or messaging apps. In sensitive workflows, that risk is amplified by the Azure Key Vault privilege escalation exposure pattern, where a single access path can expand far beyond the original intent.

Related resources from NHI Mgmt Group

• What is the difference between managed identities and hardcoded secrets for AI agents?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• What evidence is needed to understand the impact of shadow AI agents?
• Why is identity such a critical factor in securing AI agent systems?