Shadow AI is turning AI agents into unmanaged identities

At a glance

What this is: This is an analysis of shadow AI as an identity governance problem, with the key finding that AI tools and agents should be managed as non-human identities rather than blocked outright.

Why it matters: It matters because IAM, NHI, and human identity programmes all need the same visibility, access, and lifecycle discipline when AI is already embedded in daily work.

By the numbers:

• Up to 81% of the global workforce uses unapproved AI tools for their daily tasks.
• 88% of security leaders also admit to using these unapproved tools.
• Machine identities outnumber human accounts by at least 100 to 1 in North American enterprises.
• 44%.

👉 Read JumpCloud's analysis of shadow AI as an identity governance problem

Context

Shadow AI is the use of AI tools without IT or security approval, and the governance gap is that organisations still try to manage it as software choice instead of identity exposure. The primary keyword here is shadow AI, and the issue becomes an IAM problem as soon as those tools touch data, credentials, or systems.

JumpCloud's framing is that AI should be handled as a new kind of non-human identity with lifecycle, permissions, and decommissioning controls. That lens matters for NHI programmes because once an AI tool can act on data or systems, visibility and access control matter more than whether the tool was formally sanctioned.

The operational pattern is familiar to identity teams: users adopt tools first, then governance tries to catch up. The difference is scale and speed, because AI usage now spreads across employees and security leaders alike, which makes blanket blocking both brittle and incomplete.

Key questions

Q: How should security teams govern shadow AI without blocking productivity?

A: Security teams should treat shadow AI as an identity governance problem, not a simple app ban. Start by discovering where AI tools authenticate, then classify each path as approved, constrained, or unmanaged. The most practical model is to combine visibility, task-scoped permissions, and an approved-tool catalogue so users still have safe options.

Q: Why does shadow AI create NHI risk?

A: Shadow AI creates NHI risk because the tool often acts through credentials, tokens, or OAuth grants that function like machine identities. Once those credentials can access data or systems, the AI path becomes subject to the same lifecycle and least-privilege controls as other non-human identities. The issue is governance, not just usage.

Q: How do teams know if AI access is too broad?

A: AI access is too broad when a tool can read, write, and export data beyond the immediate task or when the credential remains valid after the use case changes. Teams should look for persistent tokens, shared access paths, and permissions that survive the original business need. Those are the signs of unmanaged standing access.

Q: What should organisations do first when employees are using unapproved AI tools?

A: The first step is to discover which tools are in use and which identities they rely on. Then classify the risk by data sensitivity, access scope, and whether the tool can be governed centrally. If a tool cannot be owned, reviewed, or decommissioned, it should be treated as shadow AI exposure until proven otherwise.

Technical breakdown

Shadow AI discovery and identity visibility

Shadow AI becomes a governance problem when usage is invisible to central teams. Discovery is not just about finding browser traffic or network signatures, it is about identifying which tools exchange data, which accounts authenticate, and which OAuth grants or tokens create persistent access. In NHI terms, the question is whether an AI tool is acting through a managed identity or an unmanaged credential path. Without that mapping, security teams see activity but cannot govern the identity behind it.

Practical implication: inventory AI touchpoints by authentication path first, then decide whether each one can be governed as an identity or must be blocked.

Least privilege for AI agents and NHI access

Treating AI as an identity means the access model must match the task, not the user who first enabled it. Least privilege for AI is narrower than standard application access because prompt-driven or script-driven activity can touch multiple datasets in a short time. If the access scope is broad, an AI tool can move from helper to data exfiltration path with very little friction. This is an NHI problem because the access is machine-executed, credential-backed, and often reusable across sessions.

Practical implication: bind AI access to task-scoped permissions and separate read, write, and export rights wherever possible.

Zero Trust for shadow AI

Zero Trust applies to AI because the system cannot rely on trust in the user, the endpoint, or the application label. Explicit verification, continuous monitoring, and assume-breach controls matter when AI tools may be used outside approved channels. The deeper governance issue is that identity assurance must travel with the AI interaction, not disappear once the tool is installed. That aligns shadow AI with broader NHI governance, where credentials and access paths are the control surface.

Practical implication: enforce continuous verification and monitoring on AI-related access paths instead of trusting the tool category or device location.

Threat narrative

Attacker objective: The objective is to capture sensitive data or reusable access through unmanaged AI usage and turn ordinary productivity work into an exfiltration or supply chain path.

1. Entry begins when employees or leaders use unapproved AI tools for routine work, often through browser-based interfaces, extensions, or ad hoc scripts that are not covered by central review.
2. Credential access occurs when those tools receive OAuth grants, pasted content, or other tokens that create persistent access paths outside sanctioned identity controls.
3. Impact follows when sensitive data, intellectual property, or regulated information leaves the organisation without governance, auditability, or offboarding control.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Shadow AI is no longer an application control issue, it is an identity governance issue. Once employees use AI tools to handle data, draft code, or automate work, the control question becomes who or what is acting on behalf of the business. That moves the problem from endpoint blocking into access scope, credential handling, and lifecycle oversight. Practitioners should treat every unmanaged AI path as an identity event, not a software exception.

Machine identities outnumbering human accounts by 100 to 1 changes the governance centre of gravity. When non-human accounts dominate the digital estate, the old assumption that human identity is the primary risk surface no longer holds. Shadow AI accelerates that shift by adding more machine-mediated access paths into daily workflows. The implication is that IAM programmes must stop treating AI usage as peripheral and start governing it as part of the core identity estate.

Least privilege is being applied to a class of actors that can change tasks faster than review cycles can react. AI tools are often enabled for a quick productivity use case, then left with broad access long after the original need passes. That creates a permissions drift pattern familiar in NHI sprawl, but with a faster adoption curve and weaker visibility. Practitioners should recognise that access granted for experimentation often becomes standing operational access.

Shadow AI exposes a new named concept: identity sprawl without ownership. The organisation may know that AI tools are in use, but not which account, token, or approver owns the path from prompt to data access. That breaks standard governance assumptions about accountability, recertification, and decommissioning. The practitioner implication is clear: if ownership cannot be assigned, the access is already outside policy control.

Blocking AI is a symptom response, not a governance model. The article's own trajectory shows that users and security leaders are already adopting these tools in large numbers, so blanket prohibition only pushes activity further underground. The more durable approach is to define approved identity paths, constrained permissions, and visible tool sets. Security leaders should design for containment and enablement, not denial alone.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• The visibility problem is broader than AI, which is why the Top 10 NHI Issues remains a useful next step for programme owners.

What this signals

Shadow AI is becoming the front door for unmanaged non-human access. As AI usage spreads through daily work, identity teams need to assume that some tool use will bypass formal approval and arrive first as credential exposure, data movement, or unmanaged OAuth consent. The practical response is to extend identity governance to AI touchpoints, not wait for a clean procurement signal.

Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs, and that visibility gap will only widen if AI tools are allowed to proliferate without ownership. The security team that cannot see its machine identities will not see its AI identities either. That makes discovery, attribution, and lifecycle controls a single programme problem rather than separate workstreams.

Identity sprawl without ownership is the right way to describe the next phase of shadow AI. If your programme can discover AI use but cannot tie it to an accountable owner, the control model is incomplete. Teams should align this work with Zero Trust verification and NHI governance rather than treat it as a temporary productivity exception.

For practitioners

• Map AI tools to identity paths Catalog where AI tools authenticate, which accounts or tokens they use, and whether those credentials are centrally managed. Prioritise OAuth grants, browser extensions, and script-based access because these often become the hidden control points.
• Separate approved and unmanaged AI use Create a clear distinction between sanctioned AI services and shadow AI usage, then tie each approved tool to an owner, a purpose, and a review cycle. If no owner exists, treat the access as unmanaged NHI exposure.
• Constrain AI permissions to task scope Grant only the minimum read, write, and export rights required for the specific use case. Avoid shared or long-lived credentials, and remove access when the task changes or ends.
• Build detection around AI-related data movement Monitor for unusual transfers, large prompt payloads, and authentication events tied to AI services. Detection should focus on whether sensitive information is leaving approved boundaries, not only on whether a banned app was used.

Key takeaways

• Shadow AI is an identity governance problem because unapproved AI tools can act through credentials, tokens, and access paths that behave like NHIs.
• JumpCloud's survey signals broad adoption and weak oversight, which means visibility and ownership now matter more than simple app blocking.
• Practical control starts with discovery, task-scoped permissions, and decommissioning discipline for every AI-related access path.

Key terms

• Shadow AI: Shadow AI is the use of AI tools without IT or security approval or visibility. In practice, it creates an identity problem because the tool may authenticate with credentials, tokens, or OAuth grants that allow access to data and systems outside normal governance.
• Non-Human Identity: A non-human identity is any machine-based actor that can authenticate and receive permissions, including service accounts, API keys, tokens, certificates, bots, and AI agents. For governance, the important point is that the identity has lifecycle, access, and revocation requirements even when no person is directly signing in.
• OAuth Grant: An OAuth grant is an authorisation path that allows an application or tool to access data on a user's behalf. In identity governance, grants matter because they can persist beyond the original task and become an unmanaged access path if they are not reviewed and revoked.
• Identity Sprawl: Identity sprawl is the uncontrolled growth of accounts, credentials, and access paths across an environment. In shadow AI programmes, it shows up when tools are adopted faster than ownership, review, and decommissioning processes can keep pace.

Deepen your knowledge

Shadow AI governance and NHI lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a policy for AI tools that already exist in the business, this is the right starting point.

This post draws on content published by JumpCloud: shadow AI, NHI governance, and the case for secure AI management. Read the original.