Why do AI agents create new risk for IAM and NHI programmes?

Why This Matters for Security Teams

AI agents change the security problem because they are not just calling APIs, they are deciding when to act, which tools to chain, and how long to keep going. That creates risk at runtime, not only at provisioning time. Static RBAC was built for predictable human workflows, but an agent can pivot across systems in ways the original access model never anticipated. The result is a bigger attack surface for IAM, PAM, and NHI programmes that still assume stable job roles.

This is why current guidance increasingly points to workload identity, JIT credentials, and policy evaluation at request time rather than broad standing access. NHI teams should treat the agent itself as a governed identity, then separately govern the secrets and tokens it uses. NHIMG research on OWASP NHI Top 10 and external guidance such as the NIST AI Risk Management Framework both stress governance over behaviour, not just accounts. In practice, many security teams encounter agent risk only after an allowed workflow has already touched data it should never have reached.

How It Works in Practice

The practical shift is from static entitlement design to intent-based authorisation. Instead of asking whether an agent “belongs” to a role, security teams ask what the agent is trying to do right now, with what data, in what environment, and under what constraints. That decision can be enforced with policy-as-code and evaluated at request time. Emerging models often pair ZTA principles with workload identity such as SPIFFE or OIDC so the platform can verify what the agent is before granting any action. That is more precise than treating the agent like a service account with broad standing permissions.

For this to work, short-lived secrets matter. JIT credential issuance limits blast radius because credentials expire after the task, not after an arbitrary calendar cycle. This is especially relevant where agents handle API keys, tokens, or certificates across multiple tools. The challenge is real: the Top 10 NHI Issues highlight how quickly unmanaged secrets and weak lifecycle discipline create exposure, while the OWASP Agentic AI Top 10 frames agent misuse, tool abuse, and over-permissioning as first-order risks.

• Use workload identity as the primary control plane for agent authentication.
• Issue JIT credentials with short TTLs and automatic revocation on task completion.
• Separate the agent identity from the secrets it can broker or retrieve.
• Evaluate policy at runtime using context, not just a preassigned role.

Where organisations need a deeper operating model, the CSA MAESTRO agentic AI threat modeling framework and NHIMG’s 52 NHI Breaches Analysis both reinforce that identity governance must follow the execution path, not just the login event. These controls tend to break down when agents span hybrid and multi-cloud estates because policy, token exchange, and secret storage are rarely uniform across every platform.

Common Variations and Edge Cases

Tighter control often increases orchestration overhead, requiring organisations to balance reduced blast radius against developer velocity and operational complexity. That tradeoff is real, especially where agents are embedded into customer support, coding, or SOC workflows and need rapid access to multiple systems.

There is no universal standard for this yet, but best practice is evolving in a few directions. First, fully autonomous agents usually need stricter guardrails than human-assisted copilots because their tool use is more variable. Second, multi-agent systems require separate identity and policy boundaries so one agent cannot inherit another agent’s privileges by default. Third, secrets delivery should favour ephemeral exchange over shared vault access whenever possible. NHIMG’s Analysis of Claude Code Security is useful for understanding why code-centric agents need tighter runtime control, while the NIST AI Risk Management Framework and NIST Cybersecurity Framework 2.0 help anchor accountability and continuous monitoring.

The biggest exception is legacy automation that masquerades as an agent. If the workflow is deterministic, narrow, and tightly scripted, conventional service-account governance may still be adequate. But once the system can reason, choose tools, or adapt its next step, it should be governed as an autonomous identity with runtime constraints, not a static application account.

Related resources from NHI Mgmt Group

• Why do AI agents create new risk in non-human identity management?
• 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?
• Why do AI agents create more risk when they reuse existing credentials?