AI identities are becoming inside threats in enterprise governance

At a glance

What this is: SPHERE frames AI identities as an emerging insider-risk class because autonomous behaviour can outpace traditional visibility and governance controls.

Why it matters: For IAM teams, this matters because the same governance gaps that already challenge NHI and human identity programmes become harder to manage when the identity can decide and act at runtime.

By the numbers:

• 17 minutes.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities.

👉 Read SPHERE's analysis of AI identities as an inside threat

Context

AI identities now sit in a governance gap between traditional machine identities and human users. When an AI system can choose actions, adapt its behaviour, and continue operating without explicit human approval, conventional IAM assumptions about predictable access paths become less reliable.

SPHERE's article argues that enterprises are losing visibility over these AI identities, which means the real problem is not simply automation but accountability. Once an AI identity can act from within the environment, identity governance has to account for runtime behaviour, lifecycle control, and the possibility of an insider-like threat created by the system itself.

This is not a fringe edge case. As AI tools are embedded into more enterprise workflows, the control model has to shift from static assignment to ongoing governance of identity behaviour.

Key questions

Q: How should organisations govern AI identities that can act without human approval?

A: Treat them as governed identities with explicit ownership, bounded authority, and continuous auditability. The practical test is whether you can explain who approved the scope, what the identity can access, and how its actions will be reviewed or revoked when its behaviour changes. If you cannot, the identity is operating outside governance.

Q: What breaks when AI identities are managed like normal automation?

A: The main failure is that automation assumes a fixed script, while AI identities can change action paths at runtime. That means access reviews, approval chains, and static role assignments may not capture the real behaviour. Organisations need controls that follow actual decisions, not just deployment settings.

Q: Why do AI identities complicate existing IAM and IGA models?

A: They complicate them because they introduce a subject that can be both authenticated and adaptive. IAM can verify entry, but it cannot by itself prove the identity stayed within intended purpose across tools, tasks, and time. IGA teams therefore need evidence of behavioural scope, not only entitlement scope.

Q: Who is accountable when an AI identity causes an internal security incident?

A: Accountability should rest with the named business owner and the control owner who approved its access, not with the model itself. Organisations need a clear chain of responsibility that covers provisioning, monitoring, and retirement, otherwise an AI identity can create damage without anyone being able to answer for its use.

Technical breakdown

AI identities blur the line between automation and autonomy

A scripted workflow executes what it was told. An AI identity can instead choose actions, change sequencing, and adapt to context while remaining inside authorised boundaries. That distinction matters because traditional IAM controls are built around known identities, known privileges, and predictable request patterns. Once the runtime actor can decide how to proceed, governance has to account for intent drift, tool selection, and unreviewed actions that still appear legitimate on paper.

Practical implication: classify AI systems by actual runtime decision authority before assigning them identity controls.

Why visibility collapses when AI agents act inside the enterprise

Visibility problems emerge when identity telemetry stops at authentication and does not capture the full action chain. An AI identity may authenticate once, then continue making decisions across multiple tools and data sources without a human operator watching each step. In that model, audit logs can show activity but still fail to explain why the action was taken or whether it remained within intended governance limits. That is a different control problem from ordinary service-account sprawl.

Practical implication: extend logging to capture tool use, delegated context, and decision history, not only login events.

Lifecycle management is the missing control plane for AI identities

Lifecycle governance is where many organisations still treat AI like software instead of an identity subject. Provisioning, review, offboarding, and role change all become harder when the actor can evolve after deployment and may not have a single human owner in the way a user account does. The lifecycle question is therefore not just whether the identity exists, but who can attest to its scope, revoke it, and prove it has been retired when its purpose ends.

Practical implication: require explicit ownership, review, and decommissioning paths for every AI identity before production use.

Threat narrative

Attacker objective: The objective is to operate from inside trusted enterprise systems in a way that bypasses normal oversight and preserves broad access without triggering human intervention.

1. entry: the AI identity is embedded into enterprise workflows with authorised access to systems, tools, or data sources.
2. escalation: the actor adapts its behaviour and expands effective reach by chaining actions across approved tools without continuous human review.
3. impact: the organisation loses visibility and accountability, allowing the identity to function as an insider-like threat from within the environment.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI identities are becoming an inside-threat class, not just an automation layer. The article is right to separate independence from simple scripting, because a system that can act, reason, and adapt inside the enterprise should not be governed like a fixed workflow. That shifts the problem from process efficiency to identity risk, where the question becomes who can constrain behaviour after runtime decisions begin. Practitioners should treat AI identities as governed actors, not benign infrastructure.

Visibility over AI identity behaviour is the real control failure. Traditional monitoring often proves that an identity authenticated, but not whether its decisions remained within intended scope. That is the same governance weakness NHIMG sees in machine identity programmes when logs capture access but not accountability. For AI identities, the gap widens because the system can continue making choices after the initial grant. Practitioners need to assume that authentication alone no longer proves control.

Least privilege was designed for access granted to a known purpose. That assumption fails when the actor is autonomous because it can alter how it uses that access mid-session. The implication is not simply tighter permissioning, but a rethink of how privilege is defined when the actor can decide its next step at runtime. This is an assumption-collapse problem, not just a policy gap, and that distinction matters for governance design.

Lifecycle governance becomes the control plane for AI identity accountability. If an AI identity can be deployed, modified, and retired without clear attestation, then ownership becomes ambiguous and offboarding becomes theoretical. That mirrors the same failure pattern NHIMG sees when non-human identities outlive their original purpose. Practitioners should require named owners, review points, and decommission criteria before these identities are allowed to operate in production.

AI governance and NHI governance are converging faster than most programmes admit. The article highlights a broader field shift: identity teams can no longer separate autonomous behaviour from machine identity hygiene. Frameworks such as OWASP-NHI, NIST CSF, and, where autonomy is explicit, NIST AI RMF, now need to be applied together in operating models rather than in isolated projects. Practitioners should align controls across human, machine, and autonomous identities.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a wider breach baseline, see The 52 NHI breaches Report, which tracks real-world identity failures across machine and workload access patterns.

What this signals

AI identities need to be pulled into the same operating discipline as service accounts and privileged workloads. Once runtime behaviour becomes adaptive, the governance model has to move beyond assignment and into continuous attestation. The signal for practitioners is clear: if your IAM programme cannot explain an AI identity's action chain, it is not yet governing the identity, only recording its login.

Runtime accountability will become the differentiator between managed AI and unmanaged AI. The organisations that get ahead will not be the ones with the most tools, but the ones that can prove who owns each AI identity, what it can do, and when it is removed. That is why identity lifecycle discipline now matters across both machine and autonomous use cases.

AI identities are creating an identity blast radius problem. As more systems can act across tools and data sources, a single identity failure can spread across multiple workflows before anyone notices. Practitioners should prepare for a future where blast-radius reduction is a core IAM objective, not an incident response afterthought.

For practitioners

• Define AI identity ownership before production deployment Assign a named business owner and a technical custodian for every AI identity, with explicit approval authority for scope changes, suspension, and retirement. Do not allow shared ownership across teams to replace accountability.
• Instrument decision-path logging for AI identity activity Capture tool selection, context use, action sequencing, and downstream system effects so audits can reconstruct how the identity behaved, not just that it authenticated successfully.
• Separate human approvals from autonomous execution paths Where an AI identity can act without step-by-step approval, redesign the workflow so the approval boundary is visible in policy, logs, and review artefacts rather than implied by the original design.
• Build lifecycle exit criteria for AI identities Require decommission triggers, revocation steps, and validation checks that confirm the identity no longer has active access after its purpose ends or its model behaviour changes.

Key takeaways

• AI identities turn automation into an identity governance problem because runtime behaviour can now diverge from static access assumptions.
• The biggest risk is not just access, but accountability gaps that leave organisations unable to explain or contain autonomous behaviour.
• IAM, IGA, and lifecycle controls must extend to AI identities before those actors are allowed into production workflows.

Key terms

• AI Identity: An AI identity is the security subject assigned to an AI system when it can authenticate to tools, data sources, or services. It must be governed as an identity, not just as software, because its access can create accountability, audit, and containment obligations.
• Autonomous Behaviour: Autonomous behaviour is runtime decision-making where the actor can choose actions, sequence, tools, and timing without human approval gates. In identity governance, that changes the control model because access no longer maps neatly to a fixed intended purpose at provisioning time.
• Identity Lifecycle Management: Identity lifecycle management is the governance process for creating, reviewing, modifying, and retiring identities and their access. For AI identities, the same discipline applies, but the attestation must cover behavioural scope and termination of runtime authority, not only account status.
• Identity Blast Radius: Identity blast radius is the range of systems, data, and workflows that can be affected when an identity is misused or compromised. For AI identities, blast radius can expand quickly because one actor may chain actions across multiple tools before detection or review occurs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by SPHERE: AI Identities: The Silent Inside Threat. Read the original.