Why do AI models create new IAM and NHI risks?

Why This Matters for Security Teams

AI models change the risk equation because they do not only request access, they can select tools, sequence actions, and persist toward a goal. That turns identity from a login problem into an execution-control problem. Traditional IAM, RBAC, and even strong PAM are not enough when the workload can improvise at runtime. Current guidance suggests security teams should treat these systems as autonomous Non-Human Identities, not just software accounts.

The practical consequence is broader blast radius. An agent with access to data, APIs, and internal tools can chain permissions in ways a human operator would never do on a predictable schedule. That creates exposure across provenance, intent, and tool invocation, not just credential storage. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, access control, and continuous monitoring, but it does not replace NHI-specific design choices. In practice, many security teams encounter these failure modes only after an agent has already misused a legitimate capability.

How It Works in Practice

For autonomous workloads, the identity question becomes: what is the agent allowed to do right now, for this task, in this context? That is why static RBAC often falls short. A role can say an agent may read a ticketing system or query a database, but it cannot reliably express whether the same agent should be able to escalate, loop through tools, or reuse a secret beyond the task boundary. The better pattern is intent-based authorisation, where policy is evaluated at request time and bound to the action the agent is attempting.

That model usually combines workload identity, ephemeral credentials, and real-time policy checks. A workload identity such as SPIFFE or OIDC proves what the agent is, while JIT provisioning issues short-lived access only for the task at hand. Secrets should be dynamic and automatically revoked, not copied into email, chat, or long-lived environment variables. The Top 10 NHI Issues highlights why this matters: NHI compromise often starts with weak secret handling or overbroad access, and the Ultimate Guide to NHIs shows why identity sprawl and unclear ownership keep the risk persistent.

• Issue credentials per task, not per agent lifetime.
• Bind policy to intent, data sensitivity, and execution context.
• Use ZSP and ZTA principles so access is continuously verified.
• Log tool calls, secret use, and cross-system chaining as security events.

This guidance breaks down in highly dynamic multi-agent pipelines where one agent delegates to another without a clear policy boundary, because the effective privilege path becomes hard to attribute in real time.

Common Variations and Edge Cases

Tighter runtime authorisation often increases integration overhead, requiring organisations to balance control strength against developer friction and system latency. There is no universal standard for this yet, especially for multi-agent orchestration, where one model may plan, another may execute, and a third may validate output. That is why current guidance is evolving rather than settled.

One common edge case is long-running workflows that need access across several steps. In those environments, short-lived secrets still help, but the access model must support renewal without turning into standing privilege. Another is retrieval-heavy agents that touch sensitive internal knowledge. They may not need broad API rights, but they do need strict provenance checks on what data can be read, cached, or summarised. The 52 NHI Breaches Analysis and the OWASP NHI Top 10 both reinforce that compromise often emerges from permission creep, secret sprawl, and weak containment rather than a single broken login.

In regulated environments, the safest design is usually policy-as-code with explicit approval paths for higher-risk actions, plus periodic review of tool permissions and secret TTLs. Where that is not possible, organisations should assume the agent can chain capabilities faster than human review can keep up.

Related resources from NHI Mgmt Group

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