Your security stack can't see Shadow AI

What is Shadow AI, exactly?

Shadow AI is any use of an AI tool, model, or agent inside an organisation that is not visible to security and IT. The category covers more than "employees pasting things into ChatGPT". It includes browser-embedded assistants (Notion AI, Gemini in Workspace, Copilot in Edge), IDE plugins (Cursor, Continue, GitHub Copilot Chat), native desktop apps (Claude Desktop, ChatGPT Desktop), agentic tools that call MCP servers and execute actions, and embedded AI features inside SaaS that are turned on by default.

The McKinsey Global Survey on the State of AI 2025 reports that 88% of organisations now use AI in at least one business function, up from 78% in 2024. That number reflects sanctioned use. The unsanctioned share is structurally invisible, which is the problem.

Why the existing security stack is blind

There are three layers most enterprises rely on for traffic visibility, and each one has a specific blind spot for AI.

CASB sees the SaaS, not the AI

Cloud Access Security Brokers identify which SaaS applications employees are using. They map a connection to api.openai.com to "OpenAI". What they cannot see is which model variant, which tool calls were embedded in the request, whether MCP servers were involved, or what was actually in the prompt. From a CASB's perspective, "ChatGPT" is one approved cloud application. From a security perspective, ChatGPT-with-web-search-plus-three-MCP-servers-plus-file-upload is a completely different threat profile.

DLP sees encrypted bytes, not prompts

Data Loss Prevention tools rely on inspecting payloads. AI traffic is HTTPS. Without a TLS-terminating proxy, the DLP sees nothing. With a TLS-terminating proxy, the DLP can read prompt content but only after every prompt has been routed through a centralised inspection point, which adds latency, requires per-user attribution, and creates a new exfiltration target. Most enterprises stop short of this for legal and operational reasons.

Firewalls see destinations, not intent

Network firewalls can block api.openai.com or generativelanguage.googleapis.com. The trade-off is binary: allow or block at the domain level. There is no built-in mechanism to allow ChatGPT for a customer-support team while blocking it for the legal department, or to allow OpenAI for chat but block its web-search tool. Domain-level blocking also fails the moment AI moves to a custom subdomain or to a self-hosted endpoint inside the corporate network.

Browser extensions see one browser

Browser-based AI security extensions (LayerX and similar) monitor what happens inside the browser they are installed in. They miss everything that happens in native apps, IDE plugins, or any browser the user spins up that does not have the extension. In a typical engineering team, that is most of the AI surface.

The consequence is that the modern AI traffic profile slips between every layer. The CASB knows there is OpenAI traffic. The DLP cannot read it. The firewall is asked to allow or block at the wrong granularity. The browser extension covers one of three or four AI surfaces.

The 2026 Shadow AI attack surface

Five categories of unmonitored AI traffic that sit outside the typical security stack today:

1. Browser-embedded assistants

Every major browser ships with at least one AI integration. Edge has Copilot, Chrome has Gemini, Arc has its own assistant, Brave is integrating Leo. Each one reads the page the user is on. None of them flag this to the security stack as "AI activity".

2. IDE plugins and coding agents

Cursor, Continue, GitHub Copilot Chat, Codeium, Claude Code, Aider. Most of them index the entire repository on first open. Many of them have tool-call capabilities (file write, shell execution, network) gated behind weak confirmation dialogs. The CVE record for 2025 includes CurXecute (CVE-2025-54135, CVSS 9.8) and a GitHub Copilot pull-request RCE (CVE-2025-53773, CVSS 9.6), both of which exploited indirect prompt injection through repository content.

3. Native AI desktop apps

Claude Desktop, ChatGPT Desktop, Gemini Desktop, plus a long tail of vendor-specific clients. These run outside the browser, so browser-based AI security tools do not see them. They authenticate independently of the corporate SSO. They often have file-system access.

4. MCP servers

Model Context Protocol turns LLM clients into orchestrators that can read Gmail, write to Jira, query Salesforce, execute shell commands. An employee installing an MCP server takes about ninety seconds and requires no IT approval. The blast radius is whatever the MCP server has access to, which is often "everything that user can read on every connected SaaS".

5. Embedded AI in SaaS

Notion AI, Slack AI, Linear AI, Loom AI, every CRM with "AI insights". These are turned on by default in many tenants and stream user data to the SaaS vendor's AI subprocessor, which is typically OpenAI or Anthropic. The data path is "your data → your SaaS vendor → their AI subprocessor → back". The CASB sees the first hop and stops looking.

What real Shadow AI visibility requires

Honest visibility has three properties.

It runs at the application layer on the endpoint. Network-level controls cannot tell ChatGPT-with-tool-X apart from ChatGPT-with-tool-Y. SaaS-level controls cannot see embedded AI subprocessors. Browser controls miss native apps. The only place where every AI request, regardless of tool or surface, is visible is on the device making the request, just before the OS hands the request to the network.

It identifies AI traffic, not just destinations. A list of known AI provider domains is the bare minimum and breaks the moment a self-hosted model or a new vendor appears. A real detector classifies traffic as AI or not, based on payload patterns, regardless of destination.

It exposes the granularity that matters. "Was the request to OpenAI" is not enough. The questions that matter are: which application made the request, which tools were declared in the request, was an MCP server involved, did the response include a tool call the local agent then executed. Anything coarser leaves the same blind spots that got us here.

This is exactly the architectural shift Patronus Protect is built around. An AI firewall at the network path on the endpoint, classifying every request in single-digit milliseconds, with visibility into MCP calls, tool calls, and the specific provider plus model in use, across every app, browser, IDE, and native client on the machine. No cloud routing, no per-user surveillance.

Comparison: where the existing stack fails and where on-device visibility helps

AI surface

CASB

DLP

Firewall

Browser ext.

On-device AI firewall

ChatGPT in browser

✓

partial

✓ (block all)

✓

✓

Cursor / Copilot in IDE

partial

✗

partial

✗

✓

Claude Desktop

✗

✗

partial

✗

✓

MCP server tool call

✗

✗

✗

✗

✓

LLM tool call inside req

✗

✗

✗

partial

✓

Self-hosted local LLM

✗

✗

✗

✗

✓

Embedded AI in SaaS

partial

✗

✗

✗

✓

What an honest Shadow AI inventory looks like in 2026

A concrete starting point that does not require buying anything new:

• Take five engineering and five non-engineering laptops. For two weeks, log every outbound HTTPS connection by destination, by process. Manual or scripted, both work.

• Cross-reference destinations with the published API endpoints of the major AI providers. OpenAI, Anthropic, Google, Mistral, Cohere, Hugging Face, and the long tail. You will find at least three to five providers that no one knew were in use.

• For each AI-active process, check whether it has shell or filesystem access. Cursor and Claude Desktop both do, by default. Document the blast radius.

• List the MCP servers configured on each machine. Most users will not be able to tell you. The configuration is usually a JSON file in the application's config directory.

• Inventory browser extensions across the team. AI-related extensions install themselves quietly through corporate browser sync; they are rarely audited.

The output of this exercise is a baseline. Whatever AI security tooling you eventually deploy has to be evaluated against whether it can see the surface the audit revealed.

Frequently asked questions

Is Shadow AI just a productivity-tools problem? No. The same pattern shows up in finance (analysts using personal ChatGPT for spreadsheet work with real customer data), legal (drafting in Claude before pasting into the official tool), HR (ChatGPT for screening). The exposure is whatever the user can read.

Can a TLS-terminating proxy solve this? Partially. A proxy gives you payload visibility for traffic that routes through it, at the cost of latency, per-user logging, and a new high-value target. It does not see traffic that bypasses the proxy (VPN, DoH, sideloaded apps), and it does not see local LLM activity at all.

What about agentic AI specifically? Agentic AI multiplies the problem. An autonomous agent with tool access takes actions the user did not directly approve. The relevant log is not "what the user typed" but "what tools the agent called". Tool-call visibility is the new audit primitive. Most security stacks do not have it.

How does an on-device approach handle privacy? Properly designed, it never logs prompt content by default. The visibility is at the level of process, destination, and tool-call metadata. No prompt payloads leave the device unless an explicit policy says so. This is the architectural posture of Patronus Protect.

Is this an enterprise-only problem? No. Solo developers and small teams are already targets, especially through MCP servers and IDE plugins. The Shadow AI surface scales down; the visibility tooling has to scale down with it.