Shadow AI is exposing NHI governance gaps in enterprise IAM

At a glance

What this is: Shadow AI is being framed as a governance problem in which unsanctioned AI use turns data handling into a non-human identity control issue.

Why it matters: It matters because IAM, IGA, and PAM teams need to govern AI tools, browser extensions, and OAuth grants as access pathways across human, NHI, and emerging autonomous workflows.

By the numbers:

• 81% of the global workforce has used an unapproved AI tool to complete a work task.

👉 Read JumpCloud's analysis of shadow AI governance and AI tool discovery

Context

Shadow AI is the use of unapproved AI tools by employees, and the governance gap starts when those tools are allowed to ingest corporate data without review. In this case, the primary identity question is not just who is signed in, but which AI-connected services have been granted access to content, prompts, and browser context.

The article argues that AI use is shifting from shadow IT to shadow data training, which changes the control problem for IAM teams. The relevant programme boundaries now include OAuth grants, browser extensions, and sanctioned AI tool lists, because unmanaged AI use can behave like an unmanaged NHI even when a human initiated the request.

Key questions

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. Start by discovering browser extensions, OAuth grants, and third-party AI tools that can reach corporate content, then approve only the tools that can be constrained by data class, identity, and logging. Users need a safe path, or they will choose unmanaged tools anyway.

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. It can be retained, reused, or absorbed into model behaviour, which makes later deletion uncertain and sometimes impossible. That turns a one-time policy breach into a longer-lived exposure that affects confidentiality and downstream inference.

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. If users still need consumer tools to complete routine work, the approved path is not replacing the shadow path.

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.

Technical breakdown

Shadow AI turns data submission into model training exposure

When users paste proprietary material into a public LLM, the immediate action is not the end of the risk. In many AI services, submitted prompts, files, or conversation context can be retained, processed, or used to improve models, which means the data may leave the organisation’s practical control plane. That differs from classic shadow IT, where the data usually stayed in a separate app and could be deleted after discovery. The real issue is control over downstream use, not just storage location. For IAM teams, that makes application approval, data classification, and access scope part of the same governance decision.

Practical implication: treat AI tools as data-processing identities and review what they can ingest before they can be trusted with sensitive content.

OAuth grants and browser extensions are the hidden access layer

Shadow AI often lives inside browsers, extensions, and federated app connections rather than in a single sanctioned enterprise app. OAuth tokens can give third-party tools broad access to Google or Microsoft data without the user thinking of it as an access grant, and browser extensions can silently read page content, sessions, and forms. That creates an identity path that looks lightweight to the employee but behaves like persistent third-party access from a governance perspective. The problem is not only the tool itself, but the standing authorisation behind it. That is an NHI-style access issue, even when the initiating actor is human.

Practical implication: inventory OAuth consents and browser extensions alongside service accounts because both can create durable, under-governed access paths.

The unlearning problem makes AI data misuse harder to unwind

Once information has been absorbed into a model’s training data or behavioural memory, the organisation cannot assume it can be removed on demand. This is the unlearning problem: the inability to reliably reverse the effect of sensitive data already used for model improvement without rebuilding or retraining the model. That makes the control objective different from ordinary data leakage. In shadow AI cases, the danger is not only disclosure, but persistence of inference value after the user believes the task is complete. Governance must therefore focus on preventing sensitive submission, not relying on later cleanup.

Practical implication: stop treating post-use deletion as a sufficient control and instead restrict what data can reach unsanctioned AI tools in the first place.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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 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.

Unauthorised data training is the named failure mode shadow IT never had. Shadow IT exposed data to a rogue application, but shadow AI can feed that data into model training or model memory, where the organisation cannot assume retrieval or erasure. That permanence changes the governance burden for data classification, consent, and retention, because the leak can survive the original session. Practitioners should reframe AI approval around downstream data reuse, not just app trust.

Browser-based AI use creates identity sprawl through human-initiated NHI behaviour. Employees may trigger the activity, but the durable risk sits in the access token, extension permission, or federated grant that outlives the session. This is where human IAM and NHI governance meet: the human decision creates the NHI footprint. Practitioners should unify app approvals, OAuth review, and identity inventory instead of managing them as separate queues.

Discover, Govern, Enable is a useful operating model only if discovery includes the full access chain. Discovery must extend beyond sanctioned SaaS to browser extensions, OAuth consents, and third-party AI services that can read enterprise content. Governance then becomes a scoped access decision, and enablement becomes the safe alternative path users will actually adopt. Practitioners should measure shadow AI by access pathways, not by the number of approved logos on a policy page.

Shadow AI is accelerating the need for lifecycle governance across human and non-human access. The article correctly points to lifecycle management when projects end, but the larger issue is that AI-connected access often has no clear offboarding event. That creates privilege creep across both human sessions and machine-granted authorisations. Practitioners should build offboarding rules for AI-related grants with the same seriousness applied to service accounts and third-party integrations.

From our research:

• 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.
• For a broader access-governance lens, Top 10 NHI Issues helps teams connect shadow AI discovery to identity inventory, lifecycle control, and privilege scope.

What this signals

Shadow AI is forcing IAM teams to treat browser-based AI use as an access governance problem. The next control gap is not whether employees will try unapproved AI, but whether identity teams can see the OAuth grants, extensions, and federated permissions that make that usage persistent. Programmes that still separate app approval from identity review will miss the real exposure chain.

Unauthorised data training creates a new persistence problem for security teams. Once sensitive content is used in a model workflow, the organisation may not be able to prove where that data ended up or remove its influence later. That pushes governance upstream toward prevention, content classification, and sanctioned alternatives rather than downstream cleanup.

With 4.6% of all public GitHub repositories containing at least one hardcoded secret, per the State of Secrets Sprawl 2025, data leakage is already an identity and workflow problem. Shadow AI extends that same pattern into prompts, transcripts, and model inputs, so detection has to span files, code, and conversational interfaces.

For practitioners

• Inventory AI-connected access paths Map browser extensions, OAuth consents, and federated app connections that can reach corporate data. Prioritise tools with read/write access to files, mail, chat, and calendars because those paths can expose sensitive content without a visible SaaS deployment record.
• 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. Tie approval to data classification so sensitive content is blocked before it can enter model training or memory.
• Add AI-related grants to access reviews Include AI services, browser extensions, and third-party app permissions in recurring access reviews. Remove standing authorisations when the business purpose ends, because dormant grants become the easiest route for future shadow AI misuse.
• Provide a sanctioned AI lane Offer approved tools with clear data handling rules, restricted scopes, and monitored integrations so employees do not route work through unmanaged alternatives. If the sanctioned path is unusable, shadow AI will reappear in browser extensions and personal accounts.

Key takeaways

• Shadow AI is best understood as unmanaged access to data-processing identities, not simply as banned software.
• The central risk is persistence, because data submitted to AI tools can be retained, reused, or absorbed into model behaviour.
• Teams should govern AI tools through discovery, access review, and sanctioned alternatives before employees route sensitive work into public models.

Key terms

• Shadow AI: Shadow AI is the use of unapproved AI tools or AI-connected services inside an organisation. The governance issue is not just policy drift. It is unmanaged data access, hidden authorisation, and uncertain downstream use of the content submitted to those tools.
• Unlearning Problem: The unlearning problem is the difficulty of removing sensitive data’s influence from a model after it has already been learned. In practice, this means an organisation may not be able to reliably erase the impact of data submitted to an AI system without retraining or rebuilding the model.
• OAuth Consent: OAuth consent is the authorisation a user grants to a third-party app or service to access data in a connected account. In shadow AI cases, consent can create durable access paths that outlive the user’s immediate task and should therefore be reviewed like any other identity grant.
• Browser Extension Risk: Browser extension risk is the exposure created when add-ons can read page content, session data, or form input across the web. For AI governance, extensions matter because they can become hidden conduits for data collection and third-party access that standard software inventories often miss.

Deepen your knowledge

Shadow AI governance and non-human identity controls are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy around AI tool discovery, access review, and sanctioned alternatives, it is worth exploring.

This post draws on content published by JumpCloud: Shadow AI governance and the Discover, Govern, Enable framework. Read the original.