Shadow AI is creating a data governance gap IAM cannot ignore

At a glance

What this is: This is an analysis of Shadow AI and its key finding that unsanctioned AI use spreads faster than traditional discovery and often bypasses network-centric controls.

Why it matters: It matters because IAM, NHI, and governance teams need visibility into OAuth grants, browser sessions, and AI-linked access paths before sensitive data leaves the organisation.

By the numbers:

• By Q1 2026, large enterprises doing full Shadow AI discovery audits were typically finding 8–12× more AI tools in active use than their security team had on file.
• The average mid-market and enterprise company has 25–30 AI tools active in the shadows, while security teams are aware of fewer than five.

👉 Read Strac's guide to Shadow AI detection and control in 2026

Context

Shadow AI is the use of AI tools, models, or agents inside an organisation without formal approval or oversight, and the governance gap is that the data leaves through ordinary work patterns rather than obvious exfiltration. For IAM and security teams, the problem is not limited to one application category. It spans personal accounts, SaaS-embedded AI features, OAuth grants, browser extensions, and local MCP servers, all of which can expand access without passing through standard review.

The article frames Shadow AI as a control problem that traditional discovery stacks cannot solve on their own. That is especially relevant to identity programmes because the riskiest paths often look legitimate at the identity layer, such as delegated SaaS permissions, approved logins on unmanaged accounts, or tool access granted by a single employee. In practice, this is now a broader identity and data governance issue, not just an acceptable-use issue.

Key questions

Q: How should security teams govern shadow AI without blocking productivity?

A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.

Q: Why do personal accounts and OAuth grants make shadow AI a governance problem?

A: Because they turn a simple app choice into delegated access. A personal account can bypass corporate authentication controls, and an OAuth grant can give an AI tool persistent access to mail, storage, or code repositories. That means the real risk is not just use, but the access path created behind the use.

Q: What breaks when organisations rely only on network logs to detect Shadow AI?

A: They miss the most important part of the event, which is the prompt content and the file or clipboard data being submitted. Network logs can show that AI traffic happened, but not whether the user pasted secrets, PII, or source code. That leaves the highest-risk behaviour invisible until after the data has already left the environment.

Q: What should teams do when MCP servers are running on developer laptops?

A: Treat them as governed integrations, not informal utilities. Identify the resources each server can reach, restrict filesystem and credential access by default, and require authentication or scoping before the server can connect to internal systems. If a local MCP server can read secrets or browse corporate data freely, it is already outside acceptable control.

Technical breakdown

Why browser-based AI usage defeats network-only controls

Most Shadow AI activity happens inside a browser session, which means the visible destination is often just a known SaaS domain over HTTPS. Network controls can tell you that traffic went to chat.openai.com or claude.ai, but not what data was pasted, uploaded, or granted through the session. That is why browser-level telemetry matters: it exposes prompts, file uploads, and clipboard transfers, which are the actual control points for data loss. In governance terms, the control boundary must shift from destination filtering to content-aware enforcement.

Practical implication: pair browser visibility with prompt-level redaction so the control acts before sensitive data leaves the session.

How OAuth grants turn AI into an identity problem

Shadow AI often enters through OAuth-authorised applications that inherit access to Google Drive, Gmail, Slack, or GitHub after a single user consent action. At that point the AI tool is not just a productivity app, it is a delegated identity with scope that may be far broader than the business intended. That makes the issue squarely relevant to IAM and NHI governance because the permission is persistent, user-mediated, and easy to forget. The real risk is not login alone, but long-lived delegated access that outlives the original use case.

Practical implication: inventory delegated AI apps as privileged access paths and review scopes with the same discipline used for service accounts.

MCP servers create a local workload identity risk

Locally run MCP servers connect LLM clients to filesystems, databases, Slack, and cloud APIs, often with little or no authentication and broad local access. In effect, the developer laptop becomes an undocumented integration hub that can read .env files, SSH keys, browser cookies, and internal documents, then pass them to a remote model. That is a non-human identity problem because the toolchain is acting on behalf of the user and often on behalf of the workstation context. The risk scales when those servers are network-exposed or left running with default scopes.

Practical implication: treat MCP servers as governed workloads and restrict the local resources they can access by default.

Threat narrative

Attacker objective: The objective is to capture sensitive enterprise data and access paths through trusted AI interactions that bypass normal governance checkpoints.

1. Entry occurs when an employee adopts an unsanctioned AI tool, browser extension, delegated app, or local MCP server outside formal review.
2. Escalation follows when the tool gains broad content access through pasted prompts, OAuth scopes, filesystem context, or workspace indexing.
3. Impact occurs when regulated data, source code, credentials, or internal records are retained, exposed, or redistributed outside the organisation's control.

NHI Mgmt Group analysis

Shadow AI is now an identity governance problem, not just a data leakage problem. The article shows that the riskiest AI use often comes through authorised identities on unauthorised tools, or unauthorised identities on authorised tools. That combination breaks the normal assumptions behind inventory, approval, and audit. For IAM teams, the governance boundary now includes browser sessions, OAuth consents, and AI-linked delegated access, not just directory accounts.

Browser visibility is becoming a control plane for AI risk. Network logs and SaaS audits still matter, but they are insufficient when the prompt itself is the loss event. The named concept here is the prompt-level governance gap: security teams can know which AI tools are present without knowing what data is being submitted. That gap changes how organisations think about DLP, approval, and policy enforcement.

OAuth scope sprawl is the most overlooked AI access problem. A single employee grant can create persistent access to mail, files, chats, or repositories that no one revisits after the initial use case. This is a classic lifecycle failure expressed through AI. The right lesson is not that all AI is risky, but that delegated identity paths need the same lifecycle governance as other high-value access routes.

MCP changes the unit of governance from application to workstation context. Local servers can expose files, tokens, and internal data to model clients without passing through central controls. That means workload identity concepts now matter on the endpoint as well as in the cloud. Practitioners should assume that unmanaged local integrations can become the quietest route to enterprise data.

Blocking AI outright is the wrong control philosophy. The article correctly points toward continuous discovery and redaction because adoption is already embedded in daily work. The more durable model is governed use with minimised data exposure, not prohibition. Teams that cannot enforce this will keep rediscovering the same access and data problems under new AI labels.

What this signals

Prompt-level governance gap: the next wave of AI risk is not hidden models but hidden data movement inside ordinary browser workflows. Programmes that can see tools but not prompts will continue to undercount exposure, especially where identity-bound access grants outlive the original user intent.

Shadow AI discovery needs to converge with identity governance, because the same user can create risk through a personal account, a delegated SaaS app, or a local MCP server. That means access review, scope reduction, and data redaction now belong in the same operating model, supported by guidance such as NIST Cybersecurity Framework 2.0 and OWASP Agentic AI Top 10 where agentic workflows are involved.

The operating signal is simple: if you cannot tie AI use to an approved identity, a bounded scope, and a data-handling policy, it is still Shadow AI. Teams should expect that unmanaged AI will keep expanding until browser controls, OAuth inventory, and prompt redaction are treated as one control plane.

For practitioners

• Implement browser-level AI visibility Deploy controls that can observe prompts, pasted content, file uploads, and clipboard events in browser-based AI sessions, then route high-risk activity into alerting or redaction workflows.
• Review OAuth grants for AI-linked apps Inventory AI applications with delegated access to Google Workspace, Microsoft 365, Slack, and GitHub, then remove scopes that are broader than the use case requires.
• Classify MCP servers as governed workloads Track local MCP servers on developer endpoints, identify which resources they can reach, and block default access to home directories, secrets stores, and internal APIs.
• Shift DLP to the prompt boundary Apply data classification and redaction before prompts are submitted so PII, source code, secrets, and regulated records never reach consumer or shadow AI tools in plain text.
• Create an approved AI tool path Offer sanctioned enterprise AI options with SSO, logging, and policy enforcement so users have a practical alternative to personal accounts and unmanaged extensions.

Key takeaways

• Shadow AI becomes dangerous when unsanctioned tools inherit real business data and access paths that no one has reviewed.
• The scale problem is already visible in discovery gaps, with organisations finding far more AI use than their security teams expected.
• The most durable response is governed AI use with prompt-level redaction, OAuth review, and local MCP control, not blanket prohibition.

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.
• Prompt-level data leakage: Prompt-level data leakage happens when sensitive information is pasted into an AI prompt and leaves the organisation’s secure environment. The control failure is not just application access, but the lack of rules and enforcement around what data can be submitted in the first place.
• OAuth grant sprawl: The accumulation of third-party application permissions that extend access to mail, files, chat, or code repositories beyond what teams intended. In Shadow AI cases, a single consent can create persistent delegated access that is difficult to notice, review, or remove at scale.
• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.

What's in the full article

Strac's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step detection method comparisons for browser telemetry, OAuth grants, SaaS logs, and endpoint visibility.
• Practical examples of how prompt-level redaction is applied to PII, PHI, source code, and secrets.
• Detailed discussion of MCP server discovery, local process visibility, and endpoint-scoped controls.
• Real-world Shadow AI patterns observed in discovery scans across different business functions.

👉 Strac's full guide covers the detection methods, MCP risks, and redaction patterns in operational detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect identity governance to the operational risks created by delegated AI access and unmanaged non-human identities.