Shadow AI is turning AI agents into unmanaged identities

At a glance

What this is: This is a shadow AI governance analysis arguing that AI agents should be managed as non-human identities, not as ordinary apps.

Why it matters: It matters because IAM teams now have to govern AI usage, permissions, and lifecycle controls alongside human users and traditional machine identities.

By the numbers:

• Up to 81% of the global workforce uses unapproved AI tools for daily tasks, according to JumpCloud.
• 88% of security leaders also admit to using these unapproved tools, according to JumpCloud.
• North American enterprises were seeing machine identities outnumber human accounts by at least 100 to 1, according to JumpCloud.
• In some industries, machine identities outnumber human accounts by as high as 500 to 1, according to JumpCloud.

Context

Shadow AI is the use of AI tools without formal approval or oversight, and the article argues that this is now a governance problem rather than a novelty. For IAM and security teams, the central issue is that AI tools are being used like workers, yet they are often handled like unmanaged software.

The article’s core move is to recast AI agents as non-human identities. That matters because identity governance depends on visibility, access assignment, lifecycle control, and decommissioning, all of which break down when AI is adopted ad hoc by employees and security leaders alike.

Key questions

Q: What breaks when AI agents are managed like ordinary machine identities?

A: What breaks is the assumption that access scope can be fully understood from provisioning data and quarterly review. Ordinary machine identities are repeatable; agents are not. If teams only review entitlements, they miss context shifts, delegated actions, and credential creation inside the session.

Q: Why do unapproved AI tools create more risk than traditional software use?

A: Unapproved AI tools can process user input in ways traditional applications do not, including storing prompts, retaining outputs, or reusing data to improve services. That creates exposure when employees paste regulated or sensitive information into systems the organisation does not oversee. The risk is not only misuse, but also loss of visibility into where data goes next.

Q: What do security teams get wrong about shadow AI governance?

A: They often treat shadow AI as a banned-app problem when it is usually an identity and accountability problem. Employees can use approved tools, personal accounts, or embedded AI features in ways that bypass policy even when the app itself is not explicitly blocked. Governance has to follow the interaction, not just the endpoint.

Q: How should teams govern AI agents that act inside customer accounts?

A: Treat them as delegated non-human identities, not as ordinary customer sessions. Governance should require explicit consent, narrow authorization scope, token binding, and a complete audit record tying each action back to the human principal that approved it.

Technical breakdown

Why shadow AI becomes an identity problem

Shadow AI is not just unsanctioned software use. Once an AI tool authenticates, reaches data, and performs tasks on behalf of a user, it behaves like a non-human identity with access boundaries and operational side effects. The governance mistake is to treat the interface as the risk instead of the identity and permissions behind it. That is why standard software allow or deny thinking misses the control point. The real control surface is who or what can act, what it can reach, and when that authority ends.

Practical implication: inventory AI use as an identity problem, not only as a software inventory problem.

Lifecycle, permissions, and decommissioning for AI agents

The article frames AI agents as entities that need login, permissions, and decommissioning. That is the NHI lifecycle model applied to AI: create, govern, review, and retire access based on business need. Without lifecycle controls, AI access becomes durable by accident, especially when tools are adopted outside formal provisioning paths. This is where identity governance matters most, because access that is never explicitly granted is rarely explicitly removed. The failure mode is unmanaged persistence, not just initial unsanctioned use.

Practical implication: tie AI access to joiner-mover-leaver style lifecycle controls so every agent has an owner and an offboarding point.

Zero Trust controls for AI access

The article maps AI governance to Zero Trust principles: verify explicitly, grant least privilege, and assume breach. That is sensible because AI tools often touch data, APIs, and work systems from many entry points. Explicit verification addresses identity assurance, least privilege constrains what the agent can do, and continuous monitoring is the only practical response once the toolset is distributed across the business. In this model, the question is not whether AI is trusted in principle, but whether each access event is justified and observable.

Practical implication: apply explicit verification and least privilege to every AI agent session, then monitor activity continuously.

Threat narrative

Attacker objective: The objective is to obtain or expose sensitive organisational data through unmanaged AI-enabled access paths.

1. Entry begins when employees adopt unapproved AI tools for daily work without IT oversight, creating unmanaged access paths into business data and workflows.
2. Credential compromise and data exposure follow when users paste sensitive information into public AI tools or connect those tools through authentication tokens.
3. Impact emerges as sensitive data, intellectual property, compliance posture, and operational consistency are all weakened by uncontrolled AI use.

Breaches seen in the wild

• Meta AI Instagram Account Takeover: 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is an identity governance problem before it is a software governance problem. The article is right to move AI tools out of the app-blocking frame and into the access-management frame. Once an AI tool is used to act on data or workflows, the relevant control question becomes who or what is authorised, by whom, and for how long. Practitioners should treat AI usage as an identity boundary, not just an application choice.

AI agents inherit the governance burden of non-human identities. If a chatbot or automation script can access systems, the organisation needs an owner, permissions, review cadence, and offboarding path. That is the same lifecycle logic used for service accounts, except the adoption path is now bottom-up rather than centrally provisioned. Teams that do not align AI use to identity lifecycle processes will accumulate shadow access faster than they can discover it.

Zero Trust becomes more relevant when AI is pervasive, not less. The article’s verify, least privilege, assume breach framing is directionally correct because AI usage expands the number of actors touching sensitive systems. Identity blast radius: ungoverned AI widens the scope of each user decision by turning a single prompt or token into downstream access. The practitioner task is to shrink the blast radius by making identity, not convenience, the default control boundary.

Machine identity scale changes the economics of governance. The article’s point that machine identities already dwarf human accounts means manual review models are structurally outmatched. This is not only about more identities, but about more ephemeral, user-driven, and context-shifting access requests. Organisations need governance models that assume identity sprawl is the baseline and that visibility must come before policy confidence.

Discovery, governance, and enablement is the right operating model for shadow AI. Blocking tools only hides demand and pushes usage further underground. A governance-first model works because it gives security teams a way to surface actual use, assign policy, and channel employees toward approved tools. Practitioners should treat that sequence as an access governance programme, not a one-time cleanup exercise.

What this signals

Shadow AI governance now sits at the intersection of human behavior and non-human access. Employees will keep reaching for AI tools that help them work faster, so the programme response has to focus on controlled adoption rather than prohibition. For practitioners, the signal is clear: policy without discovery will lag actual use, and actual use is already embedded in daily workflows.

Identity-led AI governance should be built around ownership and task-scoped access. The useful mental model is the same one used for NHI lifecycle management, but applied to employee-adopted AI agents. When an AI tool can touch sensitive systems, the organisation needs to know who approved it, what it can do, and how it will be removed when no longer needed.

Discovery is the prerequisite for any credible shadow AI programme. Without visibility into tokens, browser activity, and connected services, security teams cannot enforce least privilege or monitor for misuse. The practical implication is that AI governance must be measured by coverage and control assignment, not by how many tools are banned.

For practitioners

• Discover shadow AI access paths Scan browser extensions, network traffic, and authentication tokens linked to AI services so you can inventory where AI is being used without approval.
• Assign ownership to each AI agent Require a business owner, defined permissions, and a decommissioning path for every approved AI tool or agent so the identity has a clear lifecycle.
• Enforce explicit verification before AI access Treat each AI agent as a non-human identity that must authenticate before reaching data or systems, with access scoped to a specific task.
• Apply least privilege to AI-enabled workflows Limit AI tools to the minimum data sources and actions needed for their function, and separate high-risk data from general productivity tooling.
• Create an approved AI toolkit Replace blanket bans with a curated list of vetted tools for coding, writing, and analysis so employees have safer options than shadow use.

Key takeaways

• Shadow AI becomes an identity issue the moment an AI tool can access data or execute work on behalf of a person.
• The article’s numbers show that unapproved AI use is already widespread across both the workforce and security leadership.
• Security teams should shift from blocking AI to discovering it, assigning owners, and governing access through lifecycle controls.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• AI Toolkit: An AI toolkit is a curated set of approved AI tools that employees can use for common work tasks. It is not a security control by itself, but it reduces shadow adoption by giving people sanctioned options that can be governed through identity and access policies.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.