Shadow AI and unauthorized MCP servers are hiding in plain sight

At a glance

What this is: This guide explains how to find shadow AI and unauthorized MCP servers using config files, network logs, OAuth tokens, and direct checks.

Why it matters: It matters because unmanaged AI tools create identity and access blind spots that affect NHI governance, autonomous tool use, and human-led approval models.

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.
• 40% of file uploads include PII or payment card details.

👉 Read Obot's guide to finding shadow AI and unauthorized MCP servers

Context

Shadow AI is the use of AI tools, agents, or workflows outside approved governance and review. In this case, the primary problem is identity visibility, because MCP servers, OAuth apps, browser extensions, and local scripts can all create access paths that IAM teams never explicitly sanctioned.

For identity programmes, the challenge is not only discovery but control-plane fragmentation. When AI-enabled tooling runs through editor configs, personal tokens, and ad hoc approvals, standard access review and offboarding processes no longer give a reliable picture of who or what can reach company data.

Key questions

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. That sequence gives you a practical inventory before you try to govern use. The goal is to establish what is already running, which accounts it touches, and which data paths are active.

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. Even when the tool is well intended, the absence of an owner and review cadence means the organisation cannot reliably enforce data handling, access control, or revocation.

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. Those signals show the tool is not just installed, but actively moving data through a path security teams may not know exists.

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.

Technical breakdown

How unauthorized MCP servers hide in local config files

MCP clients commonly store server definitions in predictable local paths, project folders, or desktop app settings. Those files can reveal server names, commands, URLs, and the scope of local integrations without requiring packet inspection. The security issue is that this creates an unmanaged identity layer on the endpoint, where a tool can be running, connected, and trusted by the user even though it never passed through central review. Practical visibility starts with enumerating these config files across managed devices and repositories.

Practical implication: Inventory local MCP configuration sources before you try to govern the servers themselves.

Why network logs are useful for shadow AI detection

DNS and proxy logs expose where AI tooling sends data, which is often the only reliable way to confirm active usage at scale. Repeated calls to AI API endpoints, local listener ports, and processes with MCP-related names provide behavioural evidence that config review alone cannot supply. This is especially important because AI adoption changes quickly, so one-time checks age out fast. Practical detection depends on continuous observation, not a single scan.

Practical implication: Use outbound traffic and process telemetry to confirm active AI use, not just declared use.

OAuth tokens turn AI tools into hidden data paths

Many AI tools and browser extensions rely on OAuth grants or personal access tokens to reach GitHub, Slack, Notion, and similar systems. Once those grants exist, the AI tool is no longer a local utility only. It becomes an identity-bearing integration with standing access to business data, which means review, scope, and revocation matter as much as they do for any other NHI. The governance risk is that these grants often bypass normal approval workflows and linger unnoticed.

Practical implication: Treat AI-linked OAuth grants as governed non-human access, not convenience features.

Threat narrative

Attacker objective: The objective is not always malicious compromise, but it can still be data access, token reuse, and unauthorized movement of corporate information through unmanaged AI tooling.

1. Entry occurs when employees install MCP servers, AI coding agents, or browser-based AI extensions that create unreviewed access paths inside the enterprise. Escalation follows when those tools receive OAuth grants or personal tokens that let them reach internal services and repositories.
2. Privilege grows when those grants are used to read or move corporate data through AI services that were never added to the approved control plane. Impact appears as hidden data flows, compliance exposure, and a shadow inventory that security teams have to reconstruct after the fact.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

OAuth grants are the new standing privilege layer for shadow AI. Once an AI extension or MCP-connected tool receives access to GitHub, Slack, or document systems, it behaves like any other NHI with a persistent entitlement. The difference is that users often perceive it as a productivity add-on rather than a governed identity. That perception gap is exactly where access sprawl forms, and it should be treated as entitlement drift with business data implications.

Shadow AI creates an approval gap that traditional IAM reviews were not designed to close. IAM programmes assume there is a stable request, an approval step, and a durable record to certify or revoke later. Unauthorized MCP servers break that assumption because the tool can be introduced locally before any central identity process sees it. The implication is that review cadences alone cannot govern runtime tool adoption.

Named concept: shadow AI control-plane gap. This article shows the absence of a single registration and enforcement layer for AI tooling across endpoints, logs, and OAuth-connected services. Without that control-plane view, organisations end up reconstructing usage from fragments instead of governing it as part of identity operations. Practitioners should treat this as a lifecycle design failure, not a visibility annoyance.

Human behaviour is the distribution channel for unmanaged AI, but the control failure sits with governance. People adopt tools to be productive, which means blanket blocking often drives usage further underground rather than eliminating it. The better lens is NHI governance with human adoption pressure in mind, because the real problem is not intent but the absence of a sanctioned path. Teams should make approved AI use easier to see, not harder to do.

From our research:

• 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.
• That confidence gap reinforces why a monthly AI inventory is not enough, and why the state of non-human identity security should be managed as a lifecycle problem.

What this signals

Shadow AI control-plane gap: the next governance failure will not be a lack of AI tools, but a lack of a durable place to register, approve, and retire them. Endpoint discovery will still matter, but only as an input to a broader identity lifecycle process that includes OAuth grants, endpoint telemetry, and sanctioned access paths.

With 1.5 out of 10 organisations highly confident in securing NHIs, the operational message is clear: AI usage is moving faster than identity governance can certify it. Teams should expect more endpoint-level discovery work until AI tooling is pulled into a governed control plane with logging and scoped access.

The practical shift is to treat AI tool adoption as an identity programme input, not a one-off security exception. That means feeding discoveries into The State of Non-Human Identity Security style inventory work, then linking the findings to OWASP Agentic Applications Top 10 thinking where autonomous workflows are involved.

For practitioners

• 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.
• Create a sanctioned MCP gateway for shared tools Register commonly used servers in a controlled gateway, enforce RBAC for access, and log calls so teams move from scattered discovery to ongoing oversight.

Key takeaways

• Shadow AI is an identity governance issue because unauthorized MCP servers, OAuth grants, and local AI tooling create access paths outside review.
• Discovery has to combine endpoint configs, network telemetry, and token audits because no single control plane currently sees the full picture.
• The durable fix is a governed access path for approved AI tools, not a blanket block that simply drives usage further underground.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• AI Trust Control Plane: An AI trust control plane is the enforcement layer that converts governance intent into runtime decisions for identity, data, and model access. It sits between policy and execution, using context such as task, entitlement, and environment to approve, constrain, or revoke access as the system operates.

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

👉 Obot's full article covers the config checks, log signals, token review, and gateway approach in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.