Shadow AI Detection: How It Actually Works

Shadow AI detection is the process of finding and identifying AI tools your employees use without IT approval, then attributing that use to real people and real data flows. It works by inspecting traffic and application activity for signals that reveal AI use, such as connections to AI services, login accounts, and the content moving into prompts and uploads. Good detection tells you who's using which AI tool, how much, and whether it's a personal or enterprise account.

That last part matters more than most teams expect. You can't govern what you can't see, and a lot of AI use is invisible to the tools most companies already run. This post is about the method: the signals, the detection approaches, and where each one sees or misses traffic.

If you're still mapping the basics, start with what is shadow AI and the risks of shadow AI. If you want a rundown of products, see shadow AI detection tools. This one stays on the "how."

TL;DR / Key takeaways

• Shadow AI detection finds unsanctioned AI use and ties it to users, apps, and data.
• The strongest signals: destination (which AI service), account type (personal vs. enterprise), process (browser vs. thick client), and content (what's in the prompt or upload).
• Detection approaches see different slices of traffic. DNS filtering sees domains. Cloud proxies see web sessions. Browser extensions see the browser only. On-device SSL inspection sees the full picture, including desktop apps.
• DNS-only and browser-only methods miss encrypted content and thick-client AI apps like ChatGPT Desktop, Claude Desktop, and IDE or CLI assistants.
• Good output isn't a raw log dump. It's a ranked view of top AI apps, top AI users, and how much they're using, exportable for people who don't live in a console.

What is shadow AI detection?

Shadow AI detection is the discovery side of AI governance. Before you can set a policy, you have to know what's actually happening. Employees adopt AI faster than IT can approve it. They paste customer data into a chatbot, connect a personal ChatGPT account, or install an AI coding assistant that talks to a model API you've never reviewed.

Detection answers three questions:

• Which AI tools are in use? Not just the sanctioned ones. All of them.
• Who's using them? Named users and groups, not anonymous IP addresses.
• How much, and with what data? Volume, account type, and whether sensitive content is moving.

Detection is step one. Policy and enforcement come after. But detection is where most programs stall, because the visibility gap is bigger than it looks.

What signals reveal shadow AI use?

AI traffic leaves fingerprints. The trick is knowing which signals to read and where to read them. There are four that matter most.

1. Destination. The most basic signal is where traffic goes. A connection to an AI service domain or model API endpoint tells you an AI tool is in play. This is the easiest signal to catch and the easiest to over-trust, because a domain alone doesn't tell you who, what, or how.

2. Account type. A personal ChatGPT login and an enterprise ChatGPT login hit similar endpoints but carry very different risk. Enterprise accounts have data-handling agreements. Personal accounts don't. Distinguishing the two is one of the highest-value signals in shadow AI detection, and it requires seeing inside the session, not just the domain.

3. Process and device context. Traffic from a browser tab looks different from traffic generated by a desktop app or a command-line tool. Knowing which process made the request separates "someone opened a chatbot in Chrome" from "an AI CLI is running on this developer's machine." That context only exists on the endpoint.

4. Content. The highest-stakes signal is what's actually in the prompt or the uploaded file. PII, PCI, PHI, source code, IP. Reading content requires decrypting the session and inspecting the payload, which is a much higher bar than logging a domain.

The more of these signals you capture, the more useful detection becomes. Catch only the destination and you get a list of domains. Catch all four and you get a story: this person, using this account, in this app, moved this data.

How do you detect shadow AI?

There are five common places to look for AI traffic. Each sees a different slice, and the differences are the whole point.

• DNS filtering. Watches domain lookups. Fast and lightweight. It sees that a device resolved an AI service domain, but it can't see inside the encrypted session, can't tell personal from enterprise accounts, and can't read content.
• Network or cloud proxy (SSE). Routes traffic through a data center for inspection. It can decrypt web sessions it sees, but only for traffic that's actually steered through it, and only while the user is on a path that hits the proxy. Off-network gaps and backhaul latency are the trade-offs.
• Browser extensions. Live inside the browser, so they see browser-based AI use in detail. The catch is right there in the name. If the AI tool isn't in the browser, the extension is blind.
• CASB / SSPM for OAuth-connected apps. Reads the app-to-app layer. When an employee connects a third-party AI app to your Microsoft 365 or Google tenant via OAuth, this surfaces the grant, the scopes, and the risk. It's essential for connected apps, but it doesn't see a user typing into a standalone chatbot.
• Endpoint / on-device inspection. Runs an agent on the device and inspects traffic locally, before it leaves. It sees every process, decrypts SSL on-device, and attributes activity to the user, whether the AI tool is a browser tab or a desktop app.

Here's how the approaches compare on what they see and what they miss.

Detection approach	What it sees	What it misses
DNS filtering	AI service domains resolved by a device	Encrypted content, account type, process, in-app activity
Network / cloud proxy	Web sessions steered through the proxy	Off-path and off-network traffic, thick-client apps not routed through it, adds backhaul latency
Browser extensions	Browser-based AI use in detail	Anything outside the browser: desktop apps, IDEs, CLIs, scripts
CASB / SSPM (OAuth)	Third-party AI apps connected to your tenant	Standalone chatbot use, prompts, and uploads outside the OAuth flow
On-device SSL inspection	Full traffic per process and user, browser and thick client, with content	Traffic on unmanaged devices without the agent; sessions with certificate pinning need bypass handling

No single approach is "wrong." They answer different questions. But if your goal is to see all shadow AI, the gaps in DNS-only and browser-only methods are the ones that hurt.

Why do DNS or browser-only tools miss shadow AI?

Two reasons: encryption and scope.

DNS filtering stops at the domain. It can tell you a device looked up an AI service, but modern AI traffic is encrypted end to end. The prompt, the account, the uploaded file, all of it is inside a TLS session that DNS never opens. So DNS can flag that AI is happening. It can't tell you a personal account leaked source code. That's the difference between a smoke alarm and a camera.

This isn't hypothetical. When Greylock Partners evaluated their old setup, DNS-only filtering was missing HTTPS traffic outright, which is one reason they moved off Cisco Umbrella to dope.security. DNS is a coarse signal by design.

Browser extensions have the opposite problem. They see inside the browser beautifully. But AI has moved out of the browser. ChatGPT Desktop, Claude Desktop, Copilot in the OS, AI assistants baked into IDEs, and model calls fired from a terminal all run outside any browser tab. An extension can't see a single one of them. As thick-client AI adoption grows, the browser-only blind spot grows with it.

Cloud proxies sit in the middle. They can decrypt what they inspect, but only for traffic that's actually routed through the data center, and backhauling that traffic adds latency and coverage gaps when users go off-network.

Why on-device SSL inspection sees what others miss

The reason thick-client AI apps slip past DNS and browser tools is that those tools watch the wrong layer. Detection has to happen where the traffic originates: on the device.

That's the model dope.security runs. The dope.SWG agent puts an on-device proxy directly on Mac and Windows endpoints and performs SSL inspection locally. Traffic flies direct to the internet instead of getting backhauled to a data center, which is where the "up to 4x performance over legacy SWGs" claim comes from. For detection, the important part is what "on-device" buys you.

Because inspection runs on the endpoint, it isn't limited to the browser and isn't limited to traffic that happens to be steered through a proxy. It sees the AI service a desktop app connects to. It can distinguish a personal ChatGPT or Claude login from an enterprise one. And with Dopamine DLP, it inspects the content of prompts and file uploads before they reach the model, with coverage across ChatGPT, Claude, Perplexity, Abacus, and Copilot.

One honest caveat. On-device inspection only covers devices where the agent is installed. Unmanaged or BYO devices without the agent are out of scope, same as any endpoint-based method. And some apps use certificate pinning, which can break inspection until an admin sets up a bypass. dope.security surfaces those SSL errors so admins can create bypasses in a few clicks, but it's a real step, not magic. Good detection is honest about its edges.

What does good shadow AI detection output look like?

Raw traffic logs aren't detection. They're homework. The output has to answer the "who, what, how much" question at a glance.

dope.security's approach lands in two places. First, Shadow IT discovery shows every SaaS and AI/ML app in use across the org, how much data is moving, and which users are logging in. That's the "there might be apps you didn't know about" moment.

Second, AI Usage Analytics turns that telemetry into a readable dashboard in dope.console. It surfaces:

• Top AI Applications, ranked by transactions and by number of users.
• Top AI Users, ranked by AI transaction volume and by distinct apps accessed.
• Applications-per-User, so you can spot the person quietly running six tools.
• Summary metrics: Total AI Requests, Active AI Users, and Distinct AI Apps Detected, over a rolling 7-day window.

There's also a branded PDF export, built for CISOs, IT managers, and compliance leads who need the picture without living in the console.

One thing to keep honest: sanctioned versus unsanctioned classification and direct policy enforcement from the analytics view are on the roadmap, not shipped today. The detection and visibility are here now. Enforcement runs through SWG policy and Cloud Application Control, which restricts access to approved enterprise tenants only. That's the three-layer model: discover, set policy, control the tenant.

FAQ

What is shadow AI detection? Shadow AI detection is the process of finding AI tools employees use without IT approval and attributing that use to specific users, apps, and data flows. It reveals who's using which AI tool, how much, and whether accounts are personal or enterprise.

How do you detect shadow AI? You inspect traffic and app activity for signals: the AI service being contacted, the account type, the process making the request, and the content in prompts or uploads. Detection methods include DNS filtering, cloud proxies, browser extensions, CASB/SSPM, and on-device SSL inspection. Each sees a different slice.

Why do DNS-only tools miss shadow AI? DNS filtering only sees domain lookups. It can flag that a device contacted an AI service, but it can't open the encrypted session to see the account, the prompt, or the uploaded file. It's a coarse signal.

Can shadow AI detection see desktop AI apps like ChatGPT Desktop or Claude Desktop? Browser extensions can't, because those apps run outside the browser. On-device inspection can, because it watches traffic per process on the endpoint, covering browsers and thick clients like desktop apps, IDE assistants, and CLI tools.

What's the difference between detecting personal and enterprise AI accounts? Personal and enterprise accounts often reach similar endpoints, so a domain alone won't tell them apart. Distinguishing them requires seeing inside the session. It matters because enterprise accounts carry data-handling agreements and personal accounts don't.

Is shadow AI detection the same as blocking AI? No. Detection is visibility: knowing what's happening. Blocking is enforcement. You detect first, then decide policy. dope.security separates the two, with AI Usage Analytics for detection and SWG policy plus Cloud Application Control for enforcement.

See your shadow AI

You can't govern AI you can't see. dope.security runs SSL inspection on-device, so it catches AI use in the browser and in desktop apps, ties it to real users, and shows you the top tools and top users in dope.console.

Want to see who's using personal AI across your fleet? Book a 20-minute demo or try dope.security free.