Why do AI programmes create new identity risk for CISOs?

Why This Matters for Security Teams

AI programmes do not just add another application tier. They introduce autonomous workloads, new service accounts, extra tokens, model connectors, and more approvals that often sit outside the normal IAM review cycle. That is why the identity risk profile changes so quickly: the organisation is no longer only governing people, but also software that can request access, chain tools, and act on its own intent. NHI management becomes central, not optional, and the issue is amplified when AI is piloted faster than access governance can keep up. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong signal of how quickly AI-connected identities can drift from least privilege. NIST guidance in the NIST Cybersecurity Framework 2.0 reinforces that identity and access discipline must be continuous, not a one-time setup. In practice, many security teams encounter AI identity sprawl only after a model or agent has already been given standing access to production data, rather than through intentional design.

How It Works in Practice

The core problem is that traditional RBAC assumes stable roles and predictable access patterns. Autonomous AI agents do not behave that way. A single agent may need to read a ticket, call a tool, query a database, invoke MCP-connected services, and then hand off to another workflow, all within one task. Static role assignment can overgrant by default, because the role has to anticipate every possible path the agent might take. That is why current guidance increasingly points toward intent-based authorisation, where access is evaluated at runtime based on what the agent is trying to do, in what context, and against which resource. The Top 10 NHI Issues and OWASP NHI Top 10 both point to the same practical outcome: standing privilege and long-lived secrets are a poor fit for agentic systems. A workable pattern usually includes:

• JIT credential issuance for each task, with automatic revocation when the task ends.
• Short-lived secrets and workload identity, rather than embedded API keys or shared service accounts.
• Policy-as-code and real-time evaluation, so approvals reflect current context instead of pre-set assumptions.
• Separate identities for each tool, workflow, or agent boundary to reduce blast radius.

NIST AI governance concepts and Zero Trust thinking also support this approach, especially when paired with NIST Cybersecurity Framework 2.0. For implementation, many teams align with workload identity patterns such as SPIFFE and short-lived OIDC tokens so the system can prove what the agent is, not just what secrets it holds. These controls tend to break down when agents are allowed to keep reusable tokens across multiple tasks because the identity boundary becomes too weak to enforce task-level intent.

Common Variations and Edge Cases

Tighter controls often increase operational overhead, so organisations have to balance stronger containment against the friction of more frequent approvals, token issuance, and policy maintenance. That tradeoff is especially visible in multi-agent environments, where one agent may broker access for another, or where vendors expose opaque integrations that do not map cleanly to internal RBAC. There is no universal standard for this yet, so best practice is evolving: some teams prioritise JIT credentials first, while others begin with workload identity and then layer intent-based policy on top. The biggest edge case is delegated or semi-autonomous AI, where human operators believe they still control the workflow but the agent can act faster than review processes can respond. That is one reason the 52 NHI Breaches Analysis remains useful: it shows how quickly excessive privilege and secret exposure become breach paths once identities are treated as plumbing instead of security assets. The practical lesson is to treat AI programme identity as part of the core control plane, not as an experiment in a separate lane. Where autonomy is high and tool access is broad, the model breaks down fastest if secrets are static, shared, or reused across environments.

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?
• When does AI agent access create more risk than it reduces?
• When do AI agent credentials create more risk than they reduce?