[Guide]
The shadow AI discovery playbook
You cannot govern what you cannot see. Here is a repeatable, one-week method to inventory every AI tool, agent, and MCP server in your organization, and to keep that inventory current.
[Key takeaways]
- Shadow AI is not a policy failure, it is a visibility failure. Discovery comes before control.
- You can build a credible inventory in five working days using data you already collect.
- Network egress, identity logs, browser signals, and endpoint telemetry each reveal a different slice of AI use.
- Treat discovery as a continuous control, not a one-time audit. New tools appear weekly.
Shadow AI is already in your stack
Every organization we talk to underestimates its own AI footprint. The sanctioned list is short: an enterprise ChatGPT tenant, maybe a Copilot license, perhaps an approved model API. The real footprint is an order of magnitude larger. Engineers wire up coding agents, analysts paste spreadsheets into free web chatbots, and product teams ship features that call third-party model APIs no one reviewed.
This is not malice. It is people doing their jobs with the fastest tool available. But it means sensitive data, source code, customer records, credentials, is flowing to endpoints your security team has never seen. The first job is not to block anything. It is to see everything.
Shadow AI differs from classic shadow IT in two ways that matter for discovery. First, the surface is fragmented: the same person may use AI in the browser, in the IDE, on the desktop, and over the API, all in one day. Second, the risk is data, not just an unmanaged app. A single pasted prompt can exfiltrate more than a rogue SaaS signup ever would.
Four signal sources, four different pictures
No single log tells you the whole story. Each source below reveals a different slice of AI use, and the overlap between them is where your confidence comes from. Start with whichever you already have and layer the rest in.
1. Network and DNS egress
Your firewall, secure web gateway, or DNS resolver already logs outbound connections. Query for known AI destinations: api.openai.com, *.anthropic.com, generativelanguage.googleapis.com, *.cohere.ai, *.mistral.ai, and the long tail of web chatbots. Volume and frequency tell you which tools are load-bearing versus experimental.
2. Identity and SSO logs
Your IdP (Okta, Entra ID, Google Workspace) records every OAuth grant and SSO login. Filter for AI vendors and, critically, for third-party apps that requested AI-related scopes. An OAuth grant to an unknown "AI assistant" that can read your entire mailbox or Drive is a finding, not a footnote.
3. Browser and extension signals
Most AI use happens in a browser tab. Managed-browser telemetry and extension inventories surface AI sidebars, chatbot tabs, and the growing category of "summarize this page" extensions that ship page content to a model. This is the slice network logs describe poorly, because it all rides over HTTPS to a handful of CDNs.
4. Endpoint and developer telemetry
Your EDR/MDM inventory lists installed desktop apps (Claude, ChatGPT desktop, Cursor, and others). On developer machines, look for coding-agent config, IDE extensions, and, increasingly, MCP server definitions in project or user config files. MCP servers are the newest and least visible layer: an agent can inherit broad access through one the moment it connects.
Day 1 to 2: Collect
Pull 90 days of egress, IdP, browser, and endpoint data. Do not analyze yet, just centralize it into one place you can query.
Day 2 to 3: Correlate
Match destinations and OAuth grants to tools and to owners. Deduplicate across sources so one tool is one row, not four.
Day 3 to 4: Score
Rank each tool by data sensitivity, user count, and whether it is sanctioned. Flag anything with broad OAuth scopes or unknown ownership.
Day 4 to 5: Report
Produce a one-page inventory: tool, owner, users, data at risk, and a recommended action. Share it, do not sit on it.
A five-day discovery sprint
Discovery does not need a new platform or a quarter of planning. It needs one owner, read access to the logs you already collect, and five focused days. Here is the sequence we run.
Day 1 to 2: Collect broadly
Resist the urge to filter early. Export 90 days of egress logs, IdP sign-in and OAuth grant logs, browser extension inventories, and endpoint software lists into one queryable store. Ninety days is enough to catch monthly-cadence use without drowning in noise.
Day 2 to 3: Correlate to tools and owners
Turn raw destinations into named tools, and named tools into human owners. The owner column is what turns a spreadsheet into an action plan. When two sources disagree, that disagreement is itself signal: a tool that shows up in browser telemetry but not in your SSO logs is being used outside your identity perimeter.
Day 3 to 4: Score by risk, not by volume
A tool used by two people to process customer PII outranks one used by fifty to summarize public docs. Score on three axes: sensitivity of the data likely flowing to it, blast radius (users and the access they hold), and governance status (sanctioned, tolerated, or unknown). Broad OAuth scopes and unknown ownership are automatic escalations.
Day 4 to 5: Report and route
The deliverable is a single page a CISO can read in two minutes and an engineering lead can act on the same day. For each tool: what it is, who owns it, how many people use it, what data is at risk, and one recommended action, sanction, gate, or retire. Discovery that ends in a slide deck no one revisits was theater.
From one-time audit to continuous control
The hardest truth about shadow AI is that a point-in-time inventory is stale the week you finish it. New models launch, a team adopts a new agent, an engineer connects an MCP server from a public registry. A discovery sprint gets you a baseline. Staying ahead requires the same signals running continuously.
The durable version of this is inline visibility: a transparent proxy that sees AI traffic across the browser, desktop, IDE, CLI, and API as it happens, and inventories new tools the moment they appear rather than 90 days later in a log export. That is exactly the gap Cerbera was built to close, discovery first, then inspection and control on the same path, so the inventory never goes cold.
Whichever way you implement it, the principle holds: discovery is a standing control, not a project with an end date. Rerun the correlation weekly, alert on net-new tools, and keep the owner column honest.