Shadow AI and unauthorized MCP servers may already be running inside your company without your security team knowing. This guide shows you how to find them using config files, network logs, OAuth tokens, and a few simple checks—and what to do once you’ve found them.
If you’re working solo, you hopefully have quite good control over what’s running on your computer. But if you work in a company with a few developers, I can almost guarantee that someone has an MCP server running on their computer right now.
This isn’t because your team members are careless; employees may adopt these tools for productivity without malicious intent. But that’s also how shadow AI spreads inside companies. Setting up an MCP server takes a few minutes, and you probably haven’t had any policies refusing them to do so. I have already installed many MCP servers without checking this first.
So in this article, I will go through how to find these shadow agents and MCP servers, and what to do with your findings.
What do we need to look for?
Shadow AI is almost like shadow IT, but faster: traditional AI practices involve formal vetting and monitoring for security, while shadow AI focuses specifically on unauthorized AI use. They are AI tools or workflows operating outside approved tools and reviewed systems. And it’s usually one of these:
MCP servers configured for an editor like Cursor, VS Code, Claude Desktop, etc.
Coding agents like Claude Code or Codex running with access to GitHub repositories
Scripts or bots that has the possibilities to call LLM APIs with secret API keys
Browser extensions or desktop apps that talks with AI services in the background
Start searching for config files
One of the easiest way to start this quest is to look for different config files. This is because each MCP client stores its servers in a known location.
I use MacOS, and these are some of the typical paths:
Also look for projects/folders connected to your company. Inside each of these, try to look for files like .cursor/mcp.json, .vscode/mcp.json, and .mcp.json.
You can then use an MDM tool like Intune or Jamf to run a script that collects files like this. You can use this little bash snippet:
for f in ~/.cursor/mcp.json \
~/Library/Application\ Support/Claude/claude_desktop_config.json \
~/.claude.json; do
[ -f "$f" ] && jq -r '.mcpServers | keys[]' "$f" 2>/dev/null
done
This gives you a list of server names. If you also add the command and url fields as well, you will see what’s begin run, and where it connects.
Look at the network
So far we’ve only looked at config files. They can tell you about clients, but to detect shadow AI, this step looks closer to where the network traffic is going and other visibility signals that support shadow AI detection.
Pull the DNS logs or proxy logs for the last 30 days, and filter on some well known suspects api.openai.com, api.anthropic.com, generativelanguage.googleapis.com, openrouter.ai, and similar. Then group these by source machine. Monitoring network traffic can reveal unauthorized AI tool usage, and continuous monitoring is necessary because one-time checks miss changing AI usage.
I would also look for outgoing connections on the ports MCP servers usually run on locally like 3000, 8000, and 8080. And then check for processes with mcp in the name. On MacOS you can use lsof -i -P | grep -i mcp. That should get you pretty far. Without visibility into outbound connections, detecting shadow AI is much less reliable and organizations cannot manage Shadow AI risks effectively.
This one kind of surprised me the first time, it’s a really quick way to find connected OAuth apps. Go to the admin panel of the services you want to check like GitHub, Notion, Slack, etc. and review the OAuth apps and personal tokens to see which systems have AI tools access to internal data, especially since many AI tools and browser extensions rely on OAuth grants without much security oversight.
An MCP server that connects to GitHub usually shows up as a token named something like “mcp” or “cursor”, or maybe even as an OAuth app you’ve never heard of. Those unapproved connections can bypass normal review and create hidden data flows. And then if a token has been used in the last week, someone has a server running. These tools may process data in ways the organization cannot control, and unapproved use can put intellectual property at risk.
Simply just ask
This sounds too simple, but it also can give you some quick answers. Direct outreach can help you start building an inventory of AI tools in use so you can understand current usage, not discipline people. Since 63% of organizations have no AI governance policy and 80% of organizations lack a mature governance model for AI, simply asking is often the fastest way to surface unknown usage during AI adoption. Send a message or an e-mail to your team, and say that you’re making a list of MCP servers people use. Just be frank that this ask if not to get them in trouble, just that you want to make a list to for input from your security and governance teams so they can review it all as part of the AI governance policy.
Most people will search and find what they are using, and give it to you. Maybe you will even learn about a new useful server!
What do you do with the list of AI tools
Once you have a list of MCP servers and agents, don’t just block everything; the next step is to manage shadow AI because it creates significant data security and compliance risks for organizations. Since most people add/install something to become more efficient, they will likely just find another way to do it anyways. If you make things too restrictive, employees may shift usage into less visible paths, which reduces oversight and weakens security controls.
Instead, look for servers that more than one person on your team is already using, and put those behind an MCP gateway like Obot — a free, open-source control plane purpose-built for this. Obot lets you register a curated, vetted catalog of MCP servers, enforce RBAC so only the right users or groups can reach each one, connect enterprise auth (Okta, Active Directory, etc.) And rather than per-person API keys, and set guardrails that block risky calls before they happen. Every call gets logged, so you go from “I think three people use this” to an actual usage record.
Most team members won’t mind switching to a shared, sanctioned version as long as it’s easy to use — which is the whole point: the goal isn’t to stop people from using MCP servers, it’s to help them use the ones they already rely on in the safest way possible. I recommend building a routine to do this one time per month or so. That matters even more as shadow AI raises questions of regulatory compliance under frameworks like GDPR and the EU AI Act.
Worth noting: everything above — hunting through config files, pulling DNS logs, auditing OAuth tokens — is manual work you have to redo every month, because there’s no single place all of this activity flows through. That’s the deeper problem a gateway like Obot solves. It isn’t just a home for the servers you’ve already found; it’s what turns shadow AI back into ordinary, visible AI usage going forward. Once MCP traffic runs through a gateway, you’re not reconstructing an inventory from scattered logs after the fact — you already have it, continuously, without the monthly scavenger hunt.
👉 Obot helps enterprises operationalize MCP governance with centralized control, observability, and secure connector management. Try Obot today.
Summary of shadow AI risks
So, shadow AI is already here, and the goal is to detect it, find solutions for it, and recognize that it can also process and retain company data.
