TL;DR: Shadow AI is now a workforce-scale identity problem, with 81% of the global workforce using an unapproved AI tool for work tasks, according to JumpCloud. The security issue is not just unsanctioned usage but data being ingested into model training, which makes traditional block-and-delete controls insufficient.
NHIMG editorial — based on content published by JumpCloud: Shadow AI governance and the Discover, Govern, Enable framework
By the numbers:
- 81% of the global workforce has used an unapproved AI tool to complete a work task.
Questions worth separating out
Q: How should security teams handle shadow AI without blocking all AI use?
A: Security teams should govern shadow AI as an access and data problem, not just a policy violation.
Q: Why does shadow AI create more risk than classic shadow IT?
A: Shadow AI creates more risk because the data may not simply sit in an unauthorised app.
Q: How do you know if AI tool governance is actually working?
A: Governance is working when you can see which AI tools, browser extensions, and OAuth consents have access to corporate data, and when those permissions are limited to a business need.
Practitioner guidance
- Inventory AI-connected access paths Map browser extensions, OAuth consents, and federated app connections that can reach corporate data.
- Classify AI tools by data ingestion risk Separate approved tools that process only low-risk content from public or consumer AI services that may retain prompts, files, or transcripts.
- Add AI-related grants to access reviews Include AI services, browser extensions, and third-party app permissions in recurring access reviews.
What's in the full article
JumpCloud's full article covers the operational detail this post intentionally leaves for the source:
- Browser extension audit guidance for finding hidden AI tools across the fleet
- Practical steps for scanning OAuth tokens and third-party app access in Google and Microsoft environments
- A structured Discover, Govern, Enable framework for policy and rollout
- Examples of vetted enterprise AI alternatives to reduce shadow tool usage
👉 Read JumpCloud's analysis of shadow AI governance and AI tool discovery →
Shadow AI governance: what IAM teams need to fix now?
Explore further
Shadow AI is now an NHI governance problem, not just an acceptable-use problem. The article’s central shift is from employee misuse to identity exposure, because AI tools that receive corporate data, prompts, and OAuth grants behave like non-human access paths. That means the control question is no longer only whether a user was authorised to use a tool, but whether the tool itself has been governed as an identity with scoped access and revocation discipline. Practitioners should treat unsanctioned AI as an access layer that expands the attack surface.
A few things that frame the scale:
- When AI-connected services are granted access too freely, the blast radius grows fast. In a separate NHI threat study, attackers attempt access within an average of 17 minutes after AWS credentials are exposed publicly, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
A question worth separating out:
Q: What should organisations do when employees use public LLMs for work tasks?
A: Organisations should treat public LLM use as a data-handling event and classify the content before submission. Sensitive code, transcripts, and customer information should be blocked from unmanaged tools, while sanctioned alternatives should be provided for lower-risk tasks. The aim is to reduce unsafe submission, not merely punish the user after the fact.
👉 Read our full editorial: Shadow AI is exposing NHI governance gaps in enterprise IAM