Here is how to find shadow AI in your organization: list the AI apps people have connected through your identity provider, check network and proxy logs against a catalog of AI services, look at browser sign-ins and extensions, follow expense reports and sign-up emails, and ask people directly. Then check the place most reviews skip, which is developer machines and code repositories, where coding agents load MCP servers that never show up as a web app. Each method sees something the others miss, so the full picture comes from combining them into one inventory.
Start with sign-ins: SSO and OAuth grants
The quickest first pass uses data you already have. When someone signs in to an AI tool with their work account, or lets it read their mail, calendar or files, the identity provider records an app and the permissions it was granted.
In Microsoft Entra, administrators can open Enterprise apps, select an application and review its permissions, split into those an admin granted for everyone and those individual users consented to. Microsoft notes that user-consented permissions cannot be revoked from the portal; that takes Microsoft Graph or PowerShell, and users can consent again unless user consent is restricted. Google Workspace has an equivalent page in the Admin console for controlling which third-party apps can access Workspace data.
Sort the list by permission. An AI meeting assistant that can read every calendar, or a writing tool with full Drive access, is where data actually leaves. The gap is anything people sign up for with a personal email or a password, which never touches your identity provider.
Check network, DNS and proxy logs
Network data catches AI use that sign-in data misses, including personal accounts on work devices. Secure web gateways, cloud access security brokers and DNS logs all record which services each device talks to.
Microsoft Defender for Cloud Apps, for example, reads firewall and proxy logs or collects traffic from Windows devices through Defender for Endpoint, then matches it against a catalog of more than 31,000 apps, each scored on over 90 risk factors. Microsoft's Purview guidance suggests filtering that catalog by the Generative AI category to see which AI apps are in use and tagging each as sanctioned or unsanctioned. Global Secure Access in Microsoft Entra goes further and flags AI chatbots, model provider APIs and SaaS MCP servers from internet traffic.
The limit is the catalog. Microsoft states that by default Defender for Cloud Apps cannot discover apps that are not in its catalog. A brand-new AI tool, an internal model endpoint, or a tool running entirely on the laptop can pass unnoticed.
Look at the browser: logins and extensions
Most AI use happens in a browser tab, and browser-level tools see detail that network logs cannot. Push Security, for example, discovers AI apps from login events in the browser and records how each user signed in, such as corporate SSO, a standalone password or a personal account. It also inventories AI browser extensions and the permissions they request, like page content or clipboard access.
Extensions deserve their own review. An AI extension that can read every page a user opens sees internal dashboards, customer records and source code, without anyone ever visiting an AI website.
Follow the money and the sign-up emails
Paid AI tools leave a trail in finance. Search expense reports and corporate card statements for AI vendors and subscriptions, and compare what you find with the list of tools security approved. Teams often buy a few seats on a card well before anyone asks IT. Look for line items from model providers too, since API usage billed to a developer's card is a sign of an internal tool built on that model.
Sign-up and receipt emails are another trail. Reco, for example, says it detects AI tool sign-ups and usage confirmations from email metadata without reading message content. If you do not run a tool like that, a mail search for welcome emails from common AI vendors gives a rough list.
Ask people what they use
Logs tell you what happened; people tell you why. A short survey or a team conversation asking which AI tools people use, for which tasks, and with what data, finds tools no log catches, and explains what an approved alternative would need to do.
Frame it as an inventory, not an investigation. Netskope's 2025 shadow AI report found that 60 percent of users of SaaS generative AI apps were still using personal or unmanaged accounts in May 2025. Use that widespread is a sign people need these tools, and an amnesty gets more honest answers than a crackdown.
The part most reviews miss: coding agents and MCP servers
The methods above were built for apps people open in a browser. Coding agents work differently. Tools like Claude Code, Cursor, GitHub Copilot and Codex run on developer machines and load MCP servers that give them new abilities: reading files, running shell commands, querying databases, calling internal APIs. Netskope's 2025 report found GitHub Copilot in use at 39 percent of organizations it measured.
A local MCP server usually talks to its agent over the stdio transport, which the MCP specification recommends for local servers. That traffic never leaves the laptop, so there is nothing for a proxy to match against a catalog. The server is defined in a config file, often committed to a repository, and it runs with the developer's own permissions. OWASP lists these unknown servers as MCP09, shadow MCP servers, in its MCP Top 10.
To find this layer you have to look where it lives. Our guide shows the exact config file for each coding agent and the commands to find MCP servers on developer machines, and how to search your source code host for project files like .mcp.json that bring servers onto every machine that clones a repo. For each server, record the package, version, what it can reach and who runs it, then check it against the MCP security checklist.
Put it all in one inventory and keep it current
Each method produces a partial list, and the value comes from joining them. A single inventory with the tool, who uses it, how they signed in, what data or systems it can reach, and whether it is approved, lets you decide tool by tool instead of reacting to the loudest one.
Give the inventory an owner. The teams that find shadow AI in your organization most reliably are the ones where one person, usually in security or IT, merges each source monthly and runs a short review with engineering and the business teams. Decide in advance what happens to each finding: approve it, approve it with limits such as a company account or narrower permissions, or retire it with a sanctioned replacement. Writing that down turns each discovery into a decision instead of an argument.
Then make it routine. Identity and network data can be reviewed continuously, while developer machines and repositories need a scheduled sweep. Netskope measured the average number of generative AI apps per organization rising from 5.6 to 7 between February and May 2025, so a list from last quarter is already out of date.
Finding shadow AI works best when people know what is allowed. Our AI acceptable use policy template gives you a starting policy, including rules for AI agents and MCP servers.
Next step: find shadow AI in your organization, including the agents
When you set out to find shadow AI in your organization, the browser and network side is well covered by existing tools. The agent side usually is not. NoFly does shadow AI agent discovery: a read-only Discovery Scan that lists every AI agent and MCP server across your developer machines and repositories, with a risk score and the reason for each.