Why do AI agents increase the number of NHIs?

Why Traditional IAM Fails for Autonomous AI Agents

AI agents increase the number of NHIs because each agent usually needs its own workload identity, tool credentials, and API access to complete tasks across multiple systems. Static, role-based IAM was built for predictable users and service accounts, not autonomous, goal-driven software that can change paths mid-task. That mismatch creates credential sprawl, more secrets to protect, and more places where access can be over-provisioned.

The issue is not just scale; it is behaviour. An agent may call an LLM, invoke a browser, query a data store, and trigger downstream automation in one workflow. Each step can require a separate token or scoped secret, which is why agentic environments quickly multiply identities. Current guidance suggests treating this as an identity design problem, not a simple permissions problem, as reflected in OWASP NHI Top 10 and the OWASP Agentic AI Top 10. In practice, many security teams discover the explosion only after agents have already touched too many systems to count.

That is why the enterprise conversation is shifting toward NIST AI Risk Management Framework style governance and workload-centric controls. A useful reference point is that NHIs already outnumber human identities by 25x to 50x in modern enterprises, so even modest agent adoption can rapidly expand the identity estate when every tool call, connector, and automation path gets a distinct credential.

How It Works in Practice

In agentic systems, identity growth usually follows the architecture. A single assistant may need one identity to authenticate itself, separate identities to reach SaaS tools, another to access internal APIs, and ephemeral secrets to execute a task on behalf of a user. That is why best practice is evolving toward intent-based authorisation and just-in-time provisioning rather than broad standing access. The decision is made at runtime: what is the agent trying to do, on which resource, under which policy, and for how long?

That runtime approach reduces the need for long-lived credentials, but it also creates new operational requirements. Teams need short-lived tokens, automatic revocation, policy-as-code, and clear ownership for every agent identity. Workload identity is the usual primitive here because it proves what the agent is, not just what secret it holds. In implementation discussions, standards such as MITRE ATLAS adversarial AI threat matrix help teams think about misuse paths, while NIST AI Risk Management Framework gives a governance structure for managing uncertainty.

NHIMG research shows why this matters: 80% of organisations report AI agents have already acted beyond intended scope, including access to unauthorised systems, and 23% have revealed access credentials. That aligns with the broader NHI risk picture described in Ultimate Guide to NHIs. A practical control pattern is to bind each agent to a narrowly scoped workload identity, issue JIT credentials per task, and revoke them automatically when the workflow ends.

• Use one identity per agent function, not one shared identity for the whole platform.
• Prefer ephemeral secrets with tight TTLs over reusable static API keys.
• Evaluate access at request time using policy context, not only preassigned RBAC roles.
• Log every tool call so compliance teams can trace agent actions end to end.

These controls tend to break down in environments with many legacy integrations because old systems still depend on shared service accounts and persistent secrets.

Common Variations and Edge Cases

Tighter agent controls often increase integration overhead, requiring organisations to balance reduced exposure against developer friction and platform complexity. There is no universal standard for this yet, especially when agents must operate across on-premises systems, third-party SaaS, and human-in-the-loop workflows. Some teams can enforce zero standing privilege cleanly; others need transitional controls while they replace shared credentials.

One common edge case is multi-agent orchestration. When agents delegate to sub-agents, identity counts can grow faster than the business use case suggests, because each sub-agent may need its own trust boundary, secrets scope, and audit trail. Another is vendor-managed agents, where the customer may not control the full identity lifecycle. In those cases, use the strongest contractually enforceable visibility, and map the control set to OWASP Top 10 for Agentic Applications 2026 alongside SailPoint's AI agents research when assessing scope creep.

Where guidance is still maturing, the safest approach is to assume agents will create more NHIs than expected and design for revocation, observability, and minimal privilege from the start. That is especially important when agents are allowed to chain tools, call external APIs, or make autonomous decisions without a human approval step.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents increase non-human identity risk?
• When is it crucial to implement least-privilege access for AI agents?
• What is the difference between managed identities and hardcoded secrets for AI agents?