Most security teams discover their shadow AI problem the same way: someone in legal forwards a screenshot, or a developer mentions in passing that the team has been pasting stack traces into a consumer chatbot for months. By the time the conversation reaches the security function, the behaviour is established, the data has already left, and the only honest answer to "how much of this is happening?" is "we don't know."
You almost certainly do know, though. The evidence is sitting in logs you already collect.
The perimeter still sees the traffic
Generative AI usage is unusual among shadow IT categories because it is overwhelmingly browser-based and overwhelmingly hosted on a small, well-known set of domains. A user pasting a contract into a hosted assistant produces an outbound HTTPS request to a destination that your forward proxy, your next-generation firewall, or your CASB has already recorded — with a timestamp, a username or source IP, a destination hostname, a request count and, critically, an uploaded byte count.
That last field is the one people overlook. Request counts tell you who is using a tool. Uploaded bytes tell you roughly how much material is leaving. A user with three hundred requests and forty kilobytes uploaded is asking questions. A user with thirty requests and eleven megabytes uploaded is feeding documents into a model.
You do not need new sensors to start. You need to point existing exports at a matching list.
Building the inventory
The mechanical part is straightforward and worth doing carefully.
Export the logs. Most proxies and CASBs export CSV or JSON. Pull a representative window — thirty days is usually enough to see weekly rhythm without drowning in volume. You want, at minimum: timestamp, user identity (or source IP if identity is not resolved), destination hostname, request count and bytes sent.
Match against known GenAI destinations. Maintain a list of assistant, model-provider and AI-feature hostnames, and match log destinations against it. The list needs maintenance: providers add subdomains, enterprise tiers use different hostnames from consumer tiers, and a growing share of AI usage is embedded inside SaaS products you already sanction rather than on a standalone assistant domain.
Aggregate rather than enumerate. A raw list of ten million log lines is not an inventory. Aggregate by destination and by user: total requests, distinct users, total uploaded bytes, first seen, last seen. That collapses to a table a security leader can read in a meeting.
Import as pending, not as approved. This is the discipline that separates an inventory from a shopping list. Every discovered destination enters the inventory in a pending state and stays there until someone with authority makes a decision. XAIGuard's shadow-AI ingestion does exactly this: matched destinations are aggregated by requests, users and uploaded bytes, then imported to the inventory as pending for approval.
Reading the results honestly
Two failure modes are common when the first inventory lands.
The first is treating volume as risk. The highest-request destination is often a coding assistant used by engineers for boilerplate — high traffic, low sensitivity. The riskiest entry may be a low-volume document-summarisation tool that three people in finance use for board material. Sort by sensitivity of the likely payload, not by request count alone.
The second is treating discovery as enforcement. An inventory tells you what happened. It does not stop anything. The gap between "we know" and "we control" is where most programmes stall for a quarter or more, because the assumed next step is a blanket block, the blanket block is politically unacceptable, and so nothing ships.
What to actually do with the inventory
A useful shadow-AI inventory drives four decisions, and they are worth separating.
Sanction. Some discovered tools are genuinely useful and reasonably governed. Move them to an approved state, and pair approval with a route through enforcement so that prompts to those tools are scored and redacted rather than merely permitted.
Replace. Where a consumer-tier tool is doing work that an enterprise-tier equivalent could do under contract, the fastest risk reduction is often a migration rather than a prohibition. People rarely resist a better-supported version of a tool they already like.
Restrict. Some destinations warrant blocking. Blocking works far better when it is narrow, explained and accompanied by a sanctioned alternative. A block list issued without an alternative teaches people to use their phones instead, which removes the traffic from your logs without removing it from your risk register.
Instrument. For everything else, the answer is neither approve nor block but observe with guardrails: let the traffic flow through a path where prompts are inspected, sensitive content is redacted before it leaves, and the decision is written to an audit record. This converts an unknown into a governed, evidenced flow.
Closing the loop between discovery and enforcement
The reason discovery-only programmes decay is that the inventory ages the moment it is produced. New tools appear weekly. Vendors add AI features to products your inventory already lists as non-AI. A one-off log analysis is a snapshot of a moving target.
Make ingestion recurring rather than heroic. Schedule the export, schedule the match, and let the inventory update itself so that "what AI are we using?" becomes a dashboard rather than a project. Then wire the approved entries into a control point — a PAC file that routes browser traffic through enforcement, a browser extension that inspects prompts locally before submission, or an API proxy for your own applications — so that the same list that describes usage also governs it.
The important shift is conceptual. Shadow AI is not a discrete incident to be cleaned up. It is a steady-state condition of any organisation whose people have browsers, and the goal is not elimination but visibility with control: knowing which tools are in use, which data classes reach them, and being able to prove to an auditor that the sensitive ones were redacted or blocked before they left.
Start with the logs you already have. The first inventory usually takes an afternoon, and it almost always changes the conversation from speculation to specifics.
If you would like to see what your own proxy or CASB logs reveal, talk to us — we will walk through a discovery run against your data and show you the inventory it produces.