Most organizations that ask how to detect shadow AI already have the evidence sitting in systems they pay for. Identity provider consent logs, DNS resolver logs, the MDM inventory, the corporate card feed, the secret scanner in the CI pipeline. None of these were bought for shadow AI detection, all of them record it, and in most organizations nobody has ever pulled them side by side and read them as one picture.
We covered why shadow AI is the governance blind spot in an earlier post. This post is about finding it: six signals, what to filter for in each, where each one lies to you, and what to do once the count comes back higher than expected. In our experience the first pass turns up three to five times as many AI tools as the security team had on its list.
Shadow AI detection: six signals you can pull this week
The first three take an afternoon. The fourth and fifth need a contact in finance and in engineering. The sixth is the one most teams skip, and it produces the best data.
1. SSO and OAuth app grants
Start in the identity provider, because it's the only source that ties a tool to a named person with no inference required. Every "Sign in with Google" or "Sign in with Microsoft" on an AI product leaves a third-party app consent behind.
In Entra ID, open Enterprise applications and filter to apps where consent came from users rather than an admin. Google Workspace has a third-party app access report with every OAuth client and its scopes, and Okta shows the same under Applications.
Filter on scopes, not names. Read access to mail (Mail.Read, gmail.readonly), calendar (Calendars.Read, calendar.readonly), and files (Files.Read.All, drive.readonly) granted to a vendor you don't recognize is the pattern. AI meeting notetakers are the biggest cluster: they arrive with calendar and mail scopes, and one person's consent lets the bot join every meeting on that calendar, including calls with counterparties who never agreed to anything.
On one pull we watched the same notetaker show up under forty-odd accounts, and only two people remembered installing it. The rest had clicked "allow" on a link to a meeting where the bot was already attending.
2. DNS, proxy, and CASB logs
Resolver logs and the forward proxy tell you which AI vendors the network is talking to. Build a domain list and query for it. Ours starts here:
- openai.com, chatgpt.com, api.openai.com, oaistatic.com
- anthropic.com, claude.ai, api.anthropic.com
- gemini.google.com, generativelanguage.googleapis.com, aistudio.google.com
- perplexity.ai, poe.com, you.com, character.ai
- huggingface.co, replicate.com, together.ai, groq.com, mistral.ai, deepseek.com
- cursor.sh, cursor.com, windsurf.com, api.githubcopilot.com
- otter.ai, fireflies.ai, read.ai, fathom.video
Volume tells you what kind of use you're looking at. A browser tab produces bursts with long idle gaps, while a sanctioned server-side integration calls an api. endpoint at a steady rate from a fixed subnet. An api. subdomain being hit from a workstation subnet usually means a developer put a key in a script or a desktop app is calling a model directly.
The false positives are where most first reports fall apart. gemini.google.com lights up for every Workspace user because Gemini is bundled into Gmail and Docs whether anyone asked for it or not. Traffic to huggingface.co from the data science VLAN is usually a model download for sanctioned work. The biggest one: an approved vendor whose product calls OpenAI from the browser, so the proxy attributes hundreds of openai.com requests to people who have never opened ChatGPT. Until you correlate the DNS count against the identity source and the referer, it will overstate the problem, and the first time you present an inflated number is the last time anyone reads the report.
CASB signatures lag new AI tools by weeks, and DNS is blind to personal devices on cellular, which becomes the whole story later in this post.
3. Browser extensions and desktop apps
Chrome Browser Cloud Management reports every installed extension with its permissions, and osquery's chrome_extensions table exposes the same permissions column on endpoints. Jamf and Intune application inventories cover desktop apps: the ChatGPT and Claude desktop clients, Cursor, Ollama, LM Studio.
The extension class to look for is the "AI writing assistant" and the "summarize this page" tool. Both need to read every tab to work, so they request the <all_urls> host permission, and every tab includes the CRM, the claims system, and the HR portal. Filter the inventory to <all_urls> plus tabs or webRequest and read the list by hand. It's shorter than you'd think, and worse.
What surprises teams here is the permissions rather than the count. A free PDF summarizer that fifteen people had installed asked for <all_urls>, clipboardRead, and webRequest. Nobody installed it to read their clipboard.
4. Expense and procurement data
Ask finance for twelve months of corporate card transactions with merchant descriptors matching OPENAI, ANTHROPIC, CHATGPT, CLAUDE, PERPLEXITY, MIDJOURNEY, JASPER, OTTER, FIREFLIES, ELEVENLABS, RUNWAY, and CURSOR. Recurring charges of $20 and $25 dominate the result.
The loophole is the approval threshold. Most expense policies exempt software under some amount, often $500, from procurement review, and AI subscriptions are priced under it. A five-seat Team plan at $25 per seat per month comes to $1,500 a year, bills monthly at $125, and never trips anything.
The same product also appears under three different descriptors ("OPENAI *CHATGPT SUBSCR", "CHATGPT", "OPENAI LLC"), so a single-string search undercounts. And the AI add-on line on the Notion or Zoom renewal never registers as an AI vendor at all. It sits inside an invoice for a tool you already approved, the cleanest way we know for a new model to enter an organization unreviewed.
5. Code and repos
Three queries. First, the secret scanner (GitHub secret scanning, gitleaks, TruffleHog) for LLM provider key formats: sk-proj- and sk- for OpenAI, sk-ant- for Anthropic, AIza for Google, hf_ for Hugging Face. Scan history, not only HEAD, because keys get committed and then removed.
Second, dependency manifests. Search every requirements.txt and package.json in the org for openai, anthropic, google-generativeai, langchain, litellm, and @ai-sdk. Each hit is an application calling a model that probably never went through a vendor review, because the "vendor" was a pip package.
Third, MCP server configs: .cursor/mcp.json, .mcp.json, claude_desktop_config.json, .vscode/mcp.json. These are the newest source and the most consequential. A config that points an agent at the production Postgres or the Jira instance means something on a laptop has read access, sometimes write access, to systems the security review never considered, through a path no proxy log will label as AI.
6. The survey and the amnesty
Ask people. Send a short form to every team: which AI tools do you use to get your work done, for what, and what would you lose if it disappeared tomorrow. State up front that there is no penalty and no follow-up from security, and mean it.
The answers are more honest than the logs for a reason the logs can't fix: logs record traffic and nothing about why. A survey tells you that the underwriting team pastes broker submissions into Claude to extract key fields because the intake tool takes four minutes per file and Claude takes ten seconds. The DNS log would have shown fifteen claude.ai hits per person per day.
Phrasing decides the response. "Have you used unauthorized AI software" gets a compliance-flavored no. "Which AI tools help you do your job" gets a list, and often a pitch for why the tool deserves approval. Run it after signals 1 through 5 so you can compare: the survey under-reports tools people forgot they use (extensions), and the logs over-report (bundled Gemini, vendor-side API calls).
AI usage monitoring after detection
Detection hands you a list, and what you need next is a baseline: which identities use which tools, through which path, and with what classes of data in the prompts. Without a baseline you can't tell a change from noise.
The baseline has three columns. Identity is who. Tool is which model or product, reached through a browser, an API key, an extension, or an agent. Data class is whether the prompt carried customer PII, PHI, source code, contract text, credentials, or nothing sensitive. The first two come from the six signals above. The third only exists where traffic passes through a point you can inspect: a gateway or an inline CASB for browser use, something you own in the request path for API use. Watch for movement in all three: a team that used ChatGPT for drafting starts pasting claim files, service accounts show up, an API key appears where only browser use existed before.
Monitoring everything is neither possible nor the point. You will never inspect the prompt an adjuster types into ChatGPT on a personal phone, and trying to reproduces the failure mode of every DLP program before it: large coverage claims, low actual coverage. AI usage monitoring exists so you know what goes through the sanctioned path well enough to trust it, and so you notice when the unsanctioned path grows.
What AI data leakage actually looks like
The phrase suggests exfiltration, and what we see is more mundane. In rough order of frequency:
- A customer record, or a spreadsheet of them, pasted in with "summarize this" or "draft a reply."
- Source code pasted for debugging, including config files with connection strings still in them.
- A contract or policy form pasted with "explain this clause."
- Claim files with PHI (medical records in bodily injury and workers' comp) pasted for extraction.
- Meeting transcripts captured by a notetaker nobody in the meeting approved.
Almost none of it is malice. The person who pasted a customer file into a chatbot wanted a faster answer and never thought of the chatbot as a third party. The data left through an honest shortcut, so an insider-threat program is the wrong tool for the problem, and the people who leaked the data are the same people most able to tell you where the shortcut is, which is why signal 6 works.
What happens to the data afterward depends on the tier. Consumer plans of most chat products retain conversations and may train on them unless the person opts out; enterprise and API tiers generally don't. Which tier an employee is on is, in a shadow AI situation, unknown by definition.
Three questions we get asked
Is ChatGPT shadow AI? Only when it's unsanctioned. ChatGPT Enterprise, procured, behind SSO, with a data processing agreement, is sanctioned AI. The same product on a personal account with corporate data pasted into it is shadow AI. The path makes it shadow, not the tool.
How do you avoid shadow AI? Not entirely, and not by blocking. You shrink it by making the approved path faster than the unapproved one: an acceptable use policy short enough to read, an approval lane for low-risk tools that takes days rather than a quarter, and a sanctioned model access point that's already logged in and already knows what data it may see. The last item does most of the work.
Can you give an example of shadow AI? An account manager installs a free "AI email assistant" extension. It asks to read every page, gets it, and from then on ships the CRM, the pricing sheet, and the support inbox to a model hosted by a company with a two-paragraph privacy policy. Nobody bought it, nobody reviewed it, and the only record of it is a row in an extension inventory nobody queries.
The ceiling on detection
Every method above shares a limit: it finds usage after the data has already left. The OAuth grant was consented weeks ago, the DNS entry records a request that completed, the expense report covers last month. Detection is an autopsy with good timestamps.
The usual response is to block: push the domain list to the proxy, revoke the OAuth grants, pull the extensions. Blocking works on paper and fails in the proxy logs. Traffic to claude.ai drops to zero in the week after the block, and the underwriting team is still extracting fields from submissions, on a personal phone, with the same data, and now with no log at all. We've watched the drop and the silence that follows more than once. Blocking moves the usage somewhere you can't see it.
Shadow AI is a demand signal. Read the detection data that way and it changes meaning: forty accounts consented to a notetaker because forty people need meeting notes, fifteen people installed a PDF summarizer because they read long PDFs, and the underwriters paste submissions because intake is slow. None of that is a discipline problem, and none of it responds to discipline.
The organizations that shrink shadow AI do it by offering a sanctioned path that is faster than the shadow one: approved models behind an identity-aware gateway, where the usage policy is applied at the prompt. The employee gets a model that's already signed in through SSO, already knows their role, and answers as fast as the consumer tab did. The sensitive-data guardrails run in the request path, where the employee never sees them: a claim number gets masked before the prompt leaves, a paste that looks like a customer list gets held for review. Nobody routes around a path that's faster than the alternative, so blocking becomes a footnote.
Detection tells you the size of the demand, and the gateway is what converts it into governed usage.
At Swept AI, we build Swept Access, a gateway that puts approved models behind your identity provider and enforces usage policy at the prompt. If the six signals come back with a bigger number than you expected, that number is your demand forecast. Talk to us about what the sanctioned path for it would look like.