Why do AI agents make IAM and NHI risk harder to manage?

Why This Matters for Security Teams

AI agents change the IAM problem because they do not behave like static service accounts. An agent can decide to call a new API, chain tools, or request more access mid-task, so access decisions must keep pace with intent rather than with a prewritten role. That is why static RBAC alone is a poor fit for autonomous systems, especially when the agent’s goals evolve during execution.

This is also where NHI risk becomes harder to manage: every tool call, token exchange, and secret retrieval is an identity event that may require a different trust decision. Current guidance suggests treating agents as workload identities with tight, ephemeral authority, not as long-lived applications with fixed permissions. For broader NHI governance context, see Top 10 NHI Issues and the OWASP NHI Top 10.

In practice, many security teams encounter the blast radius only after an agent has already overreached, not during the original access review.

How It Works in Practice

Managing agentic access starts with recognising that the agent is the actor, but the task is the context. A useful pattern is to bind the agent to a workload identity, then issue just-in-time credentials only for the specific action, system, or data set required for that task. That means short-lived secrets, automatic revocation, and runtime policy checks that can approve, deny, or constrain each request as the agent works.

This is where intent-based authorisation becomes important. Instead of asking whether an agent belongs to a broad role, the policy asks what the agent is trying to do right now, whether that action is expected, and whether the current context supports it. That context may include the prompt goal, the requesting service, the data classification, the environment, and whether the agent is attempting lateral movement or privilege chaining. For practical patterns, see the Ultimate Guide to NHIs and the Analysis of Claude Code Security.

Operationally, this is usually implemented with policy-as-code and workload identity standards such as SPIFFE or OIDC-backed tokens, then evaluated at request time rather than preapproved once for the lifetime of the agent. That aligns with the direction of the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework.

• Use JIT provisioning for tool access and revoke on task completion.
• Replace long-lived secrets with short TTL credentials and automatic rotation.
• Evaluate policy at each request, not only at session start.
• Log every tool call as an identity decision, not just an application event.

These controls tend to break down when agents are allowed to operate across hybrid estates with inconsistent identity standards because policy and revocation cannot keep up with the speed of execution.

Common Variations and Edge Cases

Tighter runtime controls often increase operational overhead, requiring organisations to balance autonomy against change management, debugging, and availability. That tradeoff is real, especially when agents support software delivery, customer workflows, or incident response where delays can hurt outcomes. There is no universal standard for this yet, so current guidance suggests starting with higher-risk actions such as secret retrieval, infrastructure changes, and data exports.

One common edge case is the “helpful” agent that needs broad access for a narrow task. In those environments, the safer approach is usually not a wider role, but a narrower task boundary plus stronger context signals. Another edge case is shared agent infrastructure, where one agent instance can inherit state from another. That creates confusion between machine identity, session identity, and task identity, which is why OWASP Agentic AI Top 10 and NIST Cybersecurity Framework 2.0 both matter when designing control boundaries.

A further complication is secret sprawl. The Moltbook AI agent keys breach is a reminder that if agents can retrieve static secrets, those secrets often become the real crown jewels. In mature environments, the answer is not to trust the model more, but to shrink standing privilege, separate duties across tools, and keep every secret ephemeral enough that misuse has a short half-life.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk for IAM and NHI programs?
• Why do AI agents make non-human identity governance harder?
• Why do AI agents increase non-human identity risk in existing IAM programmes?
• Why do AI agents create more IAM risk than ordinary developer tools?