How to Detect Shadow AI: A Practical Guide for IT and Security Teams

Shadow AI is detected at five layers: network and DNS, the browser, the endpoint, identity and OAuth grants, and the content of the prompt itself. No single layer sees all of it. DNS shows that an AI domain was reached but not which account or what data. Endpoint agents see desktop AI apps and clipboard content but not unmanaged devices. Identity review finds AI services holding access to company data that never touch an endpoint at all. A working detection programme combines at least two layers, chosen against where the organization’s actual risk sits.

This guide covers what each layer can and cannot see, why the gaps between them matter, and a checklist you can run against your own environment this week. It is a methods guide, not a product pitch — which tools implement which layer is a separate question, and worth asking only after you know which layer you need.

New to the topic? Start with what shadow AI is, then come back.

Why Detection Is Harder Than It Looks

Three properties of AI usage break the assumptions most security tooling was built on.

It looks like ordinary web browsing. A session with ChatGPT is TLS traffic to a popular domain. There is no installer, no procurement record, no unusual port, and no signature. From a network monitor’s perspective it is indistinguishable from reading a news site.

The corporate and personal versions are the same product. This is the property that defeats most controls. A personal ChatGPT account and a corporate one resolve the same domain, hit the same TLS endpoint, and render the same interface. Netskope Threat Labs found 60% of the enterprise population using personal SaaS genAI apps in May 2025, and Cyberhaven puts 32.3% of ChatGPT usage on personal accounts specifically. Any control that keys on the destination cannot separate the sanctioned use from the shadow use.

The risk is in the content, not the connection. Knowing someone opened an AI tool is a low-value signal. Knowing they pasted a customer table into it is an incident. Cyberhaven’s endpoint research puts sensitive data in 11% of what employees paste into ChatGPT and in 39.7% of AI interactions once prompts, pastes, and uploads are counted together. Detection that stops at the connection tells you almost nothing about exposure.

Gartner’s March–May 2025 survey of 302 cybersecurity leaders found 69% of organizations suspect or have evidence that employees are using prohibited public GenAI. “Suspect” is the operative word: the behaviour is assumed, the evidence usually is not there.

The Five Detection Layers

1. Network, DNS, and firewall

What it sees. Which AI domains were resolved and connected to, from which internal IP, and when. With TLS inspection, some request metadata. A DNS filter can also block categorized AI domains outright.

What it cannot see. Whether the session used a corporate or personal account — the same domain serves both. What was in the prompt. Any device on a phone hotspot, home network, or cellular connection. AI features embedded inside SaaS you already permit, because the traffic goes to the SaaS vendor’s own domain. New AI services until the category feed catches up.

Where it fits. The fastest control to deploy and the cheapest to run. Excellent as a first-week baseline and as a coarse policy signal. A poor last line, because everything above is a hole.

Practical note. Treat a DNS block as a policy statement rather than a security boundary. It communicates intent, catches the casual case, and generates the “why is this blocked?” conversations that surface what people actually need.

2. Browser

What it sees. Which AI sites are open, which browser extensions are installed and what permissions they hold, and — with an extension that inspects the page — the content typed or pasted into an AI interface. This is also the only practical layer for seeing AI-capable browser extensions, which are a genuine and under-monitored risk surface.

What it cannot see. Anything outside the browser: desktop AI applications, AI in IDEs, CLI tools calling model APIs. Browsers where your extension is not installed, including personal browsers on the same machine.

Where it fits. The best coverage-per-unit-of-deployment-effort in this list, especially on mixed-OS fleets where an endpoint agent is impractical. Enterprise browser policies (ExtensionInstallForcelist on Chrome and Edge) make an extension non-removable on managed devices.

Practical note. Enumerate installed extensions before you do anything else. It takes an afternoon, needs no new tooling on managed Chrome or Edge, and reliably turns up AI writing assistants, meeting recorders, and “summarize this page” tools nobody declared.

3. Endpoint

What it sees. Installed applications and running processes, so desktop AI apps are visible by name. Clipboard activity, which is where most sensitive data actually moves. File uploads. Browser history across every browser on the machine, not just the managed one. On Windows, an endpoint agent can also enforce — blocking a process from launching or a paste from completing.

What it cannot see. Unmanaged and personal devices, which is the whole BYOD population. Phones and tablets. Anything on a machine where the agent is not installed, which in practice means contractors and shadow hardware.

Where it fits. The only layer that sees content at the moment it moves, in any application, regardless of the destination or the account signed in. If your concern is regulated data leaving, this is where the evidence lives.

Practical note. Run it in audit mode first. The point of the first fortnight is to learn the baseline, and the baseline is almost always higher than expected. Enforcement decisions made before you have that data tend to be wrong in both directions.

4. Identity, OAuth, and Microsoft 365

What it sees. Third-party AI applications an employee has consented into your Microsoft 365 or Google Workspace tenant, the scopes they hold, and when consent was granted. This is where AI meeting assistants, mailbox summarizers, and agentic integrations appear.

What it cannot see. Anything that does not involve an OAuth grant — a personal ChatGPT account with no tenant relationship is invisible here. Prompt content. Local desktop AI use.

Where it fits. Structurally distinct from every other layer, and the one most commonly left uncovered. An OAuth consent is a cloud-side action: it never touches an endpoint and never generates a DNS lookup from the device, so endpoint agents and network tools cannot see it even in principle. This is not a gap in anyone’s product; it is a property of where the event happens.

Practical note. Review enterprise application consents in Entra ID and the Google Workspace admin console directly. You need no new tooling to start, and it is common to find AI services holding mailbox or file scopes that no one remembers approving. Several incidents in our shadow AI incident record began exactly here.

5. Prompt and content inspection

What it sees. The actual text going into an AI tool, classified before it is sent: credentials, PII, PHI, payment data, source code. Implemented either in the browser or at the clipboard on the endpoint. This is the layer that turns “someone used AI” into “someone sent 400 customer records to a third party at 14:32”.

What it cannot see. Data that reaches the tool by a path it does not monitor — a file uploaded from an unmonitored device, a screenshot, a photograph of a screen.

Where it fits. This is what AI DLP means. It is the difference between a usage log and an incident record, and it is what an auditor asking “what data was involved?” needs you to have.

Practical note. Start with the classifiers where a false positive costs little and a false negative costs a lot: credentials and regulated identifiers. Broad classification from day one produces alert fatigue and gets the programme switched off.

Why No Single Layer Is Sufficient

The layers do not overlap enough to substitute for one another, and the gaps are structural rather than a matter of product maturity.

Two rows deserve attention. The M365 notetaker is invisible to three of the five layers, which is why organizations with good endpoint coverage are still surprised by it. And the personal laptop on a hotspot is invisible to all five — no detection technology solves that one. It is addressed by policy, by conditional access, and by making the sanctioned tool good enough that the unsanctioned route is not worth the effort.

That last point is worth stating plainly: some shadow AI is not a detection problem. If a control cannot see a device, no amount of tooling will change that. Recognising the boundary keeps a detection programme honest and stops it promising coverage it cannot deliver.

Agentic AI and AI Agents

The emerging complication is AI that acts rather than answers. An agent granted access to a mailbox, a repository, or a SaaS tenant will read and write data on a schedule, without a human present.

For detection purposes, agents mostly surface at the identity layer rather than the endpoint or the network. The signal is the OAuth grant, the API token, or the service account — not a browser session. Two consequences follow: your non-human identity inventory becomes part of your shadow AI inventory, and the review cadence has to be periodic rather than event-driven, because there is no user action to alert on.

This is also where prompt injection stops being theoretical. An agent that ingests untrusted content and holds real permissions is a different risk class from a chatbot. Several entries in the incident record are agentic-AI and integration exploits rather than employee mistakes.

A Practical Detection Checklist

Ordered by effort-to-value, not by importance. The first three need no procurement.

This week, with tools you already have:

1. Review OAuth grants in Entra ID and Google Workspace. Filter enterprise applications by consent date, look for AI vendors, and note the scopes. Revoke anything unrecognised holding mail or file access.
2. Enumerate browser extensions across managed Chrome and Edge. Flag anything with AI capability or broad read and change all your data permissions.
3. Pull DNS or proxy logs for known AI domains over the last 90 days. You are looking for the shape of usage — how many distinct devices, which departments — not a list of culprits.
4. Check installed applications in your RMM or MDM inventory for desktop AI apps.

This month:

5. Write down the approved list. Detection with no policy behind it produces findings nobody can act on. An AI acceptable use policy is the cheapest control in this entire guide.
6. Pick the layer that matches your risk and deploy there. Regulated data and a managed Windows fleet points at endpoint. Mixed-OS and no agent appetite points at browser. A pure inventory question points at identity.
7. Run in audit mode for two weeks before enforcing anything.
8. Decide what “normal” looks like so that alerts mean something. Volume of AI use is not itself a finding.

Ongoing:

9. Re-run the OAuth review quarterly. New grants appear continuously and there is no event to alert you.
10. Track new AI tools against your approved list rather than trying to blocklist the world.
11. Keep the evidence. Whatever you detect, retain it in a form an auditor or an underwriter can consume — the questions in the cyber insurance and AI tracker are a good test of whether your records are sufficient.

Common Mistakes

Blocking first. Wholesale blocking without a sanctioned alternative pushes usage to personal devices, where you have no visibility at all. You have not reduced risk; you have relocated it somewhere you cannot measure.

Treating volume as the metric. “AI usage is up 40%” is not a finding. Sensitive data in prompts is a finding. Optimising for the wrong number produces a programme that reports activity instead of risk.

Stopping at discovery. An inventory that nobody acts on ages badly. Discovery is the first step, not the deliverable.

Assuming the endpoint agent covers everything. It does not cover the OAuth layer, and that is where AI services holding access to your mail and files show up.

Frequently Asked Questions

How do you detect shadow AI?

Detect it at the layer the usage happens on. Network and DNS logs show which AI domains were reached. Browser telemetry shows which AI sites and extensions are in use. An endpoint agent shows desktop AI apps and clipboard activity. Reviewing OAuth grants in Microsoft 365 or Google Workspace surfaces AI services holding access to company data. Prompt inspection classifies the content itself. Most organizations need at least two of these, because the layers do not overlap.

Can shadow AI be detected without installing software?

Partly, and it is the right place to start. Reviewing OAuth grants in your identity provider, enumerating browser extensions through existing browser management, and querying DNS or proxy logs all use tooling you already have. That combination finds AI services with tenant access and AI sites being visited. It will not find desktop AI applications or show you what data went into a prompt.

Why can’t a DNS filter or firewall detect all shadow AI?

A resolver sees the domain and nothing else. It cannot tell a personal ChatGPT account from a corporate one, because both resolve the same domain. It cannot see prompt content, cannot see AI features embedded in SaaS you already allow, and is bypassed by a phone hotspot. It is a useful first control and an insufficient last one.

How do you detect AI tools used on personal accounts?

Not at the network layer — the account is invisible there. The browser and endpoint layers can, because they observe the session and its content rather than the destination. On unmanaged devices, personal-account use is not detectable by any technical control, and the answer is policy, conditional access, and making the sanctioned option genuinely better.

How do you find AI apps connected to Microsoft 365?

Review enterprise application consents in Entra ID: filter by consent date, look for AI vendors, and check the granted scopes. Microsoft Graph exposes the same data programmatically for continuous monitoring. This is the only layer that sees them — an OAuth consent never touches an endpoint or generates a DNS lookup from the device.

How long does shadow AI detection take to set up?

Reviewing OAuth grants and browser extensions is an afternoon. DNS filtering is minutes to hours. Browser extensions deploy through enterprise browser policy or MDM in hours. Endpoint agents deploy through an RMM in hours to days depending on fleet size. Network and SSE platforms take longest, because they require routing and inspection changes.

Is detecting employee AI usage legal?

In most jurisdictions, monitoring on company-owned managed devices used for work is lawful when employees have been informed through a written acceptable use policy. Requirements vary by country and US state, and parts of the EU require works-council consultation before monitoring is introduced. Have legal review the monitoring scope and the AUP before deployment, and communicate it through HR rather than springing it on people. This is general information, not legal advice.

---

The useful question is not “how do we detect all shadow AI” — you cannot, and any vendor implying otherwise is selling. It is “which layer does our actual risk sit on, and what is the cheapest control that produces evidence there”. Start with the identity review, because it costs nothing and routinely surprises people. Then read the buyer’s guide once you know which layer you are shopping for.