Shadow AI is the use of any AI tool, model, agent, or AI-powered feature inside an organization without explicit approval, review, or oversight from IT, security, legal, or data governance.
It includes the obvious cases:
And the less obvious — and often more dangerous — cases:
The term is a direct extension of Shadow IT — the 2010s-era category for unsanctioned SaaS apps — applied to the AI wave that started with ChatGPT in late 2022. Shadow AI inherits every problem Shadow IT had, and adds three new ones: prompt-level data leakage, prompt injection, and the fact that the model itself is a third-party data processor whose retention and training behavior is often unclear.
The two phrases get used interchangeably. The cleanest working definition for security and compliance teams:
Shadow AI is any AI capability used by employees, contractors, or systems inside the company that has not been inventoried, risk-assessed, or governed under the organization's AI policy.
If you cannot answer "who used what AI tool, with what data, when, and under whose authorization" — it is Shadow AI.
Shadow AI grew faster than any prior Shadow IT wave. Four structural reasons:
1. Adoption is bottom-up, not top-down. Employees discover and adopt AI tools faster than security can review them. A tool goes from "I saw it on Twitter" to "embedded in our daily workflow" in under a week.
2. Free tiers eliminate the procurement gate. ChatGPT, Claude, Gemini, Perplexity, Midjourney, Cursor — every consumer-grade AI has a free or low-cost individual tier with no SSO, no admin console, and no audit logs from the customer's side.
3. The browser is the new perimeter, and most security teams don't own it. AI tools are accessed through chat.openai.com, claude.ai, gemini.google.com. Network firewalls see TLS-encrypted HTTPS to a known SaaS domain — not the prompts, not the file uploads, not the OAuth scopes granted.
4. AI is being shipped into every SaaS the company already pays for. Microsoft, Google, Slack, Notion, Atlassian, Salesforce, Zoom, GitHub — every major SaaS now has AI features that are "free" with the existing license. You don't have to install anything to be using AI. Often you have to opt out, and the opt-out is buried in admin settings.
The result: by Q1 2026, large enterprises that have done full Shadow AI discovery audits are typically finding 8–12× more AI tools in active use than their security team had on file. The number for mid-market is similar in proportion, just smaller in absolute terms.
Every example below is a real pattern observed in customer Shadow AI discovery scans (anonymized):
.webp)
~/.ssh/id_rsa, .env files, and browser cookie databases as context for routine code generation prompts.When a Shadow AI discovery scan is run against a typical mid-market company, the inventory looks something like this:
The tools at the top of the list are the famous ones. The ones that consistently surprise security teams are the long-tail entries below row 10 — niche AI products picked up by individual departments that nobody at the executive level had heard of.
Shadow AI is not one risk. It is seven distinct risk categories, and a complete program needs to address all of them.
1. Sensitive data exposure. PII, PHI, PCI, source code, customer lists, credentials, and trade secrets pasted into prompts. Free-tier consumer AI tools generally retain prompts and may use them for model improvement. Even paid enterprise tiers retain prompts for 30 days for abuse detection. The Samsung incident in 2023 — where engineers leaked semiconductor design code into ChatGPT — is the canonical example, but variations happen weekly inside most companies.
2. Compliance and regulatory violations. Shadow AI breaks every major framework:
3. Intellectual property leakage. Anything submitted to a free-tier AI may be retained, indexed, or used to train future models. For pre-release products, undisclosed financials, or proprietary code, this is a one-way leak that cannot be retracted.
4. Data residency and sovereignty violations. Most consumer AI tools route prompts through US-based infrastructure regardless of the user's location. EU and APAC employees pasting EU resident data into ChatGPT may trigger cross-border transfer obligations under GDPR, the UK Data Protection Act, and emerging APAC privacy laws.
5. OAuth and over-permissioned grants. Often the most under-appreciated risk. An employee installs an AI app from the Google Workspace Marketplace and clicks "Allow." That single click can grant the AI vendor read access to every email, every Drive document, and every calendar entry. The grant persists indefinitely until manually revoked — even after the employee leaves.
6. Prompt injection and indirect attack surface. AI tools that read external content (web pages, emails, Slack messages, customer support tickets) are exposed to prompt injection — adversarial instructions hidden in content that hijack the AI to leak data, misclassify, or exfiltrate. Every Shadow AI tool with broad data access is a new injection target.
7. Audit trail gaps. When the IT team does not know a tool is in use, there are no logs. When something goes wrong — a leaked prompt, a customer complaint, a regulator's question — the company cannot reconstruct what happened. This is the deepest compliance failure, because the absence of logs alone is a finding under SOC 2, ISO 27001, and HITRUST.
A modern Shadow AI program needs to surface, in one view, which AI tools are creating risk in which category — at the tool level and at the user level:
Risk scoring should weight not just what AI tool is in use but what data has flowed into it, who the user is, and what permissions the AI tool has been granted in the rest of the SaaS estate.
These three terms collide constantly. The differences:
Shadow AI is the discovery and remediation layer. AI governance is the policy and lifecycle layer above it. You cannot govern what you have not discovered, which is why Shadow AI detection is the prerequisite for any serious AI governance program.
For the broader landscape of policies and frameworks that sit above Shadow AI detection, see the AI Governance Framework and AI Governance Policy guides.
Most security teams start with network logs and find very little. The reason: AI usage is browser-based, SaaS-embedded, and OAuth-driven, so the signal is not on the network. Real Shadow AI detection requires fusing five sources, ranked here from highest signal to lowest:
1. Browser-level discovery. A lightweight browser extension (or already-installed endpoint agent) that observes domain visits, session duration, prompts typed, files uploaded, and clipboard pastes into AI tools. This is the only signal that captures what data is being submitted, not just which tools are in use. It is the single most valuable source.
2. OAuth grant inventory. Pull the full list of OAuth-authorized applications across Google Workspace (users.tokens.list), Microsoft Entra ID (Enterprise Applications + delegated permissions), Slack (apps inventory), and GitHub (OAuth Apps). Cross-reference each authorized app against a maintained catalog of known AI products. This catches the long tail — Otter, Fathom, Gong, Glean, Notion AI, AI meeting notetakers — that pure browser monitoring would miss because users authorized them once and forgot.
3. SaaS audit log filtering. Google Workspace login activity logs, Microsoft 365 sign-in logs, Okta / Entra ID system logs, and Slack admin logs all contain references to AI tools used as authentication targets. Filtered against an AI domain catalog, these logs surface every AI tool a user has logged into via SSO.
4. Egress / SWG logs. If the organization already runs Cloudflare Gateway, Zscaler, Netskope, or another secure web gateway, its logs are gold for Shadow AI discovery. The catch: most mid-market companies do not have one, which is why this method is fourth and not first.
5. Expense and procurement signals. Ramp, Brex, Concur, and corporate-card data show personal-card and team-card subscriptions to AI tools that never went through procurement. Less timely than browser or OAuth signals, but useful for catching paid Shadow AI that lives entirely outside the SSO and SaaS log layer.
A complete Shadow AI dashboard fuses all five and presents a single inventory with prompt volume, data volume, top users, and per-tool risk:
Counts alone are not enough. The dashboard has to answer: which user, what data, which AI tool, what OAuth scopes — because that is the level at which remediation actually happens.
The 2026 expansion of Shadow AI is not another chatbot. It is agentic AI — language models that take actions on behalf of users via tool calls — and the most common transport for tool calls is the Model Context Protocol (MCP).
Engineers stand up local MCP servers on their laptops to connect Claude, Cursor, or other LLM clients to:
Most are running with no authentication, on localhost SSE transports, accessible to any process on the machine. A developer laptop with five running MCP servers is, in effect, an undocumented broker that can read ~/.ssh/id_rsa, .env files, browser cookie stores, and corporate Slack DMs — and stream that context into a remote LLM on every prompt.
This is invisible to traditional Shadow IT discovery. The agent is local, the LLM is in the cloud, and there is no SaaS audit log that records the tool invocations. Detection requires endpoint-level visibility into running MCP processes, their transport configuration, the tools they expose, and the data they have accessed.
A real MCP server inventory will look like this — a mix of stdio and SSE transports, several inactive servers (still installed, still capable of being re-activated), and a handful of high-risk servers exposing filesystem or database access:
Two MCP-specific risks deserve called out:
0.0.0.0:3001 is reachable from any network the laptop joins — the coffee shop Wi-Fi, the hotel network, a colleague's machine. Anyone on that network can invoke its tools.Treating MCP as a Shadow AI discovery problem — inventory, risk score, alert, remediate — is the right framing for the next 12 months.
Block-everything policies fail. Within two weeks, employees route around them by tethering to a phone hotspot, using a personal laptop, or finding an AI feature embedded in an already-approved SaaS. The pattern that actually works:
Tier the tools, not the people.
Always provide an approved alternative for every prohibited tool. Otherwise users go underground, and you lose the visibility you fought to gain.
Map controls to whichever frameworks you carry. A complete Shadow AI policy ties every control back to:
The policy should be framework-agnostic in implementation and framework-specific in evidence. The same control — "every AI tool processing customer data is inventoried, risk-assessed, and tied to a DPA" — produces evidence under SOC 2, ISO 42001, and GDPR simultaneously.
For a deeper template, see the AI Acceptable Use Policy template and the AI Governance Implementation guide.
Strac's approach to Shadow AI is built around a single observation: discovery without prompt-level visibility is a dashboard, not a control. Knowing 28 AI tools are in use does not stop the customer record that gets pasted into ChatGPT five minutes later.
Strac fuses three discovery sources and adds a real-time prompt-level redaction layer on top.
Discovery — three sources, agentless where possible:
Real-time prompt redaction. When an employee types a prompt into ChatGPT, Claude, Gemini, or Copilot, Strac inspects the prompt in the browser before it is sent. PII, PHI, PCI, secrets, source code, and customer records are redacted inline. The user gets the productivity benefit of the AI tool; the sensitive data never leaves the browser.
MCP server discovery. Strac extends the same approach to MCP. Endpoint signal surfaces every running MCP server, its transport configuration, the tools it exposes, and any high-risk file accesses (SSH keys, .env files, credential stores) — closing the agentic Shadow AI gap before it becomes the next Samsung incident.
Framework-agnostic evidence. Every Shadow AI finding maps to SOC 2 CC6.1, ISO 42001 8.x, NIST AI RMF Manage 4.1, EU AI Act Article 26, GDPR Article 28, and HIPAA Security Rule. The same Shadow AI inventory becomes audit evidence for whichever framework the company carries.
Coverage across the SaaS estate the AI Shadow problem is hiding inside:
Strac deploys in under 10 minutes, requires no proxy, no network changes, and no agent on every laptop — the browser extension is the only endpoint footprint, and it is optional for OAuth-only discovery.
A mature Shadow AI program produces four things, on a continuous basis:
The companies that get this right in 2026 will treat Shadow AI not as a one-time discovery exercise but as an always-on capability — the same way they treat Shadow IT, vulnerability management, and CSPM today.
What is Shadow AI in simple terms? Shadow AI is any AI tool used inside a company that the IT, security, or compliance team has not approved or inventoried. It includes free ChatGPT accounts, AI Chrome extensions, AI features auto-enabled inside SaaS like Notion or Slack, AI apps authorized via OAuth, and locally-running MCP servers. If you cannot answer "who used what AI, with what data, when, and under whose authorization" — it is Shadow AI.
What is the difference between Shadow AI and Shadow IT? Shadow IT is unsanctioned SaaS, hardware, and scripts — primarily a vendor and license management problem. Shadow AI is a strict subset focused on AI tools, with three risks Shadow IT did not have: prompt-level data leakage, prompt injection, and the AI vendor often acting as a third-party data processor whose retention and training behavior is opaque.
Is using ChatGPT at work Shadow AI?
It depends on the account. ChatGPT Enterprise, signed up under the company with SSO, no training on customer data, and a DPA is sanctioned AI. A personal gmail.com ChatGPT account used for work tasks is Shadow AI, even if the user pays for ChatGPT Plus.
How do I detect Shadow AI in my company? Use three signals together: a browser extension that observes prompts and AI domain visits, an OAuth grant scan across Google Workspace / M365 / Slack / GitHub, and audit log filtering against a known AI tool catalog. If you have a secure web gateway like Cloudflare or Zscaler, add its egress logs as a fourth source. Network DNS and firewall logs alone are insufficient — most AI usage is browser-based and looks like ordinary HTTPS to a known SaaS domain.
Can DNS filtering or firewalls stop Shadow AI?
Partially, and only briefly. Blocking chat.openai.com at the firewall stops one tool but does not stop the AI features inside Notion, Slack, Google Workspace, or Microsoft 365 — which are the same domains the company already has to allow. Within two weeks, employees switch to phone hotspots or use the AI features embedded in approved SaaS. DNS filtering should be one tool in a layered approach, never the only one.
What is the biggest risk of Shadow AI? Most security teams answer "data leakage." The more accurate answer is OAuth grants. A single click can give an AI vendor full read access to corporate Drive, Gmail, or Slack — and the grant persists indefinitely, including after the employee leaves. A complete Shadow AI program inventories OAuth grants alongside prompt content.
How does Shadow AI relate to SOC 2 compliance? Shadow AI breaks SOC 2 CC1.4 (vendor risk), CC6.1 (logical access), and CC9.2 (third-party risk) — all of which assume the company has a complete inventory of services processing data. Auditors in 2026 are starting to ask specifically: "What is your inventory of AI tools, who approved them, and what controls prevent sensitive data from being submitted?" An empty answer is a finding.
Should we just block ChatGPT? No. Blocking without providing an approved alternative drives usage underground — phone hotspots, personal laptops, and AI features inside SaaS the company cannot block. The pattern that works: tier AI tools as Approved / Conditional / Prohibited, give every team an approved alternative, and put a redaction layer in front of the conditional tier so productivity is preserved without sensitive data leaving the browser.
What is "shadow ai sorn security"? "SORN" refers to System of Records Notice — a US federal Privacy Act concept. Shadow AI in a SORN context means AI tools or agents that process records covered by a System of Records Notice without being declared in that notice. Federal agencies and federal contractors face direct Privacy Act exposure if Shadow AI is processing covered records.
How does Strac detect Shadow AI without an agent on every laptop? Strac's primary detection is agentless — OAuth grant scanning and SaaS audit log enrichment across Google Workspace, Microsoft 365, Slack, GitHub, and other connected SaaS surfaces 70–80% of Shadow AI without any endpoint footprint. The Strac browser extension adds prompt-level visibility (what data is being typed into AI tools) and is the only way to enforce real-time redaction at the prompt — but it is opt-in and incremental on top of the agentless layer.
The companies that treat Shadow AI as a 2026 compliance checkbox will spend 2027 explaining a leaked customer dataset to a regulator. The companies that treat it as an always-on discovery and redaction capability — at the prompt level, across the SaaS estate, and into the new MCP surface — will be the ones still moving fast on AI without paying for it later.
Strac discovers every AI tool in use across your company, scores each one, redacts sensitive data at the prompt level, and produces audit evidence mapped to SOC 2, ISO 42001, NIST AI RMF, GDPR, and HIPAA — all in under 10 minutes to deploy.
.avif){kind=icon}
.gif)
