Shadow AI vs Shadow MCP: How to Find Unsanctioned Tool Connections and Their Tokens

Shadow AI leaks what people type into a model, while shadow MCP hands a model the ability to act with someone's credentials, and programmes built to catch the first routinely miss the second. Shadow AI discovery watches traffic, browsers and SaaS sign-ups; an unsanctioned Model Context Protocol (MCP) server is often just a line in a configuration file, a child process of an IDE and a token in an environment variable or keychain. This guide compares the two on discovery, credential and data paths, and policy response. It is written for security engineers, IAM teams and platform owners who already run a shadow AI programme. The broader taxonomy of shadow AI is in Shadow AI vs Shadow IT, and the full governance programme for agents and servers is in the Unsanctioned AI Agents and MCP Servers Guide; this page does not repeat them. Protocol details reflect MCP specification revision 2026-07-28, checked on 14 November 2026. Products named as examples are listed alphabetically; order is never a ranking.

Key takeaways

• Different asset, different question. For shadow AI the question is "what data left?"; for shadow MCP it is "which credential can this server use, and what can it do with it?".
• Network discovery finds shadow AI, file discovery finds shadow MCP. Local stdio servers create no distinctive traffic, so the configuration file on the endpoint and in the repository is the primary inventory.
• Every shadow MCP server is also a secrets finding. The MCP authorisation specification tells stdio servers to take credentials from the environment, so each discovered server points to a token that needs an owner, a scope review and possibly rotation.
• Removing the server does not revoke the access. OAuth grants and refresh tokens outlive the configuration line; revocation happens at the identity provider or the downstream service.
• Policy responses differ in kind. Shadow AI is governed mostly by data rules and approved alternatives; shadow MCP needs managed client configuration, allowlists matched on command or URL, and per-server credentials.

The short answer

Shadow AI is the use of AI models and AI features that the organisation has not approved: a public chatbot used with a personal account, an AI writing feature switched on inside a SaaS tool, a browser extension that summarises pages. The dominant risk is disclosure: staff send prompts, files and pasted content to a third party under terms the organisation never agreed. OWASP lists this as LLM02:2025 Sensitive Information Disclosure.

Shadow MCP is the use of MCP servers, the connectors that give an AI client tools, resources and prompts, without approval. The dominant risk is delegated action: the server runs code or calls APIs with the user's or a service's credentials. OWASP's matching category is LLM06:2025 Excessive Agency, and a malicious server is a software supply chain problem (ATT&CK T1195.002 Compromise Software Supply Chain). Most taxonomies file shadow MCP under shadow AI, but treating it as another AI app leads to the wrong sensors and the wrong fix.

If you already have AI app discovery and can fund one new control, make it an endpoint and repository inventory of MCP configuration files, joined to secrets and OAuth grant data.

Side-by-side comparison

Discovery methods: why each needs different sensors

The network, browser and endpoint trade-offs for shadow AI are covered in Network vs Browser vs Endpoint Shadow AI Discovery. The point here is how those sensors perform against MCP specifically.

What finds shadow AI

Proxy, SSE and CASB logs catch AI services by domain category, and CASB catalogues let you tag discovered apps as sanctioned or unsanctioned. Browser telemetry sees prompts and paste events, including AI features inside approved SaaS. Identity provider records show corporate sign-ins and consent grants to AI apps.

What finds shadow MCP

• Configuration files on endpoints: MCP clients declare servers in files. Documented locations include ~/.claude.json and project .mcp.json for Claude Code, and ~/.copilot/mcp-config.json, workspace .vscode/mcp.json, workspace-root .mcp.json and the user-profile mcp.json for GitHub Copilot in VS Code. Portable files use a top-level mcpServers object; the VS Code format uses servers. Collect the server name, transport, command and args or url, and the names (not values) of env keys and headers. The step-by-step collection method is in How to audit MCP servers on developer laptops.
• Repositories: a committed project-level file spreads a server to every clone; search default branches and CI images for MCP configuration file names.
• Process telemetry: package runners and interpreters spawned as children of IDEs or AI desktop apps, and new listeners on localhost, show which declared servers actually run.
• Client telemetry: some clients can export which servers and tools were invoked. Claude Code, for example, records MCP server and tool names in OpenTelemetry tool events when OTEL_LOG_TOOL_DETAILS=1 is set.
• Identity provider consent records: remote MCP servers that use OAuth against your IdP appear as consented applications, the same way AI apps do. This is the one source both problems share.

The asymmetry matters: a stdio server wrapping a cloud CLI calls the provider's API with the developer's own profile, so on the wire it looks like the developer and no proxy log labels it MCP. Run both sensor sets and reconcile them in one register.

Credential and data paths

Shadow AI paths

Data flows outward: prompts, files, pasted code and transcripts go to the AI provider, usually under the user's own sign-in or a personal account. When an AI app is connected to mail, files or calendars, an OAuth grant adds a standing credential held by the vendor. That grant is the bridge to the MCP problem: it is a non-human identity outside your control. In the Vercel Context.ai OAuth Breach, an employee's broad grant to a consumer AI app stayed valid after the app vendor was compromised, and a stolen token was used to take over the employee's Workspace account (ATT&CK T1528 Steal Application Access Token).

Shadow MCP paths

Data flows both ways and credentials are exercised, not just exposed. The MCP authorisation specification marks authorisation as optional and says stdio implementations should not follow the HTTP authorisation flow but should retrieve credentials from the environment. In practice four credential patterns turn up:

Data exposure through MCP is less visible too: a tool result can pull a whole table or mailbox into the model's context, and on to the model provider, without anyone pasting anything. A malicious or compromised server can also exfiltrate directly (T1567 Exfiltration Over Web Service). The postmark-mcp Malicious MCP Server 2025 worked normally for fifteen versions; version 1.0.16 added a hidden blind copy to the send-email tool, using each victim's own email service token. No traffic monitor flagged it, because the mail went out through a legitimate account.

For finding remote servers that rely on long-lived keys, see the MCP Static Token Audit; for the key versus OAuth design choice, see API Keys vs OAuth for MCP Servers.

Threat model and failure modes for each

Shadow AI

• Assets at risk: confidential documents, source code, personal data in prompts; mailbox and file contents behind OAuth grants.
• Threat actors: usually none at the moment of exposure; harm comes from provider retention terms or a later vendor compromise.
• Typical failure: the data cannot be recalled. In the Samsung ChatGPT Source Code Leak, engineers pasted source code and a meeting transcript into a public chatbot, and the company said it could not retrieve or delete what was sent.

Shadow MCP

• Assets at risk: every system the server's credential reaches, plus the endpoint itself, because a local server runs with the client's privileges.
• Threat actors: malicious package authors, compromised maintainers, attackers who plant a project-level config in a repository, and prompt injection that steers an agent into misusing a legitimate tool.
• Typical failures: an upgrade turns a trusted server malicious; tool descriptions change after approval (ATLAS AML.T0110 AI Agent Tool Poisoning, see MCP Tool Poisoning Detection); a project file loads servers without a prompt in non-interactive runs; a server holds a wildcard scope because it requested everything up front.

The specification's security best practices say a client offering one-click local server configuration must show the exact command without truncation and require explicit approval, and should sandbox servers with minimal default privileges. Not every client meets the "should" items, so managed configuration matters more than user judgement.

Policy responses compared

The block, sanction or coach choice is covered in Block vs Sanction vs Coach. The levers differ:

Managed client and identity controls by product

Documented customer-side examples, listed alphabetically:

• Claude Code (Anthropic): by default users can connect any server. Administrators can deploy managed-mcp.json (for example /etc/claude-code/managed-mcp.json on Linux) for a fixed server set, or set allowedMcpServers with allowManagedMcpServersOnly: true in managed settings for an approved catalogue, and deniedMcpServers to block. The documentation warns that a serverName entry is not a security control; enforce with serverUrl or serverCommand. A denylist match always wins.
• GitHub Copilot (GitHub): enterprise and organisation owners control the "MCP servers in Copilot" policy, can set an MCP Registry URL, and can choose "Registry only" under "Restrict MCP access to registry servers". As of November 2026 the documentation marks the registry route as public preview and recommends an MCP allowlist in the enterprise's managed-settings.json as the generally available method.
• Google Workspace (Google): under Security, Access and data control, API controls, the accessed apps list shows each OAuth app's user count and requested scopes, and apps can be set to Trusted, Limited or Blocked. Unconfigured third-party apps can be blocked from API access by default; accessed-app data can take up to 48 hours to update.
• Microsoft Entra ID (Microsoft): user consent settings can be limited to verified publishers and low-impact permissions (the microsoft-user-default-low policy, the documented recommendation) or disabled, with the admin consent workflow as the request path. Changes apply only to future consent; existing grants must be reviewed and revoked separately.

For remote servers, a gateway adds central policy and audit, but only for traffic routed through it; the trade-offs are in MCP Gateway vs Direct MCP Connections.

Decision criteria

• Lead with shadow MCP discovery when: you have more than a handful of developers using AI coding assistants, agents run in CI, or business users connect AI apps to mail and files. These are the populations where credentials are exercised.
• Lead with shadow AI discovery when: AI use is mostly chat and drafting and regulated personal data is the main concern.
• Small organisations: restrict consent at the IdP, publish a one-page approved server list and scan managed endpoints for MCP configuration files quarterly.
• Large organisations: deploy managed client policy through MDM, feed config inventory and client telemetry into the SIEM, keep an internal registry, and treat each approved server as a non-human identity with an owner in the MCP Server Inventory Template.
• Either size: block only what you can replace; blanket blocks push developers to personal devices.

Worked scenario

A 2,000-person software company has a mature shadow AI programme: CASB categorisation, an enterprise chat tenant, and coaching pages for unapproved chatbots. Its monthly report shows shadow AI falling. An MDM script is added that collects MCP configuration files from developer laptops.

1. Discovery: the first run finds 340 declared servers across 410 developer devices, 61 distinct by command or URL. Nineteen are stdio wrappers for cloud CLIs or databases, eight carry literal API keys in env blocks, and a committed .mcp.json in a popular internal repository adds an unofficial package-runner server to every clone.
2. Correlation: the eight literal keys are matched with secrets scanning results; three are also in Git history. The IdP shows 14 consented applications that correspond to remote MCP servers, two with full mailbox scopes.
3. Triage: servers are rated by what their credential reaches. The cloud CLI wrappers inherit administrator profiles and go first.
4. Response: the committed keys are rotated the same day, the repository file is replaced, the two mailbox grants are revoked at the IdP, and managed allowlists run in audit mode for two weeks before enforcement.
5. Result: none of these findings appeared in the CASB data. Six weeks later every server in use is allowlisted with an owner and a scoped credential.

Implementation path

1. Extend the register: add MCP servers as an asset type with transport, command or URL, version, credential type and location, scopes and owner.
2. Collect configuration: deploy a read-only collector through MDM or EDR for the known file locations; record env and header key names, never values.
3. Scan repositories: add MCP configuration file names to repository and CI image scanning, with secrets detection enabled on those files.
4. Join identity data: pull consented applications from the IdP and map remote MCP servers to their grants and scopes.
5. Restrict new consent: limit user consent and turn on the admin request path before announcing enforcement.
6. Pilot managed client policy: start with a denylist of known-bad servers, then an allowlist in audit or soft mode for one team, then enforce. Roll back by removing the managed policy file or setting through the same MDM channel.
7. Clean up credentials: for each retired server, revoke tokens at the source, rotate any static secret, and check the downstream service logs for use since installation.

Detection and measurement

Monitor new MCP configuration files and changes to existing ones on endpoints and in repositories, package runners spawned by IDE and AI desktop processes, new OAuth consents to unverified publishers, and client telemetry showing server or tool names not on the allowlist. Useful measures:

• Shadow MCP ratio: distinct servers in use that are not on the approved list, divided by all distinct servers in use.
• Credential coverage: share of approved servers with a dedicated, scoped credential and a named owner.
• Static secret findings in MCP config: count per month, with mean time to rotate.
• Grant revocation time: days from discovery of an unsanctioned remote server to revocation of its OAuth grant.
• Managed policy coverage: share of developer endpoints with enforced client allowlists.

Framework mapping

Common failure patterns

• Counting MCP as an AI app category: the CASB report shows a few remote MCP domains and the programme declares coverage, while stdio servers stay invisible.
• Deleting config without revoking: the server disappears from the laptop, but its OAuth refresh token and any static key still work.
• Allowlisting by name: a name is a label the user chooses; enforcement has to match the exact command or the URL.
• Ignoring committed project files: a single .mcp.json in a shared repository installs a server for every developer, and some clients load project servers without prompting in non-interactive runs.
• Approving a server, not a version: the postmark-mcp case shows that an approved package can change behaviour in one release.
• Collecting secret values during discovery: a script that copies env values turns the SIEM into a secrets store.

Practitioner checklist

• Collect MCP configuration files from managed endpoints, recording key names only.
• Scan repositories and CI images for MCP configuration files and secrets in them.
• Map remote MCP servers to OAuth grants in the identity provider and review scopes.
• Restrict user consent to verified publishers and low-impact permissions, with an admin request path.
• Deploy managed client allowlists matched on URL or exact command, piloted in audit mode first.
• Pin approved server versions and review tool list changes before rollout.
• Issue one scoped credential per approved server; never let servers inherit administrator profiles.
• On retirement, revoke tokens at source, rotate secrets, then remove configuration.
• Report shadow AI and shadow MCP as separate lines with their own metrics.

Standards and references

• Model Context Protocol: Authorization specification
• Model Context Protocol: Security Best Practices
• OWASP: Top 10 for LLM Applications 2025
• NIST: Cybersecurity Framework 2.0
• Anthropic: Control MCP server access for your organization (Claude Code)
• GitHub Docs: Configure MCP server access
• Google Workspace: Control which third-party and internal apps access Google Workspace data
• Microsoft Learn: Configure how users consent to applications

Related NHI Mgmt Group resources: Unsanctioned AI Agents and MCP Servers Guide · How to audit MCP servers on developer laptops · Local MCP Server Security Guide · Shadow AI Policy Template · MCP Registry and Server Publishing Security Guide