What breaks when AI identities are handled outside IAM?

When AI identities sit outside IAM, organisations lose a consistent record of who has access, why access exists, and who approved it. That creates policy drift, weak accountability, and incomplete audit evidence. The programme may still function operationally, but it will not provide dependable governance or defensible compliance evidence.

Why This Matters for Security Teams

When AI identities are managed outside IAM, the organisation loses the control plane that records entitlement, approval, and revocation. That is not just an audit issue. It also means AI agents, scripts, and other NHIs can accumulate access without a reliable owner or purpose, which undermines least privilege and makes incident response slower. NIST Cybersecurity Framework 2.0 treats access governance as part of a broader, measurable risk programme, not an optional admin task, and current guidance for non-human access management points in the same direction. The gap becomes sharper once AI workloads can call tools, chain actions, and act with persistence.

Research from The 2024 Non-Human Identity Security Report shows that 88.5% of organisations say their non-human IAM lags human IAM or is merely on par with it, which helps explain why AI access so often becomes fragmented across platforms. That fragmentation is exactly what defenders see in cases like the DeepSeek breach and the JetBrains GitHub plugin token exposure, where secrets and tokens became security liabilities rather than managed assets. In practice, many security teams encounter the ownership gap only after access sprawl has already become an incident response problem, rather than through intentional design.

How It Works in Practice

The practical failure mode is simple: if AI identity is outside IAM, there is no single source of truth for who or what the workload is, what it may do, and when that access should end. For autonomous systems, static RBAC alone is too blunt. An agent does not behave like a person with a stable job function; it may read a ticket, query a database, call an API, then pivot to another tool based on live output. That is why intent-based authorisation is gaining attention. At request time, the decision should consider the agent’s goal, the task context, the data sensitivity, and the policy boundary, rather than only a preassigned role.

In stronger implementations, the agent presents a workload identity, such as an OIDC-based assertion or SPIFFE/SPIRE identity, and receives just-in-time credentials only for the task at hand. Secrets should be short-lived, scoped narrowly, and revoked automatically after completion. That reduces the blast radius if the agent is hijacked or overperforms its remit. The operational pattern also aligns with guidance in NIST Cybersecurity Framework 2.0 and with the direction of least privilege expressed in Azure Key Vault privilege escalation exposure, where overbroad access and weak secret boundaries create unnecessary risk.

• Use IAM as the approval and audit layer for AI identities, not as a passive directory entry.
• Prefer dynamic, ephemeral credentials over long-lived static secrets wherever automation allows it.
• Evaluate policy at request time with full context, especially for tool use, data access, and write actions.
• Bind each agent to a named owner, task scope, and revocation path before production use.

These controls tend to break down in multi-cloud environments with legacy secret stores and no runtime policy engine because identity, approval, and enforcement are split across systems.

Common Variations and Edge Cases

Tighter control over AI identities often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff is real, especially for teams running high-volume agents, integration bots, or experimentation sandboxes. Current guidance suggests that not every workload needs the same level of friction, but there is no universal standard for this yet. The practical answer is to tier identities by risk and privilege: a read-only summariser should not be managed like a code-deploying agent, and neither should be treated like a human administrator.

One edge case is vendor-hosted or embedded AI, where the organisation may not control the runtime identity layer. In those environments, the best available approach is compensating control: isolate the tool, constrain data pathways, require short-lived tokens, and log every privileged action. Another edge case is multi-agent orchestration, where one agent delegates to others. That creates chained trust relationships that traditional IAM rarely models well. The result is that approvals may exist, but the effective access path is still opaque. Security teams should treat this as a governance design issue, not just a tooling gap, and apply principles from NIST Cybersecurity Framework 2.0 alongside emerging agent controls discussed in DeepSeek breach analysis.

Best practice is evolving, but the direction is consistent: AI identities need the same governance discipline as any other privileged workload, with stronger emphasis on runtime context, short-lived access, and clear accountability.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• Why do non-human identities create more audit risk than human accounts?
• How should security teams govern non-human identities in Salesforce?