Shadow AI detection tools fall into five groups, and the useful question is not which one is strongest but where each one sits. Network and secure access tools see traffic to known AI services. Browser and SaaS security tools see sign-ins, extensions and connected apps. AI agent platforms see the agents built in tools like Copilot Studio and Salesforce. Data security tools see which data AI can reach. Agent and MCP discovery tools see coding agents and the MCP servers on developer machines. Each group is blind where another looks, so the right choice depends on where AI is used in your company.
How shadow AI detection tools differ
Shadow AI is any AI tool used without security sign-off, and it shows up in different places. A marketer pastes a draft into a chatbot in a browser tab. A sales team connects an AI note-taker to everyone's calendar. A business analyst builds an agent in a SaaS platform. A developer adds an MCP server to a coding agent that can run shell commands. No single vantage point sees all four.
Below, each category is described with what it sees, what it misses, and examples taken from the vendors' own documentation. Vendors add features often, so check current docs before you buy.
Network and secure access: SSE, CASB and gateways
These shadow AI detection tools sit in the path of web traffic, or read logs from firewalls and proxies, and match each connection against a catalog of known services. Microsoft Defender for Cloud Apps, for example, gathers data from firewall and proxy logs or from Windows devices through Defender for Endpoint, and scores apps from a catalog of more than 31,000 against over 90 risk factors. Microsoft's Global Secure Access adds shadow AI discovery that flags AI chatbots, model provider APIs and SaaS MCP servers from internet traffic. Zscaler describes identifying shadow AI by inspecting outbound traffic, DNS queries and URLs to known AI domains, with prompt-aware controls through its AI Access Security product.
What they see: which AI services every device on the network or behind the proxy talks to, how much data moves, and often prompts and uploads where traffic is inspected. What they miss: anything not in the catalog; Microsoft states Defender for Cloud Apps cannot discover apps outside its catalog by default. They also miss tools that create no web traffic, such as a local MCP server talking to a coding agent on the same laptop.
Some vendors in this group now add an endpoint view. Netskope Client AI Discovery scans managed Windows and macOS devices for AI agents including Claude Code, Claude Desktop and Codex, local language models, IDE AI extensions and local MCP servers. Netskope's documentation notes it relies on a signature file, so it finds listed assets, and it does not see inside virtual machines or containers unless the client is installed there.
Browser and SaaS security: sign-ins, extensions and OAuth
This group watches what happens in the browser and in your SaaS apps. Push Security discovers AI apps from browser login events, records whether each user signed in with corporate SSO, a password or a personal account, inventories AI browser extensions and their permissions, and finds OAuth connections between AI tools and systems like Google Workspace. Reco describes detecting unapproved AI apps through OAuth grants, sign-up emails from metadata, browser activity and network traffic, with integrations for more than 260 SaaS apps.
What they see: who uses which AI app, how they authenticated, and which AI tools hold standing access to company data. What they miss: anything outside the browser and SaaS layer. A coding agent run from a terminal, and the MCP servers it starts, do not pass through a browser or a SaaS login.
AI agent platforms: agents built inside SaaS and on laptops
A newer group focuses on agents themselves. Zenity, for example, keeps an inventory of agents built in Microsoft 365 Copilot, Copilot Studio, Salesforce Agentforce and ChatGPT Enterprise. It also describes discovering coding and personal agents on developer laptops, including Codex, Claude, Cursor and GitHub Copilot, along with the MCP servers and tools they connect to, using native agent hooks and an MCP gateway for runtime control.
What they see: agents business users build without review, and in some products, coding agents and their tool calls. What they miss: depends on which platforms and endpoints are connected, so check coverage against the agents your teams actually run.
Data security: what AI can reach
Data security platforms start from the data rather than the tool. BigID describes finding unmanaged models, copilots, agents and third-party AI apps, then mapping which sensitive, regulated or proprietary data they use, across file shares, databases, developer tools and AI systems.
What they see: exposure, meaning which sensitive data sits where AI can read it. What they miss: real-time use; they answer "what could leak" better than "who is using what today".
Agent and MCP discovery: where NoFly fits
NoFly's Discovery Scan reads repositories, developer machines and your identity provider, read-only, and lists every AI agent and MCP server it finds, who runs it, where, and what it can reach: files, secrets, the terminal, the network. Each server is scored against the NoFly list, with a plain reason for the score.
Its limits are worth stating. NoFly does not watch browser chat apps, prompts or SaaS usage, so it does not replace a gateway or a browser tool. It does not block or enforce anything today; policy and runtime protection are on the roadmap, not live. It is built for one layer, the agents and MCP servers developers add, and goes deep on that layer: what each server can touch and whether it behaves the way it claims.
How to choose shadow AI detection tools for your team
Start from where AI is used, not from a feature list. If most use is chat apps in the browser, a gateway or browser tool you may already own covers it. If business teams build agents in Microsoft or Salesforce, look at agent platforms. If you have engineering teams on coding agents, check how each candidate finds local MCP servers, how it reads their config files, and whether it covers repositories that carry project-level servers.
| Category | Sees | Usually misses |
|---|---|---|
| Network and SSE/CASB | Traffic to known AI services, data volume, prompts where inspected | Apps outside the catalog, local tools with no web traffic |
| Browser and SaaS security | Sign-ins, account type, extensions, OAuth grants | Terminal and IDE agents, local MCP servers |
| AI agent platforms | Agents built in SaaS platforms; some coding agents | Platforms and devices not connected |
| Data security | Sensitive data AI can reach | Live usage and new tools |
| Agent and MCP discovery | Coding agents, MCP servers, their access and risk | Browser chat apps and prompts |
Budget matters too. A gateway or CASB you already pay for may cover the browser layer with a policy change rather than a new purchase, which frees budget for the layer it cannot see. Run a short trial of any new tool against a list you built by hand, so you can tell what it finds that you did not already know.
Ask every vendor the same three questions: how a new, unlisted tool gets found, what happens on devices without your agent installed, and how often the inventory refreshes.
Whatever tool you choose, write down what is allowed first. Our AI acceptable use policy template includes a section on AI agents and MCP servers that most policies leave out.
Next step: cover the layer your shadow AI detection tools miss
Most shadow AI detection tools were built for the browser and the network, and they do that well. If your developers use coding agents, check the layer they add. Run a Discovery Scan to see every AI agent and MCP server across your machines and repositories, with a risk score for each.