Notifications
Clear all
Topic starter
10/06/2026 12:24 am
TL;DR: Unapproved AI use is already widespread, with up to 81% of the global workforce and 88% of security leaders using shadow AI tools, according to JumpCloud. The real problem is not AI adoption itself, but treating AI as software instead of as a governed identity with explicit access, lifecycle, and monitoring controls, while machine identities now outnumber human accounts by at least 100 to 1 in North American enterprises.
NHIMG editorial — based on content published by JumpCloud: shadow AI, NHI governance, and the case for secure AI management
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map AI tools to identity paths Catalog where AI tools authenticate, which accounts or tokens they use, and whether those credentials are centrally managed.
- 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.
- Constrain AI permissions to task scope Grant only the minimum read, write, and export rights required for the specific use case.
What's in the full article
JumpCloud's full blog covers the operational detail this post intentionally leaves for the source:
- A practical discover, govern, enable framework for turning shadow AI into a managed programme.
- Specific examples of AI tool discovery signals, including browser extensions, network traffic, and OAuth-linked services.
- How to position AI tools as non-human identities inside an existing identity management system.
- A curated AI toolkit model for replacing banned-app lists with approved options.
👉 Read JumpCloud's analysis of shadow AI as an identity governance problem →
Shadow AI governance is the identity gap teams are missing?
Explore further
11/06/2026 2:08 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow AI is turning AI agents into unmanaged identities
12/06/2026 3:43 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Shadow AI is turning AI agents into unmanaged identities
