What is shadow AI?

Why does shadow AI happen?

Shadow AI is a demand problem before it is a security problem. Employees discover that a chatbot drafts a proposal in minutes or that a coding assistant clears a backlog, and they start using it immediately, usually on a personal account with a personal email and sometimes a personal credit card. Procurement cycles, legal review, and security assessments move in quarters. Consumer AI signups move in seconds.

The scale is striking. The Microsoft and LinkedIn Work Trend Index (2024) found that 78% of AI users bring their own AI tools to work rather than waiting for a sanctioned option. The pattern spans every generation and every company size, which means shadow AI is not a fringe behavior by a few early adopters. It is the default way AI enters most organizations.

What are the risks of shadow AI?

The core issue is data exposure through channels the organization cannot see. When an employee pastes a customer list, a contract, or a codebase into a personal AI account, that data leaves the corporate boundary with no data loss prevention, no retention policy, and no audit trail. Consumer AI terms often permit the provider to train on submitted content, so the exposure can be permanent. Netskope's Cloud and Threat Report (2026) found that source code alone accounted for 42% of generative AI data policy violations, ahead of regulated data at 32%.

The financial impact is now measurable. IBM's Cost of a Data Breach Report (2025) found that 20% of studied organizations experienced a breach linked to shadow AI, and that those breaches cost an average of $670,000 more than other incidents. The same report found that 97% of organizations with an AI-related breach lacked proper AI access controls.

• Sensitive data pasted into consumer tools with no logging, retention control, or legal hold
• Personal accounts that survive offboarding, keeping company context after the employee leaves
• Unvetted browser extensions and AI agents granted OAuth access to mail, files, and calendars
• API keys and service credentials embedded in unsanctioned scripts and agent workflows
• Compliance gaps when regulated data crosses into tools that were never risk assessed

How do you discover shadow AI?

Surveys and self-reporting undercount shadow AI because employees know the tools are unapproved. Reliable discovery comes from observing real activity: what identities actually connect to, from where, and with which accounts. The signal is already present in systems most organizations run today.

• Network and DNS logs showing traffic to AI domains and API endpoints outside the sanctioned list
• OAuth grant records in the identity provider, where AI apps request scopes for mail, drive, and chat
• SaaS and CASB logs distinguishing personal-account logins from corporate SSO sessions on the same app
• Endpoint telemetry revealing AI desktop apps, CLI tools, and local agent runtimes
• Expense reports and virtual card statements surfacing paid AI subscriptions no one approved

Should you block shadow AI or steer it?

Blanket blocking rarely works. Employees route around blocks with personal devices, phone hotspots, and lesser-known tools, which pushes the same activity into channels with even less visibility. Blocking also signals that the organization is hostile to productivity gains that employees can see with their own eyes, so it corrodes trust in security along the way.

Steering treats demand as real and redirects it. That means offering sanctioned enterprise tiers with SSO, logging, and no-training contract terms, then making the sanctioned path faster and better than the personal one. It also means tiered policy: allow low-risk use broadly, require review for sensitive data classes, and reserve hard blocks for clear-cut cases like regulated data in consumer tools. The approach shows up in the data. Netskope's 2026 report found that personal-account usage of AI apps fell from 78% to 47% of AI users over a year, while organization-managed account usage climbed from 25% to 62%, evidence that users move willingly when a governed option exists.

Shadow AI and non-human identity

Shadow AI increasingly means more than employees chatting with a bot. It includes autonomous agents, unsanctioned MCP servers, and scripts wired to model APIs, each acting through its own service accounts and grants, and presenting API keys and OAuth tokens that no inventory tracks. A personal ChatGPT session exposes what one person pastes. An unsanctioned agent with a long-lived token can read, write, and act continuously across connected systems. That shifts shadow AI from a data hygiene issue into an identity governance issue, because every unapproved AI integration mints non-human identities that exist outside the organization's identity lifecycle.

What does a shadow AI incident look like?

The following is a composite assembled from patterns that recur across public incident reporting; it describes no single named company. A sales engineer at a 900-person software firm signs up for a free AI meeting assistant with a personal email address. The tool is genuinely useful, and to get transcripts of customer calls the engineer clicks through an OAuth consent screen granting the app read access to the corporate calendar and mailbox. The screen looks exactly like the consent phishing flow security teams train against, except this app is legitimate and the employee wants what it offers. The grant issues a refresh token, and from that moment corporate mail and meeting content flow to a third-party vendor continuously, not only while the engineer is in a meeting.

Nothing surfaces, because nothing in the sanctioned stack was touched. The app never appears in SSO dashboards; the signup was personal. Data loss prevention inspects nothing, because the vendor pulls content server to server through the mail platform's API rather than through the employee's browser. Eighteen months later the engineer resigns. Offboarding disables the SSO account, but the third-party grant and its refresh token survive, because deprovisioning only covered apps in the corporate catalog. What remains is a working credential to a corporate mailbox held entirely by an outside party. If that vendor is ever compromised, the attacker gets the exact outcome token theft describes, without ever touching the company, because the company never held the token.

When the grant finally surfaces in a quarterly OAuth review, incident response stalls on a question no one can answer: what did the vendor actually read? There are no vendor-side logs the company can access, no negotiated retention terms, and no way to scope exposure to specific messages. The report to legal ends up bounding the disclosure as everything the mailbox contained across eighteen months. That is the signature of a shadow AI incident: not a dramatic intrusion, but an unbounded exposure with no forensic floor.

How does shadow AI evade traditional controls?

Network blocking assumes unsanctioned tools live at distinct, known domains. AI tools break that assumption twice. They ride shared cloud and CDN infrastructure, so blocking at the domain level produces collateral damage or misses the target entirely. And the market moves faster than any deny list: blocking one model provider's API does nothing about the hundreds of wrapper apps built on top of it, and blocking a wrapper does nothing about the one that launches next week.

The endpoint picture is worse. Desktop AI apps, command-line tools, and locally hosted models never cross the web proxy at all. Developer laptops increasingly run local agent runtimes and MCP servers wired to real databases and repos through credentials that no MCP authentication layer mediates, and each new assistant an employee tries adds another runtime to the pile, compounding into AI agent sprawl that no inventory captures. Browser extensions add a third gap: they read page content after TLS decryption, so a secure web gateway never sees the data leave, a structural difference examined in enterprise browser versus SWG and SASE.

The deepest gap is identity. A personal login and a corporate SSO session to the same AI app are indistinguishable at the network layer: same domain, same TLS, same client. The only reliable discriminator is which identity authenticated and what it was granted, which is why shadow AI discovery keeps landing at the identity layer no matter which control was tried first.

How do you stand up a shadow AI program?

Discovery findings decay fast, because employees adopt new tools weekly. A workable program treats shadow AI as a permanent operating condition rather than a one-time audit, and sequences the work so visibility precedes enforcement:

• Baseline from identity signals first: pull 30 to 90 days of OAuth grants, IdP login records, DNS traffic, and expense data before announcing anything, so the picture reflects real behavior rather than what employees admit to.
• Rank findings by data exposure, not tool count: one agent holding mailbox and drive scopes outweighs fifty chat accounts. Score each finding by the scopes granted and the data classes reachable, with least privilege as the yardstick.
• Ship the sanctioned alternative before enforcing anything: an enterprise tier with SSO, logging, and no-training contract terms, provisioned in days. Enforcement without an alternative just teaches evasion.
• Publish tiered policy in plain language: what is allowed freely, what requires review, and what is banned outright, with examples employees actually recognize from their own workflows.
• Wire offboarding to revoke third-party OAuth grants and API keys, not just SSO accounts, moving AI integrations toward zero standing privileges so nothing survives the person who created it.
• Feed AI grants and agent activity into identity threat detection and response so an anomalous scope grant or a dormant token that suddenly wakes up raises an alert, not a quarterly finding.
• Re-run discovery on a schedule and report the trend: the metric that matters is the share of AI usage happening on governed identities, not the raw count of tools found this quarter.

What are the common mistakes in shadow AI programs?

Most shadow AI programs fail in predictable ways, and nearly all the failures share one root: treating a continuous behavior as a one-time project. The specific mistakes are worth naming because each one feels reasonable at the time.

• Treating discovery as a cleanup instead of a control: a single audit names forty tools, generates a remediation sprint, and never runs again. The census is stale within a month and the program has no way to know it.
• Blocking the ten most famous apps and declaring victory, while the long tail of wrappers, extensions, and personal accounts keeps growing into identity sprawl that no one is watching.
• Treating chat and agents as one risk class: a chatbot exposes what someone pastes, while an agent with write scopes exhibits excessive agency and can act on connected systems continuously. Policy that lumps them together either overblocks harmless chat or underprotects against autonomous action.
• Ignoring the credentials shadow AI mints: every unsanctioned integration creates API keys, tokens, and grants that outlive the experiment that created them, and nothing expires them by default.
• Making the sanctioned path slower than the shadow path: if the governed tool requires a ticket and three approvals, the personal account wins every time, regardless of policy.
• Punishing self-reporting: amnesty for employees who disclose the tools they already use is the cheapest discovery signal available. Discipline converts that signal into silence.

Frequently asked questions

Related terms