Shadow AI: what it is, how widespread it is, and how to detect it

TL;DR

• Shadow AI is AI use at work that IT and security have not approved: personal chatbot accounts, AI browser extensions, desktop AI clients, coding agents and the MCP servers wired into them.
• Verizon’s 2026 DBIR finds 67% of AI users on corporate devices sign in with non-corporate accounts. IBM’s 2026 breach study puts shadow AI in 43% of AI security incidents, up from 20%, at an average cost of $5.39 million.
• Detection needs four layers. Network inspection, identity discovery, endpoint agents and an AI gateway each see a different part of the traffic, and none sees all of it.
• Bans push usage onto personal phones. The programs that work sanction approved tools with enterprise data terms, route them through one gateway with per-user keys and logs, and publish an AI acceptable use policy.
• Gateway plus endpoint is the pattern for laptops: Bifrost, an open-source AI gateway, holds policy, and Bifrost Edge (early access) routes desktop, browser and coding-agent traffic through it.

Shadow AI is the use of AI tools, models and agents at work without the approval or oversight of the organization’s IT and security teams. It is the 2020s version of shadow IT, with one difference that changes the risk: the thing employees adopt without asking is a service designed to receive text, files and source code and send back an answer. In 2026 it is also the norm rather than the exception. Two independent datasets, one built from breach investigations and one from network telemetry, show unsanctioned AI accounts on most corporate devices and shadow AI behind a growing share of security incidents. This explainer covers what counts as shadow AI, what the evidence says about its scale, which risks are real, how detection works at each layer, and how organizations turn unsanctioned use into governed use without banning AI outright.

What shadow AI means

Shadow AI covers any AI capability used for work that the organization has not reviewed, approved or put under its controls. The category is wider than “someone using ChatGPT.” It includes consumer chat accounts, AI features switched on inside approved SaaS products, AI browser extensions, desktop AI clients, coding agents in the terminal, MCP servers connected to those agents, and scripts that call a model API with a personal key.

The term borrows from shadow IT, and Verizon’s 2026 Data Breach Investigations Report draws the parallel directly: unaccounted AI systems that hold corporate data “exist outside of the control of the organizations and can represent a significant risk for data leakage.” The difference is direction. A shadow file-sharing app stores data the employee chose to put there. A shadow AI tool is built to accept prompts containing whatever the employee is working on, and, depending on the plan and settings, the vendor may keep that content and use it for training.

Three variants deserve names because they need different controls:

• Shadow AI apps: chat services, desktop clients and browser extensions used with personal accounts.
• Shadow agents: coding agents and desktop agents that read local files, run commands and call tools on the user’s behalf.
• Shadow MCP: Model Context Protocol servers configured inside those agents, often installed with one command from a README. The Frontier Wire guide to MCP security tools covers this layer, and OWASP’s MCP Top 10 lists shadow MCP servers as its own risk.

A longer breakdown of the categories, with a control mapped to each, appears in this analysis of seven shadow AI exposure categories.

How widespread shadow AI is in 2026

Shadow AI is now the majority pattern on corporate devices. Verizon’s 2026 DBIR, drawn from data loss prevention telemetry, finds that 67% of AI users on corporate devices sign in with non-corporate accounts. IBM’s 2026 breach study, built on 602 breached organizations, finds shadow AI in 43% of AI-related security incidents, more than double the prior year.

The two studies measure different things, so the methodology matters as much as the headline.

Verizon defines a “regular user” as someone who accesses an AI platform at least once every 15 days. It also reports that the average company had more than 15% of users with unauthorized AI extensions installed in their browsers, and that source code was, “by a large margin,” the most common data type submitted to external AI models, followed by images and structured data. In 3.2% of the DLP policy violations it examined, research and technical documentation was uploaded to unauthorized AI systems.

IBM’s governance figures explain why the incidents keep growing. In 2026, 68% of breached organizations lacked governance to manage AI or detect shadow AI, up from 63%. Only 29% ran regular audits for unsanctioned AI, and only 19% said their governance and security teams coordinated.

Why employees adopt unapproved AI tools

Employees adopt shadow AI for ordinary reasons: the tools save time, the approved alternative is missing or worse, and the approval process is slower than the task. The Work Trend Index found BYOAI “even more common at small and medium-sized companies,” at 80%, which tracks with organizations that have not yet bought an enterprise AI plan.

Three structural causes recur across the sources:

• No sanctioned option. If the company has not licensed an AI assistant, the personal account is the only one available. Blocking a domain without offering an alternative moves the activity to a personal phone, where no corporate control applies.
• AI arrives inside tools that are already approved. Editors, note-taking apps, CRMs and browsers have shipped AI features that send content to a model provider. The application passed procurement before the feature existed.
• Developer tooling moves faster than review. Coding agents and MCP servers install from a package manager in seconds. Verizon’s finding that source code dominates data sent to external AI models fits this pattern.

The Bifrost blog’s essay on shadow AI as an insider threat makes the same point from the security side: the people creating the exposure are employees trying to do their jobs, which is why a response built only on blocking tends to fail.

Shadow AI risks

The core shadow AI risk is data leaving the organization through a channel with no contract, no log and no control. IBM found that shadow AI incidents led to data loss or compromise in 49% of cases and regulatory fines in about one in five. The other risks follow from the same gap: training on company data, IP exposure, compliance breaches, agent actions and untracked spend.

The training question is where plan type matters most. OpenAI’s help center states that for its services for individuals (Free, Plus and Pro), “we may use your content to train our models,” with an opt-out under data controls. Its enterprise privacy page states that business products such as ChatGPT Business, ChatGPT Enterprise and the API are not used for training by default. Anthropic’s 2025 consumer terms update asked Free, Pro and Max users, including Claude Code users on those plans, to choose whether their chats are used for training, and extended retention to five years for those who opt in; it does not apply to Claude for Work, the API, Amazon Bedrock or Vertex AI. The same employee, using the same model, can be inside or outside a data protection agreement depending only on which account they signed in with.

The best-known early case is Samsung. In May 2023, TechCrunch reported that Samsung temporarily restricted generative AI tools on company devices after internal data was accidentally leaked to ChatGPT the month before. The restriction covered company-owned computers, tablets and phones and non-company devices on internal networks.

Agents add a risk that chat does not. The MCP specification’s security guidance warns that local MCP servers “may have direct access to the user’s system and may be accessible to other processes running on the user’s machine, making them attractive targets for attacks.” A shadow MCP server is not only a data exit; it is code running with the developer’s permissions. Prompt injection turns that into an attack path, a mechanism covered in the Frontier Wire explainer on prompt injection.

How to detect shadow AI

Shadow AI detection combines four layers: network inspection of traffic to AI domains, identity and SaaS discovery of sign-ins and OAuth grants, endpoint agents that inventory installed AI apps and MCP configurations, and an AI gateway that logs every request routed through it. Each layer misses traffic another layer sees, which is why mature programs run at least two.

Figure 1: The endpoint agent is the only layer that sees configuration on the machine; the gateway sees only traffic routed to it.

Network inspection. Cloudflare’s Gateway sorts applications into app types, with an “Artificial Intelligence” group for AI assistance applications such as ChatGPT, Google Gemini, Perplexity and Claude, and its AI security report dashboard shows the most-visited AI applications by user count and data uploaded to AI applications by approval status. Microsoft’s shadow AI discovery in Global Secure Access is described as “a network-based feature” that identifies traffic to AI services “like ChatGPT, Claude, SaaS MCP servers, and AI Model Provider frameworks (for example, DeepSeek, Anthropic Claude API).”

Identity and SaaS discovery. The Defender for Cloud Apps catalog lists more than 31,000 discoverable cloud apps, scores each on more than 90 risk factors, and includes a Generative AI category, so administrators can tag AI apps as sanctioned or unsanctioned. Microsoft’s Data Security Posture Management for AI adds policies aimed at data loss in AI prompts.

Endpoint agents. These are the only layer that can list which MCP servers are configured across a fleet, because a local MCP server talks to its client over standard input and output and never crosses the network. They also see desktop clients and extensions regardless of which network the laptop is on.

AI gateway. A gateway produces the richest record (who, which model, how many tokens, what it cost, which guardrail fired), but only for traffic routed to it. On its own it governs the sanctioned path, not the shadow one, which is why the gateway is usually paired with one of the discovery layers above. A practical guide to detecting shadow AI across the organization walks through combining these signals into one inventory.

The AI acceptable use policy

An AI acceptable use policy tells employees which AI tools they may use, with which data, under which conditions, and how to request something new. It is the document that makes detection fair: monitoring is easier to defend when the rules it enforces were published first. IBM found only 32% of breached organizations had AI governance policies in place in 2026.

Policies that hold up in practice tend to cover the same eight points:

1. Approved tools, by name and plan, with the reason each was approved (enterprise data terms, region, retention).
2. A request path for new tools with a published turnaround time, so waiting is not slower than going around.
3. Data classes that may never enter any AI tool (credentials, regulated personal data, unreleased financials) and classes allowed only in approved tools.
4. Accounts: whether personal accounts on corporate devices are permitted. Verizon’s 67% figure suggests most organizations have not said.
5. Browser extensions and AI features inside approved SaaS products, which need their own review.
6. Coding agents and MCP servers: which agents are approved, whether MCP servers must come from an approved list, and what actions require human confirmation.
7. Human review of AI output before it reaches customers, code repositories or official records.
8. Monitoring and logging: what is recorded, who can see it, and how long it is kept.

NIST’s AI Risk Management Framework supports the inventory side of this. Its GOVERN 1.6 practice reads: “Mechanisms are in place to inventory AI systems and are resourced according to organizational risk priorities.” An acceptable use policy without an inventory has nothing to enforce.

Governing shadow AI without banning AI

Governing shadow AI means replacing unsanctioned tools with sanctioned ones that are at least as useful, then routing sanctioned traffic through one control point. Blocking alone fails because, as Samsung’s case and the Work Trend Index both suggest, employees who need AI find another device. The working pattern is discover, classify, sanction or block, route centrally, then log and review.

Figure 2: Blocking without offering an approved alternative pushes usage to personal devices, where no layer can see it.

As Figure 2 shows, the decision point has two exits, and the block exit points back to an approved tool. Three practices make the loop work:

• Sanction the tool people already use, on the right plan. Moving a team from a personal ChatGPT or Claude account to a business plan changes the data terms without changing the workflow, which is the fastest risk reduction available.
• Route sanctioned traffic through one gateway. A central AI gateway issues each user or team a key, applies budgets and rate limits, runs guardrails on prompts and responses, and logs every call. The Frontier Wire primer on what an AI gateway does explains the mechanics, and the guide to LLM cost control at the gateway covers the budget side.
• Make the approved path the easy path. Developers point coding agents at the gateway once; the comparison of AI gateways for Claude Code, Codex and Cursor lists how each gateway handles that setup.

Several gateways can hold that central role. LiteLLM’s proxy issues virtual keys that track spend and restrict model access. Cloudflare AI Gateway adds analytics, logging, caching, rate limiting and fallbacks for applications connected to it. For enterprise rollouts, a broader treatment of how to govern shadow AI usage across enterprises covers sequencing by team and risk tier.

The limit of every gateway is the same: it governs traffic that is configured to reach it. A desktop chat client or a browser tab that talks straight to its vendor bypasses the gateway entirely. That gap is where endpoint routing comes in.

Routing endpoint AI through a gateway with Bifrost Edge

Endpoint routing closes the gap between the traffic a gateway governs and the AI people actually use on their laptops. An agent on each machine intercepts AI traffic from desktop apps, browser AI and coding agents and sends it through the organization’s gateway, so the same keys, budgets, guardrails and logs apply without per-app configuration.

Bifrost is used here as the worked example because it publishes both halves of the pattern: an open-source AI gateway (GitHub, Apache 2.0) that serves 25+ providers and 10,000+ models through one OpenAI-compatible API, and Bifrost Edge, an endpoint agent that the product page lists as early access. The gateway adds 11 µs of overhead per request at 5,000 RPS on an AWS t3.xlarge in Bifrost’s published benchmark, which matters when every laptop’s AI traffic passes through it.

Figure 3: Edge enforces app and MCP decisions on the device; keys, budgets, guardrails and logs stay at the gateway.

The division of labor in Figure 3 follows the documentation:

• The gateway is the policy engine. Virtual keys carry model access, budgets and rate limits per user, team or customer. Built-in observability records inputs, outputs, tokens, cost and latency for every request, and content logging can be switched off. Guardrails cover secrets detection, PII and custom regex rules, and integrations such as AWS Bedrock Guardrails, Azure Content Safety, Google Model Armor and CrowdStrike AIDR.
• Edge extends that policy to the machine. The Edge overview describes routing “all AI traffic - chat apps, browser AI, coding agents, and MCP servers” through the organization’s Bifrost after a single SSO sign-in, with no base URLs to change. The supported applications list currently includes Claude Desktop, the ChatGPT desktop app, Cursor, Codex, Claude Code, Codex CLI, OpenCode, ChatGPT web and Claude web.
• App and MCP decisions are enforced on the device. Administrators allow or block AI apps centrally, and newly detected apps or MCP servers trigger an approval request. MCP governance builds a fleet-wide inventory of servers configured in Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex and Cursor, and a denied server “cannot be used, even by an app that had it configured before the policy existed.”
• Rollout uses existing device management. Edge deploys through MDM platforms including Jamf, Microsoft Intune, Kandji, Omnissa Workspace ONE and JumpCloud, on macOS, Windows and Linux, with no secrets in the managed configuration.

Enterprise tier. Guardrails, SSO and signed audit logs of administrative activity are part of Bifrost Enterprise.

The shadow AI governance resource for desktop and browser AI and the explainer on endpoint AI governance cover the endpoint model in more depth, and this analysis of shadow MCP focuses on the agent-tool side. Endpoint routing pairs with network inspection rather than replacing it: the network layer still sees traffic from devices that have no agent installed.

Shadow AI under GDPR and the EU AI Act

Shadow AI is a compliance problem mainly through data protection law, and secondarily through the EU AI Act. Personal data sent to an AI vendor with no processing agreement can breach GDPR. The AI Act asks organizations to support staff AI literacy now and, for high-risk use cases, imposes deployer duties from December 2027 under the amended timeline.

GDPR. When an employee pastes customer data into a personal AI account, the organization has engaged a processor without the contract GDPR Article 28 requires, has no record of the processing for Article 30, and may have transferred data outside the EEA without the safeguards Chapter V requires. None of that depends on whether the vendor trains on the data; the transfer itself is the issue.

EU AI Act. Article 4 originally required providers and deployers to ensure “a sufficient level of AI literacy” among staff. The Digital Omnibus on AI, published in the Official Journal on 24 July 2026 and in force from 27 July 2026, softened this to taking measures to support AI literacy, without guaranteeing a set competence level. The same amendment moved obligations for stand-alone high-risk systems listed in Annex III from 2 August 2026 to 2 December 2027. An employee who uses a general-purpose chatbot for an Annex III purpose, such as screening job candidates, can bring the organization into high-risk territory, where deployers have duties under Article 26, including assigning human oversight to competent people. Shadow use makes those duties impossible to meet, because the organization does not know the use is happening.

Standards. NIST’s AI RMF GOVERN 1.6 asks for an inventory of AI systems, and OWASP’s LLM02:2025 lists sensitive information disclosure among the top risks for LLM applications. Both treat visibility as the starting point. A sector view of the same obligations appears in this piece on AI governance in regulated industries.

A 90-day shadow AI program

A shadow AI program can reach a defensible baseline in about 90 days: one month to see what is in use, one month to sanction and route the main tools, and one month to enforce and measure. The sequence matters more than the dates, because enforcement before an approved alternative exists drives usage further out of sight.

The metric to track is the share of AI traffic that reaches providers through the governed path. IBM’s finding that only 29% of breached organizations audit for unsanctioned AI suggests that simply measuring it puts an organization ahead of most.

Limits of the evidence

The numbers in this piece come from three kinds of source, and each has a bias. Verizon’s figures come from DLP telemetry, which sees only organizations running that DLP service and only traffic it inspects. IBM’s figures come from Ponemon interviews at organizations that suffered a breach, so they describe breached organizations, not all organizations. The Work Trend Index is self-reported and dates from early 2024. None of the products named here were deployed or tested for this article; capabilities come from vendor documentation read in October 2026.

Two things would change the conclusions. If major AI vendors made business data terms the default on consumer plans, the training risk would shrink, though the processor and transfer questions would remain. If operating systems or browsers gained native controls for AI traffic, endpoint routing would become a platform feature rather than a separate agent. Until then, the gap the evidence describes is between AI that is used and AI that is seen, and closing it takes a published policy, an approved alternative for every common use, and enough detection layers that the governed path is also the one people take.