TL;DR: Shadow AI is already embedded in browser extensions, IDE plugins, local models, and OAuth-connected assistants on employee endpoints, creating hidden data leakage, secret exposure, and long-lived non-human identities, according to Delinea. The real problem is not adoption itself, but unmanaged identity inheritance that extends user access into tools no security team has inventoried.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Delinea's blog post: Shadow AI on employee endpoints is turning unsanctioned AI tools and OAuth grants into hidden non-human identities with inherited access.
Why it matters: IAM, PAM, and NHI teams need endpoint visibility because shadow AI can bypass inventory, policy, and lifecycle controls before anyone notices.
Context
Shadow AI is what happens when employees use AI tools, local models, or AI-enabled plugins outside the organisation’s approved inventory and governance process. On endpoints, that creates a control problem that is closer to identity governance than to simple software sprawl, because access often follows the user automatically.
The article’s core warning is that many AI tools inherit permissions through browser sessions, OAuth grants, and integrations that security teams never reviewed. That makes the endpoint the place where shadow adoption becomes identity risk, especially when the tool can read mail, move files, or call APIs on a user’s behalf.
This is not a future-state issue. The article describes a live governance gap already present in common workstation workflows, where user convenience has outpaced discovery, approvals, and revocation discipline. That pattern is typical across enterprises rather than an edge case.
Key questions
Q: What breaks when shadow AI is not part of the asset inventory?
A: When shadow AI is absent from inventory, security teams cannot apply policy, logging, access review, or remediation to the workload. That means the service may process sensitive data and expose credentials without ever entering the governance process, which turns discovery into a control boundary, not just a reporting issue.
Q: Why do OAuth grants to AI assistants create more risk than a normal SaaS login?
A: OAuth grants can persist after the initial login and allow an app to act on a user’s behalf without repeated prompts. That makes them hard to spot with MFA centered monitoring, especially when the app looks user approved. If the token is stolen, the attacker inherits the delegated access path until the grant is revoked or expires.
Q: What are the signs that shadow AI is leaking secrets?
A: Look for prompts containing API keys, tokens, connection strings, customer data, or regulated information, especially when the same workstation also runs local models or AI plugins. Repeated copy-and-paste into AI tools is a strong indicator that secret handling has escaped normal controls.
Q: Should IAM and PAM teams treat AI assistants like privileged accounts?
A: Yes. If an assistant can read mail, move files, or call APIs on behalf of a user, it should be governed as an identity with an owner, a defined scope, monitoring, and revocation rules. That is the only practical way to control delegated access at endpoint speed.
Technical breakdown
Endpoint-distributed shadow AI expands the identity perimeter
Shadow AI on endpoints is not just an application inventory problem. Browser extensions, IDE plugins, meeting assistants, local model runtimes, and productivity apps now embed AI functions directly into the user’s workstation, which means the control boundary has moved from the data centre to the desktop. Once an employee grants access or installs an agentic tool, the tool can inherit context, credentials, or session state without passing through normal procurement or review paths. In practice, the endpoint becomes the first and often only place where that identity is created, used, and hidden.
Practical implication: discover AI-capable binaries, extensions, and OAuth grants at the endpoint before they accumulate unmanaged access.
OAuth grants turn AI assistants into long-lived NHIs
When an AI assistant connects to Microsoft 365, Google Workspace, GitHub, or Salesforce through OAuth, it becomes more than a convenience layer. It is effectively a non-human identity with delegated access to the user’s permissions, and that delegation often outlives the human’s active use of the tool. Because OAuth scopes are usually granted once and reused silently, the assistant can persist as a standing identity even when the employee forgets it exists. That creates a lifecycle problem, not just an authentication problem.
Practical implication: inventory delegated OAuth access as NHI and apply revocation, scoping, and review controls to every grant.
Secrets exposure and privilege creep are the two fastest failure modes
The article points to two common technical failures. First, users paste API keys, tokens, and connection strings into AI prompts while debugging or automating work, creating immediate secret exposure. Second, local models and AI wrappers often request admin rights or persistent privileges that exceed what the task actually needs, which creates privilege creep on the endpoint. These behaviours are dangerous because they combine high-value data handling with hidden runtime access paths that security teams rarely monitor in real time.
Practical implication: treat secret handling and endpoint privilege escalation as the first controls to validate for shadow AI use.
Threat narrative
Attacker objective: The objective is to obtain durable access to data, workflows, or secrets through user-trusted AI tooling without triggering normal governance controls.
- Entry begins when an employee installs a browser extension, IDE plugin, local model, or OAuth-connected assistant on an endpoint outside approved inventory. Credential access follows when the user pastes API keys, tokens, or sensitive data into the tool, or grants it delegated access to mailbox and workspace data. Escalation occurs when the assistant inherits the user’s permissions and keeps them beyond the immediate task, creating a persistent non-human identity. Impact is data leakage, secret exposure, and unauthorised actions performed through trusted user context.
Breaches seen in the wild
- 17,000+ Secrets Exposed in Public GitLab Repositories: Over 17,000 secrets including API keys and tokens exposed in public GitLab Cloud repositories.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Shadow AI on endpoints is now an identity governance problem, not an application preference problem: the control failure is not that employees are using AI, but that identity inheritance follows them into tools the organisation never approved. Browser extensions, local models, and AI assistants inherit context through the endpoint, which means governance has to start with discovery and delegation scope, not usage bans. The practical conclusion is simple: if the tool can act as the user, it must be governed as an identity.
OAuth-connected AI assistants create a new class of long-lived NHI: the article shows how a user’s one-time consent can turn into persistent delegated access across mail, files, and SaaS platforms. That changes the lifecycle question from installation to revocation, because the assistant continues to exist after the human stops thinking about it. Practitioners should read this as a signal that NHI inventory is no longer confined to back-end service accounts.
Secret exposure through AI prompts is a governance failure of context, not awareness: users paste keys and sensitive text because the workflow feels faster, not because they intend to bypass controls. The problem is that the endpoint collapses the boundary between debugging, collaboration, and credential handling. The implication is that endpoint telemetry and secret detection now sit inside the NHI governance model, not beside it.
Shadow AI will make service-account sprawl look small because every assistant behaves like a delegated actor with persistence: once AI tools can read mail, call APIs, and move files, the question is not whether they are useful, but how many unmanaged identities now exist on the endpoint. That forces IAM and PAM teams to treat the workstation as an identity creation surface. The field should expect more governance failures from delegation than from malware.
Identity blast radius is the right concept for this problem: the article’s strongest signal is that a user’s permissions can extend into an AI tool that was never designed as part of the identity programme. That makes blast radius a function of consent scope, session persistence, and revocation discipline. Practitioners should use that lens to decide which shadow AI tools can remain enabled at all.
From our research library:
- One in five organisations reported a breach due to shadow AI, and 97% of those breached through an AI model or application lacked proper AI access controls, according to IBM's 2025 Cost of a Data Breach Report.
What this signals
Identity inheritance is the key governance issue in shadow AI: once a user grants an assistant access through the endpoint, the tool can behave like a delegated actor rather than a simple application. That means security teams should think in terms of scope, persistence, and revocation, not just approved or unapproved software.
The operational boundary has shifted to the workstation, where discovery, entitlement review, and secret exposure now intersect. Organisations that do not extend PAM and NHI controls to endpoint-installed AI will keep finding unmanaged access after the fact, which is the wrong time to learn who owns the tool.
Identity blast radius is the right lens for programme planning because it captures how far a user’s permissions can travel once an AI tool is allowed to inherit them. Teams should assess whether their current governance model can see, scope, and revoke those delegated permissions before they become persistent.
For practitioners
- Discover AI-capable tools on every endpoint Inventory browser extensions, IDE plugins, local model runtimes, and installed assistants on employee workstations, then flag anything that can accept prompts, launch subprocesses, or request OAuth access.
- Inventory delegated OAuth access as NHI Review grants to Microsoft 365, Google Workspace, GitHub, Salesforce, and similar systems, then classify each AI assistant as a non-human identity with an explicit owner and expiry.
- Restrict endpoint privilege for local AI tools Remove administrative rights from local model wrappers and AI runtimes unless the process genuinely requires elevation, and monitor for privilege escalation requests during launch.
- Detect secret sharing in AI prompts Add secret-scanning and behavioural alerts for prompts that contain API keys, tokens, connection strings, or other credential material so leakage is detected before it spreads.
Key takeaways
- Shadow AI on endpoints is creating a governance gap because identity follows the user into tools that were never formally approved or inventoried.
- The most material risks are secret exposure, delegated OAuth access, and persistent non-human identities that outlive the task that created them.
- IAM and PAM teams need endpoint discovery, delegated access review, and revocation discipline to keep shadow AI from turning user convenience into standing access.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | AI assistants and plugins inherit access from third-party services and endpoint tools. |
| NHI-04 — Insecure Authentication | OAuth-connected assistants authenticate as the user and can persist beyond intended use. | |
| NHI-05 — Overprivileged NHI | The article highlights assistants and local tools that inherit more access than their task requires. | |
| Recommendation — Map delegated AI access paths to NHI-03 and review each third-party integration for ownership and revocation. Apply NHI-04 controls to review delegated authentication scopes and revoke unused AI grants. Constrain AI assistants to least privilege and remove permissions that are not essential to the workflow. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article centres on delegated credentials, tokens, and OAuth grants that need lifecycle control. |
| Recommendation — Use IA-5 to manage, rotate, and revoke credentials that underpin endpoint AI access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Shadow AI becomes risky when endpoint tools inherit unchecked permissions and entitlements. |
| Recommendation — Apply PR.AA-05 to review and limit entitlements granted to AI tools on employee endpoints. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The article explicitly warns that users paste API keys and tokens into AI tools. |
| Recommendation — Map prompt-driven secret exposure to TA0006 and hunt for leaked credentials in endpoint telemetry. | ||
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.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- Identity Inheritance (Agent): The condition where an AI agent operates using the permissions of a human user or parent system, granting it access to everything that identity can reach. A major source of over-privilege in agentic deployments.
- 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
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org