What is shadow AI?

What counts as shadow AI

Shadow AI is any use of an AI tool, model, agent, or AI feature for work that happens outside your organization's approval or outside its view. A personal ChatGPT account on a work laptop is shadow AI. So is a coding agent that a developer installed with npm, an MCP server added to a config file, a browser extension that summarizes every page it can read, and an open-weight model running on a data scientist's machine.

The unit is the use, not the product. If your company pays for ChatGPT Enterprise, a prompt sent from the company workspace falls under your contract and your admin console. The same prompt typed into a personal account on chatgpt.com, from the same browser, is shadow AI. Approval has two parts, the vendor and the account, and a vendor review only checks the first.

Shadow AI is rarely malicious. People reach for an unapproved tool because the approved one is missing, capped, or worse at the task, and that shapes how you respond.

Seven kinds of shadow AI, with examples

Most definitions stop at employees using ChatGPT without permission, which is one of seven kinds. The scenarios in the following sections are illustrative, not reports of specific incidents.

Personal accounts inside approved tools

Your company rolled out Claude to engineering. A developer also has a personal Max plan, and when the team seat hits a usage limit, they sign out of claude and sign back in with the personal account. The binary, hostname, and process don't change, but the session no longer reports to your organization or follows its admin settings.

The same pattern shows up with a second browser profile signed in to a personal ChatGPT account, or a Cursor install logged in to a team that isn't the company's. Vendor tenant controls exist for exactly this case: anthropic-allowed-org-ids for Claude, ChatGPT-Allowed-Workspace-Id for ChatGPT, plan-based routing for GitHub Copilot, and AllowedTeamId for Cursor. For how to apply each, see block personal AI accounts on work laptops.

AI features embedded in sanctioned SaaS

Your company approved Zoom years before it had an AI assistant. Zoom AI Companion can generate a meeting summary, and Zoom's documentation says account owners and admins can enable or disable meeting summaries for the account, groups, or users. If nobody reviewed that setting, a model your vendor review never covered summarizes a customer's escalation call.

Nobody installed anything, and the traffic goes to the same Zoom domains as before. Only the SaaS vendor's admin console shows this kind, so the control is a review of AI settings in every approved app, repeated when vendors ship features.

Desktop apps

A finance analyst installs the ChatGPT or Claude desktop app, signs in with a personal account, and drags in a forecast spreadsheet. Software inventory finds the app. Inspection is harder: apps that pin certificates or ship their own trust store tend to break under TLS inspection, so they often land on a proxy's bypass list, and from then on the proxy sees only that a connection happened.

Browser extensions

A recruiter installs an AI writing assistant from the Chrome Web Store. To rewrite text in any text box, it asks for access to data on every website the recruiter visits, including the applicant tracking system. Its requests leave from the browser process, so a network control attributes them to Chrome, and the data goes to a backend nobody reviewed.

CLI coding agents

A developer runs npm install -g @openai/codex or npm install -g @google/gemini-cli. Within minutes the agent is running shell commands with the developer's credentials and deciding on its own to open .env. The binary sits in a global npm prefix or the home directory, which most software inventories don't treat as an installed application, and its state lives in ~/.claude/, ~/.codex/, or ~/.gemini/.

Here shadow AI stops being only a data problem. A coding agent can also delete a branch, push to a remote, or call an API with your token. For where each coding agent keeps its account and MCP servers, see shadow AI coding agents. For the controls specific to agents, see coding agent security.

MCP servers

A developer wants their agent to answer questions about production data, so they add a community Postgres MCP server to ~/.cursor/mcp.json with a connection string for a read replica. Another adds a remote MCP server that authenticates to the company's Jira with OAuth. Neither went through review, and each gives an agent a tool it didn't have.

The OWASP MCP Top 10 lists this as MCP09:2025 Shadow MCP Servers, defined as "unapproved or unsupervised deployments of Model Context Protocol instances." Each client keeps its own list. Claude Code stores user and local servers in ~/.claude.json and project servers in .mcp.json (Claude Code docs), Codex uses [mcp_servers.NAME] tables in ~/.codex/config.toml (Codex docs), Gemini CLI uses the mcpServers key in ~/.gemini/settings.json (Gemini CLI docs), and Cursor uses ~/.cursor/mcp.json (Cursor docs). For how to restrict them, see restrict MCP servers in coding agents and rogue MCP server detection.

Local models

A data scientist installs Ollama, pulls an open-weight model, and runs a month of support transcripts through it to cluster complaints. According to the Ollama FAQ, Ollama binds 127.0.0.1 port 11434 by default and doesn't see prompts for models run locally.

No prompt leaves the laptop, so the risks are different. Nobody reviewed the model's license or provenance, and setting OLLAMA_HOST to listen on all interfaces exposes an unauthenticated model server to the network. A network control sees the model download and nothing after it.

Check one machine

On a developer's macOS or Linux machine, the following commands show which of these categories are present. They read configuration files instead of running each agent's mcp list command, because listing checks each server's health, and for a stdio server that means starting it.

1
# Agent state directories that exist for this user
2
ls -d ~/.claude ~/.codex ~/.gemini ~/.cursor 2>/dev/null
3

4
# MCP servers each coding agent will load
5
jq '.mcpServers // {} | keys' ~/.claude.json
6
grep -E '^\[mcp_servers\.' ~/.codex/config.toml
7
jq '.mcpServers // {} | keys' ~/.gemini/settings.json ~/.cursor/mcp.json
8

9
# Local model server and loaded models
10
lsof -nP -iTCP:11434 -sTCP:LISTEN
11
ollama ps

These commands find only the tools you know to look for, so treat the output as a starting inventory, not a complete one. For each detection method across a fleet, and what each one misses, see how to detect shadow AI.

How is shadow AI different from shadow IT?

Shadow IT is technology used without IT's approval: a team's own Trello board, a personal Dropbox, a server under a desk. Shadow AI is a subset of it with the same root cause, a tool that does the job better than the approved one. Four differences change which controls work.

The data leaves in the prompt. Shadow IT risk usually accumulates in an unapproved store. With AI, using the tool is the transfer: one paste of source code moves it to a third party under whatever terms that account carries, and there's no folder to audit afterward. Consumer and business tiers of one AI service often carry different retention and training terms, so the account matters as much as the vendor.

Agents act, not only read. A shadow SaaS app holds data. A coding agent holds the developer's shell, credentials, and Git remote, and an MCP server gives it more. The incident you plan for includes a destructive command or an API call made with your token, not only disclosure.

AI ships inside apps you already approved. Shadow IT starts when someone signs up for something. Shadow AI often starts when a vendor turns on a feature in a product your procurement team reviewed before the feature existed. Your vendor inventory says "approved," and it's describing a different product.

The same domain carries personal and company accounts. This existed for Google Drive and Dropbox, and CASBs answered it with tenant restrictions. For AI it's the default: claude.ai and chatgpt.com serve personal and enterprise accounts from the same hostnames, and so do the API endpoints the CLIs use. A domain blocklist can't express "company account allowed, personal account refused," and a domain allowlist lets both through.

Which controls see which kind of shadow AI?

No single control covers all seven kinds. The following matrix records what each detection layer sees for each kind. "Sees" means the layer identifies the use and who did it. "Partial" means it sees some of it, or sees it without attribution. "Misses" means the layer has no view of it. Network, browser, endpoint, and hook layers can usually block what they see; MDM inventory and the identity provider mostly report.

The rows for coding agents and MCP servers are where browser and identity controls go dark, because nothing happens in a browser and a CLI signed in with an API key never touches your identity provider. The row for embedded SaaS features is where every network and endpoint layer goes dark. For the products at each layer and what each one documents seeing, see shadow AI detection tools.

The network columns also have limits the matrix can't show. HTTP/3 runs over QUIC on UDP, and Zscaler's own guidance is to block QUIC so browsers fall back to TCP, where inspection works. Encrypted Client Hello (RFC 9849) encrypts the server name in the TLS handshake, which every control that reads the ClientHello relies on. A laptop on a phone's personal hotspot skips any control enforced on the office network. Vendor documentation cited on this page was reviewed on November 3, 2026.

What are the risks of shadow AI?

The incident with the clearest primary reporting is Samsung's. On March 30, 2023, Economist Korea reported that Samsung's semiconductor division had allowed ChatGPT from March 11, and that three incidents followed. Two employees entered the full source code of internal programs, one for a semiconductor equipment measurement database and one for yield and defect analysis, to fix and optimize it. A third transcribed a meeting recording and entered the text to produce minutes. Samsung capped uploads at 1,024 bytes per question. On May 2, 2023, Bloomberg reported a memo banning generative AI on company-owned computers, tablets, and phones and on internal networks, and noted that 65% of respondents to an internal Samsung survey saw such services as a security risk.

Strictly, the use at Samsung was sanctioned at the time. Permission without a governed path produced the leak, and the ban that followed could only ask staff to keep company information off their personal devices.

For breach data, IBM's Cost of a Data Breach Report 2025, conducted by Ponemon Institute across 600 organizations that had breaches between March 2024 and February 2025, reported the following findings:

• One in five organizations reported a breach due to shadow AI.
• Organizations with high levels of shadow AI saw an average of $670,000 in higher breach costs than those with low levels or none.
• Shadow AI incidents compromised personally identifiable information in 65% of cases and intellectual property in 40%, against global averages of 53% and 33%.
• Only 37% of organizations had policies to manage AI or detect shadow AI.

IBM's 2026 press release doesn't report a shadow AI figure, so this page uses the 2025 numbers and cites only figures confirmed on the publisher's own page.

Other risks are less quantified but more specific. That account's terms, not your contract, govern data entered under a personal account, and you can't delete it. A coding agent outside your policy can read ~/.aws/credentials or run a destructive command with no rule in the way. An MCP server config often holds a database URL or API token in plain text, in a file the agent can read.

How do you reduce shadow AI without pushing people further into it?

Blocking is the reflex, and on its own it makes shadow AI worse. Arcjet's guide to stopping users sending PII to an LLM describes the failure: users who are refused don't stop having the problem. They open a personal ChatGPT account and paste the same document there, out of reach of your detector, your logs, and your data processing agreement. Measured as blocks per week, the control looks like it works, while the data it was meant to protect leaves through an account you can't see.

The responses that hold up start from the demand:

1. Provide an approved alternative that matches the reason for the shadow use. If developers switch to personal Claude accounts at a usage limit, the fix is capacity, not a firewall rule.
2. Make approval fast and visible. Answer requests in days, and publish which tools are approved and which data classes each may receive.
3. Block at the account, not the domain. Tenant controls refuse the personal account and keep the company account working.
4. Put guardrails on the approved agent instead of withholding it, such as an egress allowlist and a model allowlist.
5. Watch what happens after a block. If blocked sessions end instead of moving to an approved tool, people went somewhere you can't see.

Explain the rule where people meet it. A block page that links to the company workspace gives the person somewhere to go.

Where Arcjet fits

Arcjet covers the endpoint and coding agent rows of the matrix.

The Arcjet endpoint agent runs on managed macOS and Windows devices, deployed through your MDM, including Jamf. It observes each connection from the device to an AI service, identifies the signed app that made it, and attributes it to the person behind the local account. On macOS it's a Network Extension content filter with a root launchd service, so closing the menu bar app or logging out doesn't stop reporting. On Windows it's a LocalSystem service that reads the server name from the TLS ClientHello through the Packet Monitor API and correlates kernel network and process ETW events, with no kernel driver. Neither platform decrypts TLS, installs a root certificate, or reads prompts, so pinned apps and CLI agents keep working. That separates it from on-device secure web gateways and from SSE and CASB products that intercept TLS.

In the Arcjet Console, Discovery leads from People to Devices to AI usage, and Providers shows which people, devices, and apps reach each service. Counts are connections, not prompts or tokens. Shared, system, and unidentified local accounts show as Unknown user instead of inheriting the device owner. Endpoint provider policies set Allow or Block per provider for a group of devices, the agent blocks the connection on the device, and each decision appears in Arcjet Activity with the person, device, app, and provider.

For coding agents, Arcjet hooks enforce one policy in the hooks that Claude Code, GitHub Copilot, Cursor, OpenAI Codex, and Muse Code already fire, and decide each tool call, prompt, or model switch before it runs. Arcjet also polls the Claude Compliance API or accepts OpenTelemetry, which record without enforcing. The three sources prove different things: the endpoint connection shows an app reached a provider, the hook event shows what an agent ran and what the policy decided, and the Compliance API shows an organization account had a session. A hook event near a connection isn't proof they were the same request.

Arcjet is the wrong choice, or not enough, in these cases:

• A hostname can't separate a personal account from a company account on the same service. Use the vendor tenant controls for that.
• A local model with no network traffic isn't a connection, so the agent doesn't see inference.
• Devices without the agent are out of scope, including personal phones.
• A connection from an AI app isn't proof of an AI request. It can be an update check.
• The agent doesn't inspect prompt content in browser tabs. If what employees paste into chat is your main risk, browser DLP products such as Harmonic and Prompt Security inspect prompts.
• AI features inside sanctioned SaaS use the same hostnames as the approved app and need the vendor's admin settings.

For endpoint agent pricing and availability, book a demo.