Shadow AI Detection: Why Your Current Tools Miss It

Shadow AI is any AI tool your people use without IT knowing: a personal ChatGPT account, a free document summarizer, an AI feature buried inside a SaaS app, or an IDE copilot wired to a Model Context Protocol server. You cannot detect it from DNS logs or a browser extension, because the traffic is encrypted and half of it never opens a browser. Real detection means inspecting traffic on the device, across every egress path. dope.security does exactly that.

Every security leader now assumes shadow AI exists in their org. They are right. The hard part is not believing it, it is seeing it, because the popular detection methods each have a blind spot big enough to drive a data breach through. This post explains what shadow AI actually is, why the usual tools miss it, and what detection has to do to be worth anything.

What is shadow AI?

Shadow AI is the unsanctioned use of AI tools with company data. It is the marketing analyst pasting a customer list into a personal chatbot to write segments, the developer piping a private repo through an AI code assistant, the finance team uploading a forecast to a free summarizer. Some of it happens in a browser tab. A lot of it does not: desktop apps, command-line tools, API calls, and MCP servers all send data to a model without a URL you can watch. That range is why shadow AI is harder to find than shadow SaaS ever was.

Why is shadow AI so hard to detect?

Because the signals most tools rely on are the wrong signals. Roughly 95% of web traffic is encrypted, so anything that reads DNS queries or metadata sees a destination, not the action. It can tell you someone reached a domain. It cannot tell you they uploaded a spreadsheet, which account they used, or whether the data was sensitive. And any tool anchored to the browser is blind the moment AI moves to a desktop client or an IDE. Detection that depends on a single vantage point misses whatever happens everywhere else.

The detection methods that fall short

Three approaches dominate, and each leaves a gap.

DNS logging tells you a device resolved a known AI domain. That is a start and nothing more. It cannot distinguish a corporate tenant from a personal login on the same domain, cannot see the payload, and cannot see AI features embedded inside apps on other domains. Cisco's own documentation confirms that DNS-layer Umbrella cannot do tenant control at all, and that real inspection requires the proxy plus SSL decryption [Documented]. A DNS log is an attendance sheet, not a security control.

CASB API scanning connects to your sanctioned tenants and inventories what is inside them. Useful for governance of apps you already know about, useless for discovery of the ones you do not, because it only sees the tenants you have connected. Shadow AI is by definition outside those.

Browser extensions and isolation can watch what happens in the tab, including copy and paste. But their controls live in the browser, so they miss API-based AI, IDE copilots, and desktop agents entirely. Menlo's AI controls, for example, are architecturally bound to the browser, so anything outside it goes unseen [Documented]. If your developers use AI where they work, in the editor, browser-only detection never sees it.

Detection method	Sees	Misses	dope.security
DNS logging	Domains resolved	Payload, tenant, embedded AI, non-browser traffic	Inspects decrypted traffic on the device
CASB API scan	Inside connected tenants	Any unsanctioned or unknown tool	Discovers unsanctioned tools by their real traffic
Browser extension / isolation	Activity in the tab	Desktop apps, IDE copilots, API, MCP	Covers every egress path, not just the browser
On-device inspection (dope.security)	Real usage, account, and data across all paths	Nothing in the paths above	The recommended approach

The pattern: single-vantage methods each miss a different slice. Detection at the device is the only spot that sees them all.

What real shadow AI detection requires

To detect shadow AI in a way you can act on, you need three things at once. You need to inspect the actual traffic, decrypted, so you see the action and not just the destination. You need to do it across every egress path on the device, so desktop and IDE and API traffic count, not only the browser. And you need to tie it to identity and tenant, so you can tell the corporate account from the personal one on the same domain. Miss any one of those and your inventory has a hole in it.

dope.security runs a lightweight agent on the device and inspects SSL traffic there. That location is the whole advantage: it sees what actually left, from which app, under which account, including Model Context Protocol traffic that browser and DNS tools never register. This is the discovery layer of AI governance, the first of three. If you want the full picture of how discovery, policy, and tenant control fit together, the deeper guide on controlling personal versus corporate ChatGPT and the write-up on stopping sensitive uploads to AI show the next steps.

What risks does shadow AI actually create?

Shadow AI is not a compliance abstraction, it is a set of concrete exposures. The first is data leakage: sensitive customer records, source code, or financials pasted into a tool that may log the input or train on it. Once that data leaves, you cannot recall it, and you often cannot even prove what left. The second is regulatory: in healthcare, finance, and biotech, moving protected data into an unsanctioned service can breach obligations you are audited against, and "we did not know it was happening" is not a defense.

The third risk is quieter and growing fast: Model Context Protocol servers and IDE copilots that wire company systems directly to a model. These can read repositories, ticketing systems, and internal data, and they rarely touch a browser, so the tools most companies rely on never see them. The fourth is simple sprawl: dozens of overlapping AI subscriptions bought on personal cards, none inventoried, each its own small data-exit. You cannot manage, budget for, or secure what you have never seen, which is why detection is the foundation the rest of the program sits on.

A step-by-step shadow AI detection process

Detection works best as a repeatable process, not a one-off scan. Start by putting inspection where the traffic originates, on the device, so encrypted sessions and non-browser paths are in scope from day one. Next, classify what you find by tool, by account (corporate versus personal), and by the sensitivity of the data moving, so the inventory is actionable rather than just a list of domains. Then rank by risk: a personal chatbot receiving customer data outranks a sanctioned tool used correctly.

From there, feed detection straight into policy instead of filing a report. Allow the sanctioned, warn the questionable, block the personal accounts, and route DLP at your most sensitive data classes. Finally, keep it running continuously, because the AI landscape changes weekly and a point-in-time audit is stale the day after you run it. dope.security does this loop in one place: discovery, classification, policy, and control from a single on-device agent and console.

Shadow AI detection versus shadow IT discovery

Shadow IT discovery, finding the unsanctioned SaaS apps in use, has been a category for years, and many tools do it by reading logs or connecting to sanctioned tenants. Shadow AI detection is harder for two reasons. AI usage is often a feature inside an app you already sanctioned, not a separate app, so app-level discovery misses it. And AI moves data through prompts and API calls and MCP servers that a SaaS-discovery tool was never built to inspect. Treating shadow AI as just another shadow IT problem is why so many programs think they have coverage they do not. Detecting it takes payload-level inspection at the device, which is exactly the vantage point most legacy discovery tools lack.

From detection to control

Detection is worthless if all it produces is a report you read after the data is gone. The point of seeing shadow AI is to do something in the same motion: allow the sanctioned tool, warn on the risky one, block the personal account, and catch sensitive data before it reaches any of them. That last part is DLP, and it has to read the prompt, not just the file. Dopamine DLP inspects prompts and uploads on the device with zero-retention APIs, so you enforce without keeping a copy of the data you are trying to protect. The signal it keys on for tenant control is explained in our ChatGPT workspace ID post.

Who owns shadow AI detection?

Shadow AI detection tends to fall between chairs. Security owns risk, IT owns the endpoints and the SaaS estate, and the data or privacy office owns the compliance exposure, so it is easy for each to assume another has it covered while none actually does. The practical answer is that whoever owns endpoint and web security should own detection, because that is where the only complete vantage point exists. If discovery lives with the team that also sets web policy and runs DLP, detection flows straight into action instead of becoming a report that gets emailed around.

That single-owner model is easier when the tooling is unified. When discovery, policy, and DLP live in separate products owned by separate teams, the handoffs are where shadow AI slips through. dope.security keeps all three in one console, so one owner can see the usage, decide the policy, and enforce it without a cross-team ticket chain. The result is faster response and fewer gaps between "we detected it" and "we did something about it."

Why dope.security detects what others cannot

The reason is architectural, not a feature checkbox. Because inspection runs on the endpoint instead of a backhauled proxy, dope.security sees the traffic at the source, before it flies direct to its destination. There is no dependency on a browser being open, no dependency on a tenant being pre-connected, and no dependency on a domain being on a known list. It is one agent, under 100 MB of RAM, one console, and it discovers, sets policy, and controls the tenant in the same place. A top-tier venture firm and a Fortune 100 both run it precisely because it surfaces the AI and MCP usage their old tools could not (see how Fly Direct works).

To restate the thesis: you cannot detect shadow AI from a DNS log or a browser extension. The traffic is encrypted and half of it never touches a browser. Detection that matters happens on the device, across every path, tied to identity, and it flows straight into control. That is where dope.security starts, and it is why the shadow stops being shadow.

Want to see what AI your people are actually using? Book a 20-minute demo or start a free trial of dope.SWG.

Frequently Asked Questions

How do I detect shadow AI in my organization?

Inspect actual traffic on the device rather than relying on DNS logs or a browser extension, because most AI traffic is encrypted and much of it never opens a browser. dope.security runs an on-device agent that surfaces which AI tools are used, under which account, across desktop apps, APIs, and Model Context Protocol traffic.

Can DNS logs detect shadow AI?

Only crudely. DNS logs show that a device reached a known AI domain, but not the account used, the data sent, or AI features embedded in other apps. Cisco's own documentation confirms DNS-layer tools cannot do tenant control and need the proxy plus SSL decryption for real inspection.

Why do browser-based tools miss shadow AI?

Because their controls live in the browser, so they cannot see desktop AI apps, IDE copilots, command-line tools, or API and MCP traffic. Developers in particular use AI inside the editor, which browser-only detection never registers. dope.security inspects every egress path on the device.

Is shadow AI detection the same as blocking AI?

No. Detection is discovery, the first layer; blocking is a policy action. Good practice is to discover usage, then allow sanctioned tools, warn on risky ones, and block personal accounts, while DLP catches sensitive data in prompts. dope.security does discovery, policy, and tenant control from one console.

Does detecting shadow AI mean storing our prompts?

It should not. Detection identifies usage, and any data inspection that follows should be zero-retention. Dopamine DLP classifies prompts and uploads through zero-retention APIs, so nothing is stored or used for training. It is covered by US Patent 12,464,023.

Can shadow AI detection see Model Context Protocol traffic?

Only if it inspects at the device across all egress paths, which most tools do not. MCP traffic often bypasses the browser entirely. dope.security surfaces AI and MCP usage because it inspects on the endpoint rather than depending on a browser session or a DNS lookup.