Shadow AI: what's really happening inside the firm

When a CISO walks into an AI committee meeting in 2026, the sentence they hear most often is: "We banned ChatGPT and Copilot." A few weeks later, when that same CISO investigates where employee output is actually going, they find a surprise — personal ChatGPT accounts, Cursor instances IT didn't know about, Notion AI, Gemini, Claude. The ban works at the level of formal policy; it doesn't work at the level of actual workflow.

We call this shadow AI: AI tools that aren't in the organisation's official AI registry, but are actively used by employees as part of daily work. SaaS discovery was solved in the early 2020s. AI discovery hasn't been solved yet. This piece explains why, how it should be solved, and what an honest AI governance picture actually looks like.

Why you don't see it

Traditional SaaS management tools cannot solve the AI problem because they look in the wrong place. Most CASB / SSPM tools draw from three sources:

Finance integrations — only contract-visible AI (e.g. ChatGPT Enterprise, Copilot for M365). Personal or team subscriptions bought on a corporate card don't appear in this report.
SSO logs — only AI apps that have been wired into SSO. A developer who signs into ChatGPT with a Google account never lands in the SSO log.
Network proxy / DLP — domain-level visibility exists, but you can't see which user, which device, which account type. And proxy/DLP inspects content. We don't believe in that.

All three share the same blind spot: they don't see what's actually happening on the endpoint. Not the IDE extension (Cursor, Copilot), not the CLI tool (ollama, Claude Code), not the personal-account browser session.

The four invisible layers of AI

AI usage in an organisation happens across three to four distinct layers. Each requires a different discovery method:

AI usage layers and the visibility IT / security teams have into each. Top layers (sanctioned corporate AI) are almost fully visible; as you descend — embedded AI, IDE extensions, local models — traditional tools go blind.

1. Browser-based AI (the most visible one)

ChatGPT.com, claude.ai, gemini.google.com, perplexity.ai, copilot.microsoft.com. A browser extension can see every visit; the account type (corporate SSO vs personal) and the page's target score (personal data / foreign / no SSO) can be captured. We track the action, not the content.

2. IDE-extension AI

GitHub Copilot, Cursor, Continue, Codeium. This category escapes classic SaaS management entirely — because these aren't SaaS, they're IDE extensions. Catching them requires scanning the installed-extension inventory on the endpoint.

3. CLI / local AI tools

ollama, llama.cpp, lm-studio, Claude Code, Cursor agent mode. Developers are now running local models — uncontrolled data flow begins here. Again, only endpoint discovery sees it.

4. Embedded AI inside suites

M365 Copilot, Notion AI, Slack AI, Zoom AI Companion, Adobe Firefly. These activate via opt-in inside an existing corporate subscription; one admin clicks once, IT never finds out. They don't show up in licence data because they aren't a new purchase.

The CenseCloud approach

We unify all four layers in one inventory. With browser extension + endpoint agent + IdP/finance signal correlation, you can answer all at once: which user, on which device, which AI tool, with which account type.

Seeing is not enough — manageable control is

Once the shadow AI inventory exists, the second trap is to assume "block" is the only available action. In practice that fails, because employees route around it. CenseCloud's AI governance page offers a four-tier control ladder:

Sanctioned — approved by IT/security, used with a corporate account. Risk score suppressed, usage monitored.
Monitored — not banned but watched. The user stays visible, no alert, but behaviour telemetry flows.
Conditional — conditional access (e.g. corporate account only, certain roles only). The browser extension warns on any session that violates the condition.
Blocked — last resort. The user gets a coaching screen explaining why, and pointing to the sanctioned alternative.

Higher rung, lighter intervention, greater user autonomy. The four-step grey zone between zero-tolerance blocking and unconditional access is where real governance actually lives.

This ladder makes real governance possible without falling into the binary of "ban / free for all".

Steps you can take this week

Build the list of known corporate AI contracts (M365 Copilot, ChatGPT Enterprise, Gemini Business, etc.). Add them to your "sanctioned" list.
Run an IDE-extension inventory scan across endpoints. See how many AI extensions are installed, how many have a corporate contract behind them.
For browser-side AI visits, collect the account-type signal (corporate SSO vs personal). Domain alone is not enough.
Before reaching for "block", create room for coaching and redirection — the answer to "why is the user using this tool" is sometimes "we need a new corporate subscription".

Conclusion: count first, then policy

"We banned AI" is now a meaningless sentence, because which AI is almost never an answered question. The right order is: first, inventory the four layers; second, tier the control; third, train the user. People who reverse this order live the same blind spot today on AI that they lived two years ago on SaaS.

CenseCloud builds this inventory from the endpoint up. See the Shadow AI solution page or the platform architecture for the full picture.

Shadow AI: what's actually happening inside the firm