Shadow AI inside engineering orgs often is not a mystery SaaS logo on an expense report. It is an MCP server someone stood up in Cursor, Claude Desktop, or VS Code over a lunch break—wired to GitHub, Slack, or Notion with whatever token was handy.
Obot's practical guide starts where discovery is cheapest: local and project config files (mcp.json, Claude desktop configs, editor settings). Those files name the servers, commands, and URLs already in use. MDM tools such as Intune or Jamf can collect the same paths across the fleet instead of relying on voluntary self-reporting alone.
Next, pull DNS and proxy logs for known model and routing endpoints, group by source machine, and watch local ports MCP servers commonly bind. Then audit OAuth apps and personal access tokens in GitHub, Slack, Notion, and similar—tokens named like “mcp” or “cursor,” or apps nobody remembers approving, are usually enough to prove a live connection.
Asking teams directly still works if you frame it as inventory, not discipline. People adopt these tools to finish work; if the only answer is a hard block, they will route around you into less visible paths and you will lose the audit trail you were trying to create.
The governance move Obot argues for—and the one that holds up in a board conversation—is a sanctioned MCP gateway with RBAC, enterprise auth, and call logging, plus a curated catalog of vetted servers. Bring the popular ones under a shared control plane rather than pretending a monthly scavenger hunt is a control.
For service-desk and platform owners, that is the same pattern as any other shadow channel: discover, classify by privilege and data reach, then offer a safer default path that is easier than the underground one.