Shadow AI is any AI tool, model, agent or AI feature used inside an organization without review or approval from IT, security or legal: a personal ChatGPT account, a notetaker on every call, an MCP server on a developer laptop, an Agentforce bot nobody owns. The data handed over does not come back, and in 2026 the problem has grown from unsanctioned tools into unsanctioned agents with standing access to Drive, Slack, GitHub and Salesforce. Strac finds both with browser, endpoint, MCP, OAuth and audit-log evidence, joins each shadow agent to its identity, permissions, activity and sensitive data, redacts at the prompt, and sanctions or revokes in one click.
Shadow AI is any AI tool, model, agent or AI-powered feature that employees use for work without approval, review or oversight from IT, security, legal or data governance. A personal ChatGPT account, a browser extension that summarizes tickets, an AI notetaker silently joining calls, a coding assistant reading the repo, a Zapier automation posting to Slack on a shared login. It is shadow IT with a much shorter fuse, because the thing being handed over is not a login. It is your data.
In 2026 the definition has to stretch one more step. The shadow AI tool of 2023 was a chat tab. The shadow AI of 2026 is increasingly an agent: software that holds a standing OAuth grant, an API key or a human's browser session, decides its own next action, and keeps running when nobody is watching. That is why this guide treats shadow AI agents as a first-class category, and why Strac's answer has grown from discovery plus redaction into a full AI agent security platform.
This guide covers the definition, why the problem is compounding, real examples, the seven risk categories, how detection methods compare, the MCP and agent wave, a policy that holds, and how Strac discovers, governs and controls shadow AI and shadow AI agents.
The three questions people actually need answered:
That last point is the whole game. Shadow AI is not a discovery problem you solve once; it is an enforcement problem you solve continuously. A list of unsanctioned tools is obsolete the week a new one launches. A control that redacts PII, PHI, card data and secrets out of any prompt, in any AI tool, on any account, does not go stale. Neither does a graph that shows which agent can reach which sensitive data.
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. If you cannot answer "what is this agent, who owns it, what identity does it run as, what can it reach, and what did it do," it is a shadow AI agent.
Shadow AI grew faster than any prior Shadow IT wave. Four structural reasons:
1. Adoption is bottom-up. Employees 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. 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. They do not see the prompts, the file uploads or 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. Mid-market is similar in proportion, just smaller in absolute terms.
The same employee, three months apart, moves through three stages. Each stage changes what is exposed and which control works.
.webp)
contents:write on a repo, an MCP server with shell access, a Zapier flow on a shared CRM login, an Agentforce bot nobody ownsStage 1 is a data-handling problem. Stage 3 is an identity and permissions problem that happens to involve AI. Most shadow AI programs were built for stage 1. The rest of this guide covers all three.
The most common shadow AI tools are the famous ones: ChatGPT, Claude, Gemini, Copilot and Perplexity, used on personal accounts in the browser or through desktop apps. The riskier long tail is notetakers, coding assistants, AI extensions and agents. Every example below is a real pattern observed in customer shadow AI discovery scans (anonymized):
~/.ssh/id_rsa, .env files and browser cookie databases as context for routine prompts.When a shadow AI discovery scan is run against a typical mid-market company, the inventory looks something like this:
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 2023 Samsung incident, 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.
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 vendor read access to every email, Drive document and calendar entry, and the grant persists until manually revoked, even after the employee leaves. In Strac's agent inventory this is the most common way a shadow AI tool becomes a shadow AI agent.
6. Prompt injection and indirect attack surface. AI tools that read external content (web pages, emails, Slack messages, support tickets) are exposed to adversarial instructions hidden in that content. Every shadow AI tool with broad data access is a new injection target, and an agent with write or execute capability is a target that can act.
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. 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 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 agent governance program. The row that should worry you is Reversible: shadow IT is a governance problem you can unwind, shadow AI is a disclosure you cannot take back.
The short answer to "can CASB detect shadow AI?" and "can EDR detect shadow AI?" is: partly. A CASB or secure web gateway sees traffic to AI domains it already knows and the sanctioned apps it brokers, but not a personal account on a home network, a tool that launched last week, or an agent acting through an OAuth grant. EDR sees AI desktop apps and processes running on a device, but it is built to catch malware, so it does not classify what data went into a prompt and it does not see the prompt in a browser tab. Traditional DLP watches email, uploads and egress. Shadow AI detection that holds up needs content-aware visibility in the browser and on the endpoint, joined with OAuth and audit-log evidence.
Most security teams start with network logs and find very little, because AI usage is browser-based, SaaS-embedded and OAuth-driven. Real shadow AI detection fuses five sources, ranked from highest signal to lowest:
1. Browser-level and endpoint discovery. A lightweight browser extension or an already-installed endpoint agent that observes domain visits, prompts typed, files uploaded, clipboard pastes and local agent processes. This is the only signal that captures what data is being submitted, not just which tools are in use, and the only one that sees the 17 of 41 shadow agents in the example at the top of this guide that never touched a provider API in their own name.
2. OAuth grant inventory. Pull every OAuth-authorized application across Google Workspace (users.tokens.list), Microsoft Entra ID, Slack and GitHub, and cross-reference against a maintained catalog of AI products. This catches the long tail (Otter, Fathom, Gong, Glean, Notion AI) that users authorized once and forgot.
3. SaaS audit log filtering. Google Workspace login and token audit logs, Microsoft 365 sign-in logs, Okta and Entra ID system logs, Slack admin logs and Salesforce Event Monitoring all reference AI tools used as authentication targets or connected apps. Filtered against an AI catalog, they surface every AI tool a user has signed into and every connected app acting through an API.
4. Egress / SWG logs. If the organization already runs Cloudflare Gateway, Zscaler or Netskope, its logs are useful. Most mid-market companies do not have one, which is why this method is fourth.
5. Expense and procurement signals. Ramp, Brex, Concur and corporate-card data show subscriptions that never went through procurement. Less timely, but useful for paid shadow AI that lives outside the SSO and SaaS log layer.
What each method catches, and what it misses:
Read the Misses column carefully, because it explains why shadow AI inventories are always out of date: every discovery method except the browser is blind to the free personal account, which is exactly where the problem is. Detection tells you what happened. Only the browser and endpoint layer can intervene before it does, and only that layer sees an agent that borrows a human's session instead of asking for its own credential.
A complete shadow AI view fuses all five into a single inventory with a decision per tool:
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 their local filesystem, Postgres, Slack, GitHub, AWS, Google Drive and browser sessions. Most run with no authentication, on localhost SSE transports, accessible to any process on the machine. A developer laptop with five running MCP servers is 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 no SaaS audit log 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. The discovery method is covered in depth in shadow MCP.
A real MCP server inventory looks like this: a mix of stdio and SSE transports, several inactive servers that are still installed, and a handful of high-risk servers exposing filesystem or database access:
Two MCP-specific risks deserve to be called out:
0.0.0.0:3001 is reachable from any network the laptop joins. 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. MCP is also the clearest example of the bigger shift, which is the next section.
A shadow AI agent is an AI agent or AI-enabled automation running inside your environment with real credentials that nobody registered, risk-assessed or owns. It is shadow AI with standing access and the ability to act. In the inventories we build, it takes five shapes:
drive.readonly or gmail.readonly. The AI client now acts on that user's behalf, continuously, against every file the user can open.Here is why this breaks the shadow AI programs most companies built. OAuth scanning and audit-log filtering are API-only methods. They see the grants and some of the bots, because those leave a record in a provider's admin API. They cannot see a local MCP server, an agent inside a human's browser session, or an automation on a shared login, because from the provider's point of view those are a human. In the example environment shown at the top of this guide, 17 of the 41 unsanctioned agents were found only by the endpoint or browser sensor. An API-only product would have reported 24 and called the inventory complete.
Three things in the shadow AI agents view at the top of this guide matter more than the counts:
client_id, and a reviewer should be able to disagree with it.client_id, Slack app restrict or uninstall) and otherwise generates the exact change and a console link. Block applies at the data layer, in the browser or on the endpoint, so the agent keeps running but stops receiving sensitive data. None of it requires write access on day one.The findings that come out of this view are the same ones that drive Strac's agent security program: an unsanctioned agent that can access sensitive data (High), an ownerless live agent or credential (High), a shared human credential used by an agent (Medium to High), and an agent that can read secrets and execute (Critical). Severity is computed from six visible factors (sensitivity, action capability, breadth, sanctioning, observed use, attribution confidence) so a CISO can defend it in an audit. For the full method, start with how to discover AI agents.
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.
Add agent rules, because tool tiers do not cover standing access. Four rules that hold up in practice: every agent has a named owner; any agent that can reach regulated data must be sanctioned; no single principal holds secrets access and execute capability; write, delete or admin permissions unused for 30 days are overprivilege and get narrowed. Preview each rule against the inventory before you enforce it, so you know how many owner requests and revocations it will generate.
Map controls to whichever frameworks you carry. A complete policy ties every control back to SOC 2 (CC1.4, CC6.1, CC9.2), ISO 27001 (A.5.19, A.5.23, A.8.16), ISO 42001 (clauses 8.2 to 8.4), NIST AI RMF, the EU AI Act (Articles 16, 26, 50), GDPR (Articles 28, 32, 35) and HIPAA. Be framework-agnostic in implementation and framework-specific in evidence: the single control "every AI tool and agent processing customer data is inventoried, owned, risk-assessed and tied to a DPA" produces evidence under all of them at once.
For a deeper template, see the AI Acceptable Use Policy template.
A mature shadow AI program produces four things, continuously:
Two numbers tell you whether the program is working: the percentage of agents with an accountable owner, and the median time from finding to remediation. The companies that get this right in 2026 will treat shadow AI as an always-on capability, the way they treat Shadow IT, vulnerability management and CSPM today. The broader program is covered in shadow AI governance.
Strac's approach to shadow AI is built around a single observation: discovery without prompt-level visibility is a dashboard, not a control. Knowing 18 AI tools are in use does not stop the customer record pasted into ChatGPT five minutes later. And knowing 187 agents exist does not tell you which 17 can reach sensitive data.
So Strac is built as an AI agent security platform that answers four questions for every AI tool, agent and automation it finds, and joins the answers in one graph: Agent → Principal → Permissions → Resources → Sensitive data.
The discovery layer under that graph is what Strac has run for years, and it is what makes the inventory honest:
Visibility, not surveillance. On the endpoint, Strac shows each AI service the fleet reaches, the app or browser that made the connection, the device and the user, and flags when sensitive data comes near an AI tool. It does this without reading a single prompt, and with no keystroke logs and no screenshots anywhere in the product. When you are ready to act, the same agent blocks sensitive files and uploads to unsanctioned tools.
Enforcement on every surface. Discovery tells you shadow AI exists. These controls decide what it can take with it:
Real-time prompt redaction. When an employee types a prompt into ChatGPT, Claude, Gemini or Copilot, Strac inspects it in the browser before it is sent. PII, PHI, PCI, secrets, source code and customer records are redacted inline. The user keeps the productivity; the sensitive data never leaves the browser. The same control applies to MCP tool calls, where request and response are both inspected.
Bounded remediation. Discovery credentials are separate from remediation credentials, so the platform deploys read-only. When you opt in per provider, Strac revokes a Google OAuth grant by client_id in one click, restricts or uninstalls a Slack app, generates the exact IAM policy delta for AWS, and recommends repo and permission narrowing for GitHub with a console link. Every option states what will change and whether it is reversible.
Framework-agnostic evidence. Every 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 the HIPAA Security Rule.
Strac deploys in under 10 minutes with no proxy and no network changes. The browser extension and endpoint agent are the only device footprint, and both are optional for OAuth-and-audit-only discovery.
Shadow AI is any AI tool, model, agent or AI feature 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, locally running MCP servers, and agents or automations running on borrowed credentials. If you cannot answer "who used what AI, with what data, when, and under whose authorization," it is shadow AI.
Shadow IT is unsanctioned SaaS, hardware and scripts, primarily a vendor and license management problem that you can unwind by revoking the account. Shadow AI is focused on AI tools and agents, with three risks shadow IT did not have: prompt-level data leakage that cannot be recalled, prompt injection, and the AI vendor acting as a third-party data processor whose retention and training behavior is opaque.
Shadow AI agents are AI agents and AI-enabled automations running with real credentials that nobody registered, risk-assessed or owns: an AI client with a standing OAuth grant to Drive, a local MCP server with shell access, a computer-use agent driving an employee's logged-in browser, a Zapier flow on a shared CRM login, or an Agentforce bot whose creator left the team. They differ from shadow AI tools in that they hold standing access and act without a human reviewing each step, so risk is measured by what the agent can reach and do rather than by what one person pasted.
With evidence from where the agent actually runs. An agent that drives a human's browser session or signs in with a shared login looks like a human in every provider audit log, so API-only discovery cannot see it. Strac's browser and endpoint sensors observe the agent process, the controlled tab, the tool call and the file lineage, correlate that with the provider's record of what the human account did, and label the attribution as correlated with its confidence factors shown. In a typical inventory that is how 17 of 41 unsanctioned agents are found.
Partly. A CASB sees traffic to known AI domains and sanctioned apps, and EDR sees AI apps and processes running on a device. Neither sees what data went into a prompt on a personal account, and neither sees an AI agent acting through an OAuth grant or a human's browser session. Shadow AI detection needs browser and endpoint DLP that understands content, joined with OAuth and audit-log evidence.
Most security teams answer "data leakage." The more accurate answer is standing access: an OAuth grant or agent credential that persists after the one-time paste. A single click can give an AI vendor or agent 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 and agent permissions alongside prompt content.
Blocking reliably fails. The tools are useful, employees are measured on output, and the alternative is one tab away on a personal device you do not manage. Organizations that ban AI outright mostly succeed in making shadow AI invisible rather than absent, and they get shadow AI agents on top. The approach that holds is to let people use AI, remove the sensitive data from the prompt (redact, warn or block per data class), and give every agent an owner and a scoped credential. If you do need to block a specific tool, see how to block ChatGPT at work.
Go deeper on every part of shadow AI, from detection to prevention to the agent layer:
The companies that treat shadow AI as a 2026 compliance checkbox will spend 2027 explaining a leaked customer dataset, or an agent that exported one, to a regulator. The companies that treat it as an always-on discovery, redaction and agent-governance capability, at the prompt level, across the SaaS estate, and into the MCP and agent surface, will be the ones still moving fast on AI without paying for it later.
Strac discovers every AI tool and agent in use across your company, resolves each agent's identity and permissions, joins it to the sensitive data it can reach, redacts sensitive data at the prompt and the tool call, and produces audit evidence mapped to SOC 2, ISO 42001, NIST AI RMF, GDPR and HIPAA, read-only on day one and in under 10 minutes to deploy.
👉 Book a demo and we will run the shadow AI agent inventory read-only against your own Google Workspace or Slack tenant on the call, and show you which agents only the endpoint can see.
.avif){kind=icon}
.gif)
