TL;DR: Shadow AI now includes unapproved tools, browser extensions, OAuth-connected apps, and locally installed assistants that can process sensitive data outside IT oversight, creating visibility, compliance, and identity risk, according to Blackpoint Cyber. The governance failure is not the model itself but the unmanaged access path, because the first control gap appears when approved accounts and data reach unreviewed AI services.
At a glance
What this is: This is an MSP-focused analysis of shadow AI, showing that unapproved AI tools create data, compliance, endpoint, and identity exposure when employees use them outside IT oversight.
Why it matters: It matters because identity teams, MSPs, and security owners must govern not just sanctioned AI platforms but also the OAuth grants, endpoints, and data paths unapproved AI quietly creates.
Context
Shadow AI is an access and governance problem, not just a tooling problem. When employees adopt AI services, extensions, or embedded features without review, the organisation loses visibility into what data is processed, retained, or shared. For identity and security teams, the issue sits at the intersection of SaaS consent, endpoint control, cloud identity sprawl, and data handling risk.
The MSP angle makes the problem more operationally urgent. In managed environments, one unsanctioned AI app can appear across multiple tenants, while account-level consent and broad permissions leave a standing relationship that may outlast the original use case. That combination turns a convenience decision into an access governance issue that conventional inventory and review processes often miss.
Key questions
Q: What breaks when employees use shadow AI for work tasks?
A: Shadow AI breaks identity visibility and lifecycle control. Employees can create or use AI accounts, connect them to work data, and move sensitive information outside approved governance. That leaves security teams unable to reliably inventory the identity, review its access, or revoke delegated permissions when the business need ends.
Q: Why do OAuth-connected AI apps create hidden data exposure risk?
A: OAuth-connected AI apps can hold broad, persistent permissions that outlive the employee’s immediate use of the tool. That turns a quick signup into a standing delegated access path. The risk grows when users or admins approve read, write, or offline scopes without a lifecycle process for ownership, review, and revocation.
Q: How can MSPs detect shadow AI across client environments?
A: Start with inventory. Identify installed AI-enabled apps, browser extensions, SaaS features, and OAuth-connected services in each tenant, then compare them against approved software and consent settings. That gives you a practical discovery baseline and shows where unreviewed AI may already have access to client data.
Q: Should organisations treat shadow AI as a security risk or an innovation issue?
A: Treat it as both, but govern it first as a security risk. Shadow AI becomes dangerous when it can reach data, call APIs, or make decisions outside approved control paths. Security teams should build intake and review processes that allow safe experimentation without leaving identities and permissions unmanaged.
Technical breakdown
Why shadow AI creates a governance blind spot
Shadow AI exists when employees use AI tools, apps, or embedded features without IT or security approval. The technical problem is not merely that the tool is unknown, but that its data handling, retention, and permission model are also unknown. Once a user pastes content, authorises an app, or enables a feature inside a SaaS platform, the organisation has already lost control over the access boundary. That is why inventory, consent policy, and sanctioned alternatives matter more than simple user warnings.
Practical implication: Build discovery around applications, extensions, and SaaS-connected AI features before you try to govern their use.
OAuth consent turns AI apps into standing identities
When a user grants an AI app access through OAuth, the app often receives durable access to mailbox or file data. That grant behaves like part of the cloud identity footprint, even if no one treats it as a privileged account. Because the relationship persists beyond the initial click, it can evade ordinary access reviews and offboarding workflows. In practice, the risk is not only the app itself but the delegated authority it inherits through the user or tenant.
Practical implication: Treat third-party AI consent as an identity governance event and review it with the same discipline as other cloud entitlements.
Unvetted AI extensions expand the endpoint attack surface
Browser extensions, desktop assistants, and local AI agents introduce another layer of risk because they can run with broad user permissions and interact with email, files, or browser sessions. If the extension is not inventoried, it cannot be patched, constrained, or monitored in the same way as approved software. That creates an attractive path for both data exposure and impersonation. The security gap is especially visible in MSP environments, where one popular extension can spread the same exposure across multiple tenants.
Practical implication: Control which AI-capable software may run on endpoints and include extensions in software inventory and approval workflows.
Threat narrative
Attacker objective: The objective is to reach sensitive client data or privileged cloud content through an access path that the organisation never formally approved or monitored.
- Entry occurs when an employee installs an unapproved AI tool, browser extension, or embedded AI feature without security review.
- Credential_harvested occurs when the user authorises the app through OAuth or pastes sensitive material into the service, giving it standing access to mail or files.
- Escalation follows as the connected app or extension continues operating outside regular access review and can expose regulated or confidential data over time.
- Impact is data loss, compliance exposure, or tenant-wide spread of the same ungoverned AI control across managed environments.
Breaches seen in the wild
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
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 is now a governance failure mode, not a novelty problem. The issue is not whether employees use AI, but whether the organisation knows which tools can touch data and under what authority. That is why shadow AI belongs in the same governance conversation as SaaS sprawl, delegated access, and data classification. For practitioners, the control question is who approved the access path, not which model produced the output.
OAuth consent is the clearest identity bridge in shadow AI risk. A user-approved AI app can sit outside normal review while retaining a live relationship to mailboxes or files. That means access governance has to follow the grant, not the tool name, and cloud identity inventory becomes part of AI oversight. Practitioners should treat every third-party AI consent as a standing entitlement with an owner, scope, and revocation path.
Shadow AI creates a visibility trust gap across MSP environments. One unsanctioned app can appear in many tenants, so a local user decision becomes a multi-customer exposure pattern. This is where managed service providers face a different risk profile from single-enterprise teams: the same blind spot scales across the book of business. The implication is clear, discovery and tenant-level control need to be standardised before AI adoption becomes entrenched.
Unmanaged AI features in approved SaaS are the most overlooked risk class. The vendor may be vetted, but the new feature added last month may not have been reviewed for data handling or access scope. That creates governance debt inside otherwise approved platforms, which is harder to detect than a standalone rogue app. Practitioners should assume the control failure can live inside a trusted product and build review processes around feature changes as well as new software.
Shadow AI belongs in the same control family as cloud identity sprawl. Once AI tools can read mail, access files, or summarise regulated content, they become part of the identity and access landscape whether or not administrators planned for them. The named concept here is shadow AI identity drift: access that appears through convenience, then persists without lifecycle control. Practitioners should govern it as an identity lifecycle problem with data consequences, not as a one-off user-behaviour issue.
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
Shadow AI discovery has to start at the identity layer. The practical control point is not the model catalogue, it is the consent trail, endpoint software list, and SaaS feature inventory that reveal where unapproved AI can reach data. If those three views are disconnected, governance will always lag adoption.
Identity governance and endpoint control now overlap in AI oversight. An AI assistant, extension, or connected app can become part of the cloud identity footprint without ever looking like a traditional account. Practitioners should expect AI use to surface as a review problem, a consent problem, and an inventory problem at the same time.
Shadow AI identity drift: this is the pattern where a convenience-driven AI grant or feature becomes a standing access path outside normal lifecycle control. MSPs and enterprise teams should treat that drift as an operational signal that discovery and revocation are out of sync.
For practitioners
- Discover sanctioned and unsanctioned AI touchpoints Inventory installed applications, browser extensions, SaaS AI features, and OAuth-connected apps in each tenant so you know where AI can reach data.
- Restrict user-driven app consent Disable or limit self-service consent where possible and require review for third-party apps that request mailbox or file access.
- Define prohibited data categories for AI use Write a short acceptable use policy that explicitly bans regulated records, credentials, and client-confidential material from unapproved AI tools.
- Control AI-capable software on endpoints Use application control to block unapproved desktop assistants, local AI agents, and high-risk extensions on managed devices.
- Monitor connected-app behaviour Watch for unusual patterns such as newly authorised apps reading mail at odd hours or accessing files beyond expected business use.
Key takeaways
- Shadow AI creates risk because unapproved AI tools can process sensitive data outside the controls applied to sanctioned systems.
- The most important exposure path is delegated access, especially when users approve AI apps through OAuth and forget about the grant.
- MSPs and security teams should focus on discovery, consent control, and endpoint restrictions rather than relying on policy language alone.
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 CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Shadow AI often enters through weakly governed consent and delegated access. |
| NHI-10 — Human Use of NHI | Employees using unapproved AI tools create unmanaged machine identities through convenience. | |
| Recommendation — Review AI app consent flows under NHI-04 and remove standing access grants that lack business approval. Classify employee-approved AI services under NHI-10 and govern their access as machine identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Shadow AI risk is driven by unreviewed entitlements to mail, files, and SaaS data. |
| Recommendation — Apply PR.AA-05 to inventory and review AI app entitlements before they reach sensitive data. | ||
| CIS Controls v8 | CIS-5 — Account Management | AI app grants behave like accounts and need the same lifecycle oversight. |
| Recommendation — Use CIS-5 to track, review, and remove dormant AI-related accounts and app grants. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | Unapproved AI apps can become paths for data access and theft in real environments. |
| Recommendation — Map shadow AI detections to TA0006 and TA0010 to prioritise exposed identity and data paths. | ||
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.
- OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
- Cloud Identity: A cloud identity is any account, role, token, or credential used to access cloud services and resources. In practice, it includes both human and non-human identities that can authorize actions in infrastructure, applications, or automation pipelines. Governance depends on knowing which identity type is active and what it can do.
- Application control: Application control is the enforcement of which software may run on a device and under what conditions. It is a key governance layer because unauthorized or unsafe code can undermine access assurance even when authentication and device enrolment are in place.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity control to the broader security programme that needs to govern AI access paths and delegated permissions.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org