Shadow AI on endpoints exposes a new identity governance gap

At a glance

What this is: Shadow AI is expanding on employee endpoints through local models, extensions, and OAuth-connected assistants, and the core finding is that these tools create unmanaged non-human identities with inherited access.

Why it matters: It matters because IAM, PAM, and lifecycle programmes now have to govern AI-adjacent identities and access paths that appear outside procurement, inventory, and review processes.

👉 Read Delinea's blog post on controlling shadow AI on endpoints

Context

Shadow AI is the use of unsanctioned AI tools, local models, browser extensions, or AI-connected workflows that sit outside formal inventory and control. In this case, the identity problem is not just data leakage. It is that each OAuth grant, plugin, or local runtime can inherit user permissions and behave like a non-human identity on the endpoint.

That makes endpoint governance an identity governance issue as much as an application security issue. Traditional approval, inventory, and review cycles were built for software deployed through managed channels, not for AI tools that arrive through a browser click, a free download, or a plug-in store. The article reflects a typical enterprise starting point: visible enough for users, mostly invisible to security.

The security gap widens because the same endpoint can now host human work, machine automation, and AI-assisted workflows at once. Once those tools can read mail, move files, or call APIs, access management has to account for identity inheritance, standing privilege, and revocation across multiple actor types.

Key questions

Q: How should security teams govern AI tools that inherit user permissions on endpoints?

A: Treat each OAuth-connected assistant, plug-in, or local model as a non-human identity with delegated authority. Map what it can read, change, or trigger, then bind it to ownership, review, and revocation controls. If the tool can act on behalf of a user, it belongs in the same governance cycle as other privileged access, not in an informal exception path.

Q: Why do shadow AI tools create more risk than ordinary shadow IT?

A: Shadow AI is more dangerous because it can process far more sensitive data and act through inherited permissions. A browser-based assistant or local model may read mail, files, or connected SaaS systems, which turns a convenience tool into an identity and data-access issue. The risk is not just unsanctioned software, but unsanctioned authority.

Q: What breaks when employees paste secrets into AI chat tools?

A: Secrets can leave the organisation through a normal work interaction rather than a known transfer channel. Once an API key, token, or connection string is entered into an AI tool, it may be logged, cached, indexed, or exposed through downstream integrations. That makes secret containment slower, harder to trace, and often impossible to fully reverse.

Q: How can organisations reduce Shadow AI risk without banning AI outright?

A: Use a visibility first approach: discover what is installed, publish a short approved tool catalog, restrict unnecessary privilege, and train employees on what data can be shared. The goal is to make sanctioned tools easier to use than shadow tools. If the approved path is fast and clear, usage becomes governable rather than underground.

Technical breakdown

OAuth-connected AI assistants and inherited access

When an employee grants OAuth access to an AI assistant, the tool inherits the permissions of that human account for as long as the grant remains active. That makes the assistant a non-human identity with delegated authority, not just a convenience layer. The risk is not limited to prompt content. The integration can read mailboxes, access files, and trigger actions across connected SaaS platforms. In practice, the identity boundary shifts from the user to the assistant, but most organisations still track only the human account. That leaves access governance blind to the actual actor using the permissions.

Practical implication: inventory OAuth grants as identities in their own right and tie them to PAM-style review, scoping, and revocation.

Local LLM runtimes and endpoint privilege

Local models such as workstation-hosted LLMs often need persistent processes, disk space, GPU access, and sometimes administrative rights to install or update. That combination creates an endpoint footprint outside normal software procurement and patch management. The governance issue is not model accuracy. It is that the runtime itself can become an unmanaged privileged workload on a human endpoint. If the model wrapper is granted elevated rights to make installation easier, the endpoint begins to accumulate standing privilege that outlives any single user session or task.

Practical implication: treat local AI runtimes as privileged software and restrict administrative elevation unless the use case genuinely requires it.

Secret exposure through AI chat and copilots

Developers and business users routinely paste API keys, tokens, connection strings, contracts, and regulated data into AI tools while asking for help. That creates a secret-exposure path that bypasses traditional DLP assumptions because the leak happens through normal work interactions, not a deliberate exfiltration step. Once the secret is copied into a prompt, it can be logged, cached, indexed, or retained by downstream integrations. This is a classic NHI problem because the exposed credential is often what authorises production access, and the original user may never know the scope of what was shared.

Practical implication: extend secret-detection and endpoint controls to AI interfaces, not just source repositories and ticketing systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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 really NHI sprawl in disguise: once an AI tool inherits OAuth permissions or runs persistently on an endpoint, it becomes a non-human identity that security teams must govern. The article's most useful contribution is to collapse the false boundary between AI adoption and identity management. The practical conclusion is that endpoint AI discovery belongs in NHI governance, not in a separate innovation queue.

Identity inheritance is the failure mode that matters most: the human account is usually not the real actor after delegation. The assistant, plugin, or local runtime executes with borrowed authority, which means review processes that only inspect the person miss the thing doing the work. That is why PAM, inventory, and offboarding need to follow the grant, not just the employee. The practitioner takeaway is to govern the delegated identity, not the nominal user.

Shadow AI creates secret exposure debt: every prompt that includes a key, token, or contract expands the blast radius of a leak beyond the endpoint itself. The named concept here is ephemeral credential trust debt, the gap between how casually a secret is shared and how slowly its impact can be contained. Once a secret enters an AI workflow, the organisation may never know how far it propagated. The conclusion for practitioners is that discovery without content-aware control is incomplete.

Endpoint control now has to cover three actor types at once: human users, NHI integrations, and AI-driven assistants increasingly coexist on the same workstation. That makes access review cadence, privilege elevation, and application control interdependent rather than separate disciplines. The article shows why shadow AI is not just an endpoint visibility issue but a governance integration issue. Practitioners should treat workstation AI as a cross-domain identity problem, not a point control problem.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Our research also found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is the exact control blind spot shadow AI exploits when it inherits access.
• For a broader control lens, see 52 NHI Breaches Analysis, which shows how hidden identities and weak governance repeatedly turn small exposures into larger incidents.

What this signals

Ephemeral credential trust debt: shadow AI expands the gap between how quickly users adopt new tools and how slowly security teams can review the identity grants behind them. That means endpoint discovery, OAuth governance, and access review need to converge into a single operating model, not remain separate workflows.

The practical signal for programmes is that workstation AI is no longer just an application allowlist issue. Teams should expect more non-human identities to appear through browser plugins, local runtimes, and delegated SaaS access, then use endpoint control plus governance review to keep the estate legible.

The same pattern is already visible in NHI programmes more broadly, where security confidence remains low and visibility gaps persist. Shadow AI is simply the next place those gaps surface, which is why the governance boundary now needs to include the endpoint, the identity grant, and the data path together.

For practitioners

• Inventory AI tools on the endpoint Use endpoint privilege management and application control to identify browser extensions, local model runtimes, and AI apps that are running outside procurement and security review. Prioritise tools that can read mail, files, or connected SaaS data through delegated credentials.
• Review OAuth grants as non-human identities Map every AI assistant, plug-in, and connector to the account it impersonates, then classify the access it inherits. Revoke grants that are no longer needed and require explicit ownership for each connected service.
• Restrict local model elevation on workstations Block administrative installation paths where a local LLM or wrapper does not need them, and monitor for persistent processes that create an unmanaged endpoint footprint. Fold these binaries into software allowlists and patch review.
• Extend secret controls to AI interfaces Apply secret scanning and user guidance to chat tools, copilots, and IDE assistants so API keys, tokens, and connection strings are caught before they are pasted. Add endpoint alerts for repeated sharing of sensitive strings with external AI services.
• Make sanctioned AI easier than shadow AI Publish a curated approved-tool list, explain what data each tool can handle, and make requests for new tools fast and visible. Reducing friction is a control because users will route around slow approval paths.

Key takeaways

• Shadow AI turns ordinary endpoint usage into an identity governance problem because assistants and plugins inherit user permissions.
• The main operational risk is not adoption volume but hidden authority, secret exposure, and unmanaged access persistence across SaaS and local runtimes.
• Teams that combine endpoint discovery, OAuth review, and least-privilege enforcement can govern AI use without forcing it underground.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, models, or assistants that operate outside formal inventory and security governance. In practice, it includes browser extensions, local runtimes, and SaaS-connected copilots that can process sensitive data or act with inherited permissions without being approved or reviewed.
• Identity Inheritance: Identity inheritance is the transfer of access from a human account to a tool, assistant, or workflow that acts on the user's behalf. The security issue is not the software itself but the borrowed authority, which can outlive the task and bypass ordinary review, ownership, and revocation processes.
• Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the accumulated risk created when secrets are shared casually with tools that can cache, log, or forward them. The credential may be short-lived, but the exposure path is not. This creates a gap between momentary usage and long-lived governance impact.
• Endpoint Privilege Management: Endpoint privilege management is the control of what software can do on a workstation, including installation, elevation, and runtime behavior. In shadow AI environments, it becomes a way to discover and constrain local model runtimes, plug-ins, and binaries that might otherwise bypass standard software oversight.

Deepen your knowledge

Shadow AI, endpoint discovery, and delegated access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring AI tools under the same identity controls as service accounts and other non-human identities, it is worth exploring.

This post draws on content published by Delinea: Shadow AI is already on your endpoints. Here’s what to do about it. Read the original.