TL;DR: Shadow AI is spreading through unauthorized MCP servers, editor integrations, OAuth grants, and local tooling that security teams often do not see until they audit config files, logs, and tokens, according to Obot. The core issue is not detection alone, but the collapse of governance assumptions around agent access, data flow, and approval.
NHIMG editorial — based on content published by Obot: Shadow AI and unauthorized MCP servers are hiding in plain sight
By the numbers:
- 63% of organisations have no AI governance policy.
- 80% of organisations lack a mature governance model for AI.
- 77% of workers paste sensitive corporate data into AI services.
Questions worth separating out
Q: How should security teams find unauthorized MCP servers and shadow AI first?
A: Start with the places that already expose behaviour: local config files, endpoint telemetry, DNS and proxy logs, and OAuth-connected apps.
Q: Why do shadow AI tools create more risk than sanctioned SaaS apps?
A: Shadow AI bypasses procurement, security review, and entitlement design, so it often enters with broad access and no clear accountability.
Q: What are the signs that AI tool usage is outside governance?
A: Look for repeated calls to AI endpoints from unmanaged devices, local processes tied to MCP servers, newly active OAuth tokens, and browser or desktop extensions that have not been reviewed.
Practitioner guidance
- Enumerate MCP configuration locations across endpoints Scan known local paths, editor settings, and repository folders for MCP definitions so you can identify which servers are present before you decide how to govern them.
- Correlate AI API traffic with source machines Use DNS and proxy logs to map outbound calls to AI endpoints back to specific devices, then compare that activity with declared tool usage and approved integrations.
- Review OAuth grants as governed identity assets Audit tokens and connected apps in GitHub, Slack, Notion, and similar systems, then revoke grants that were never reviewed or that no longer match business need.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Exact macOS, VS Code, Claude Desktop, and project-folder paths to search for MCP configuration
- Bash and MDM-oriented examples for collecting local server inventories across managed endpoints
- Step-by-step guidance for reviewing OAuth apps and personal tokens across common enterprise services
- Practical notes on using an MCP gateway to centralise approved servers and logging
👉 Read Obot's guide to finding shadow AI and unauthorized MCP servers →
Shadow AI and MCP servers: what IAM teams need to look for?
Explore further
Shadow AI is now an identity governance problem, not just a discovery problem. Config-file hunting, DNS review, and token audits are all symptoms of the same underlying issue: enterprises have no single, governed place where AI tool identity is registered, reviewed, and retired. That means offboarding, access review, and usage oversight are being asked to work after the fact, which is too late for tools that can appear in minutes. The practitioner conclusion is that AI tooling needs lifecycle governance, not just periodic inventory.
A few things that frame the scale:
- 63% of organisations have no AI governance policy, according to The State of Non-Human Identity Security.
- A separate finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs.
A question worth separating out:
Q: How should security teams govern shadow AI without blocking productivity?
A: Use visibility-based controls instead of blanket bans. Identify which tools are in use, who is using them, and what data they can access, then apply targeted policies by role and data sensitivity. That approach preserves legitimate AI adoption while reducing exposure from unsanctioned tools and unreviewed data paths.
👉 Read our full editorial: Shadow AI and unauthorized MCP servers are hiding in plain sight