By NHI Mgmt Group Editorial TeamBased on JumpCloud: “Shadow AI Is the New Shadow IT: What CIOs Must Do Now” (February 23, 2026)

TL;DR: Shadow AI is spreading as employees use unsanctioned AI tools and paste sensitive data into them, with 61% of organisations reporting unmonitored AI use and 60% of IT professionals saying AI is outpacing their protection, according to JumpCloud. The security problem is not just tool sprawl but the collapse of identity, policy, and data-handling control at the point of use.


At a glance

What this is: Shadow AI is the unsanctioned use of AI tools by employees, and the article argues that it exposes weak IAM visibility, policy enforcement, and data-handling controls.

Why it matters: IAM teams need to treat shadow AI as an identity and governance problem, because unapproved AI use can bypass access controls, leak data, and undermine compliance even when traditional tool approvals exist.

By the numbers:

  • 61% of organisations report encountering unsanctioned or unmonitored use of AI tools.
  • 60% of IT professionals agree that AI is outpacing their organisation’s ability to protect against threats.

Context

Shadow AI is the unsanctioned use of AI tools that bypasses IT approval, and it becomes an identity security problem when employees use corporate credentials, unmanaged browsers, or personal accounts to move sensitive data into services the organisation cannot govern. In practice, the risk is not just that a tool is unknown, but that data leaves controlled workflows without any reliable policy, logging, or access boundary.

JumpCloud’s article frames the issue as a growing gap between AI adoption and IAM visibility. That gap matters because identity controls are only effective when the organisation can see which users are reaching which tools, under what policies, and with what data handling rules. When that visibility breaks, governance becomes advisory rather than enforceable.

The article’s starting position is typical for today’s enterprise environment, not an edge case: employees are already experimenting with AI to work faster, and security programmes are still catching up to the operational and data-flow implications of that behaviour.


Key questions

Q: How should security teams govern shadow AI without slowing adoption?

A: Start with continuous discovery, then classify tools by data access, system connectivity, and provider trust. Use policy thresholds that allow low-risk use cases quickly while forcing review, restriction, or blocking for tools that can reach sensitive systems. The control objective is to make safe adoption fast and unsafe adoption expensive.

Q: Why does shadow AI create risk even when employees are trying to be productive?

A: Because the risk is not intent, it is uncontrolled data movement. A user who pastes sensitive material into an unsanctioned AI service can expose information outside enterprise policy, retention, and compliance boundaries even if the work request was legitimate.

Q: What are the signs that an AI system is being used outside the controls expected by the EU AI Act?

A: Warning signs include poor data quality, limited explanation of model decisions, weak records of system activity, and missing human review for decisions that affect individuals. If teams cannot explain how the model was trained, what data it uses, or who approved its use, the system is likely operating outside the governance boundary the Act expects.

Q: When should teams prioritise governance and process discipline over adding more AI tooling?

A: Teams should prioritise governance and process discipline when AI initiatives are spreading faster than oversight can keep up. The article reflects the 10 20 70 view, where sustainable AI success depends more on processes, talent, change management, and governance than on model quality alone. Without that foundation, additional tooling often increases complexity instead of delivering reliable, scalable outcomes.


Technical breakdown

Why shadow AI becomes an IAM visibility problem

Shadow AI is not just unsanctioned software use. It is a control-plane problem where identity, access, and data handling are no longer tied to a governed application inventory. If a user can sign up for a public AI service with corporate credentials, paste company data, and continue working outside approved channels, IAM loses both enforcement and evidence. The organisation may still authenticate the user, but it cannot reliably govern the destination, the prompts, or the downstream retention of data. That creates a visibility gap that traditional application allowlists do not close.

Practical implication: treat unmanaged AI access as an identity visibility failure, not only a software approval issue.

How data leaves the controlled perimeter through AI prompts

The article highlights a simple but damaging pattern: an employee copies customer records, code, or financial information into a public AI tool to get work done faster. Once that happens, the data is no longer confined to enterprise controls. Depending on the service and settings, the input may be retained, reused, or exposed through model behaviour or account compromise. The security issue is therefore not only the tool itself but the handling path that moves regulated or proprietary data into a system the organisation does not administer.

Practical implication: classify prompt content as a data-handling control point and restrict sensitive inputs before they reach external AI services.

Why centralised identity control matters more than tool approval lists

The article argues that visibility improves when access decisions are centralised and tied to verified identities. That is the right direction, because a simple approved-tools list does not tell you who used what, from where, or with which account. Centralised IAM can block sign-ups, flag unsanctioned logins, and create a control point for policy enforcement across human users and non-human identities. In an AI-heavy environment, the practical question is not whether a tool exists, but whether the organisation can tie use back to a governed identity and approved context.

Practical implication: unify identity enforcement across humans and non-human identities so AI access is policy-driven and observable.


Threat narrative

Attacker objective: The objective is not always a direct attacker action, but the end state is the same: uncontrolled disclosure of sensitive enterprise data outside governed identity and data boundaries.

  1. Entry occurs when an employee uses an unsanctioned AI tool to speed up routine work and enters it through a corporate or unmanaged identity path.
  2. Credential and data exposure follow when sensitive customer data, proprietary code, or financial information is pasted into the external service.
  3. Impact arises when the organisation loses control over where the data went, how it was retained, and whether compliance or confidentiality obligations were breached.

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 IAM visibility failure before it is an AI adoption issue. The organisation may still authenticate users correctly, but it cannot govern the destination once employees shift work into unsanctioned AI services. That means the real break occurs between identity assurance and application visibility, where approved access no longer predicts actual data movement. Practitioners should read this as a governance gap in the access layer, not a tooling gap in isolation.

Shadow AI creates a data-handling control failure at the point of use. When employees paste sensitive information into external AI tools, the policy problem is not abstract risk appetite but unbounded data transfer. Data privacy, IP protection, and regulatory compliance all depend on knowing which content is allowed to leave controlled systems. The article shows that AI use collapses that boundary if prompts are not governed explicitly, so teams must treat prompt input as an enforceable control surface.

Unified identity governance becomes the minimum viable control pattern for AI-era access. The article’s emphasis on centralised IAM is directionally correct because identity, device, and application controls have to produce one view of who can use which AI service and with what data. Separate control silos cannot keep up with this behaviour. Practitioners should expect AI to force governance closer to the issuance and usage layer rather than relying on after-the-fact review.

Shadow AI is accelerating the shift from approved access to governed use cases. That is a meaningful change for IAM, because access approval alone does not answer whether the activity itself is acceptable. Organisations will need more explicit policy boundaries around sanctioned AI, sensitive prompts, and identity-backed enforcement. The implication for practitioners is that access control now has to be paired with data-use governance, or it will remain structurally incomplete.

Shadow AI and IAM visibility gaps create an identity blast radius problem. Once an employee can move from a trusted identity to an ungoverned AI endpoint, the organisation loses the ability to predict where sensitive data may surface next. That expands the blast radius beyond the original user account into compliance, IP, and operational risk. Teams should treat that expansion as a core governance signal, not a side effect.

From our research library:

What this signals

Shadow AI is turning identity governance into a usage-governance problem. The next phase of IAM will be judged less by whether users can authenticate and more by whether organisations can govern what they do after authentication, especially in AI-enabled workflows. Teams that still treat approval lists as sufficient will keep missing where data actually leaves control.

Centralised identity control is necessary but not sufficient. The operational gap is now between who is allowed to act and what data they are allowed to expose to external systems. Practitioners should expect policy, browser control, and AI service governance to converge around the same enforcement layer.

Shadow AI expands the governance surface without creating new user roles. That makes detection harder, because the behaviour often looks like normal work until sensitive content crosses into an unsanctioned service. Security teams should prepare to govern the activity itself, not only the account that initiated it.


For practitioners

  • Map sanctioned and unsanctioned AI use Build an inventory of AI services being used by employees, including browser-based tools, consumer accounts, and embedded AI features in other apps. Correlate that inventory with identity sources so you can see which users are reaching which services.
  • Enforce prompt data restrictions Define which data types can never be entered into external AI tools, especially PII, financial records, customer data, and proprietary code. Push those rules into policy, browser controls, and user training so the restriction is not only written down.
  • Centralise identity enforcement for AI access Tie AI access decisions to verified identities, approved accounts, and consistent logging across human users and non-human identities. Use that control plane to block unapproved sign-ups and to flag access outside approved business use.
  • Create a sanctioned AI use policy Write clear rules for which AI tools are approved, what review is required before new tools are adopted, and who owns exceptions. Make the policy operational by linking it to enforcement points instead of leaving it as guidance alone.
  • Train teams on safe AI use Explain to users why copy-pasting sensitive data into public AI tools creates privacy, compliance, and confidentiality exposure. Pair the training with approved alternatives so the safer path is also the easier path.

Key takeaways

  • Shadow AI is not just unsanctioned software use. It is a governance failure that lets sensitive data move outside approved identity and access boundaries.
  • The article points to a familiar enterprise pattern, with most organisations already seeing unmonitored AI use and IT teams struggling to keep pace with adoption.
  • The most effective response is to unify IAM visibility, formalise AI use policy, and enforce data-handling rules at the point where employees interact with AI tools.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-10 — Human Use of NHIShadow AI often starts with employees using unsanctioned AI services through corporate identities.
Recommendation — Treat AI access by employees as governed usage and enforce approved-service boundaries.
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article centers on who can reach which AI services and under what policy.
Recommendation — Align AI access to PR.AA-05 so entitlements match approved identities and use cases.
CIS Controls v8CIS-5 — Account ManagementCentralised account governance is the article’s main control theme for AI visibility.
Recommendation — Use CIS-5 to inventory accounts and remove pathways to unsanctioned AI services.
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementThe article’s identity control discussion depends on managing credentials and access paths.
Recommendation — Apply IA-5 to control authenticator use and prevent unmanaged AI sign-ins with corporate identities.
OWASP API Security Top 10API10 — Unsafe Consumption of APIsUnsanctioned AI tools expose organisations to unsafe downstream consumption of external services.
Recommendation — Review external AI integrations for unsafe consumption paths before allowing production use.

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.
  • Identity Visibility: Identity visibility is the ability to see which identities exist, what they can access, and how those access paths relate across systems. In NHI programmes, it means correlating service accounts, tokens, certificates, and agents into one operational view so governance decisions are based on evidence, not assumptions.
  • Data Handling Control: Data handling control is the set of rules and technical enforcement points that determine what information may be entered into, stored by, or transmitted through a system. In shadow AI scenarios, it is the boundary that should stop sensitive content from leaving governed workflows.
  • Sanctioned AI: Sanctioned AI is an AI system that has gone through procurement, legal, and security review and is governed by defined controls. The term matters because approved status should reflect real access scoping, ownership, and data handling rules, not just a business decision to use the tool.

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 NHI governance in your organisation, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org