Shadow AI Discovery: A Buyer's Guide to Finding What Is Already in Use

The question here is an inventory question: which AI tools are people in this organisation using, and which of them did anyone approve?

It sounds like the data-loss question and it is not. That one asks whether something sensitive left. This one asks what exists, which has to be answered first — you cannot write policy for tools you have not found.

Who asks it, and when

Usually IT or security, triggered by a procurement review, a SOC 2 or ISO cycle, or a leadership question that starts 'how many AI tools are we actually paying for'. Finance shows up faster than people expect, because the answer usually includes a number of individual subscriptions nobody consolidated.

What the tools actually do

• Watch network traffic for known AI service endpoints and attribute them to users.
• Maintain a catalogue of AI applications with risk ratings, so a new one is recognised rather than appearing as an unknown domain.
• Report usage over time: which tools, which departments, growing or shrinking.
• Feed the result into policy — allow, block, or route to an approved equivalent.

The same platforms serve this as the DLP category — Netskope, Zscaler, Purview — because both are answered from the same vantage point. CASB and SSE tooling you already run may cover most of it before you buy anything.

How to evaluate one

• How is a tool detected — by domain, by certificate, by an agent on the endpoint? Domain lists age badly; anything launched last month is invisible until the catalogue catches up.
• What happens off the corporate network? A developer on home wifi with a personal subscription is exactly the case you are trying to find, and it is the case most likely to be missed.
• Does it attribute usage to a person, or only to an address? An inventory you cannot act on is a report, not a control.
• Can it see CLI tools, or only browser traffic? Terminal agents are a growing share of engineering AI usage and they do not look like a web app.

The trap in this category

A discovery report is the most convincing artefact in this entire space, because absence is invisible. Nothing on the screen says 'and here is the AI usage that did not come through here'.

There is a cheap sanity check. Take the number of distinct AI tools the report shows for the engineering department, then ask ten engineers what they used this week. If the second list is longer, you now know the size of the gap — and you would not have learned it from the dashboard.

What it will not cover

Discovery tells you a tool is in use. It does not tell you what was done with it, and cannot: the content of an AI coding session lives in files on the developer's machine, in a format specific to that tool, deleted on that tool's own schedule.

That distinction matters most in the case discovery is best at surfacing. You learn that eleven engineers are running Claude Code. The next question from anyone senior is what they built with it — and the honest answer, unless something is capturing it, is that nobody knows and the transcripts older than thirty days are already gone.

The sequencing question

Do this one early, because it is cheap if you already run an SSE and because every other category's scoping depends on it. Then decide what the inventory obliges you to do: policy on what people send is the data-loss category, and a record of what the tools produced is the provenance category.

Finding the tools is the easy half. The half that keeps getting deferred is the record of what they did, and it is the one with a deletion timer running against it.