Ask your security team how many MCP servers are running across your organisation right now. If they can answer with confidence, you’re ahead of most enterprises. Tenable’s Cloud and AI Security Risk Report 2026 found 70% of enterprises have integrated at least one AI or MCP package into their production infrastructure — and almost none have a formal inventory or approval process for those integrations.
That’s shadow MCP. Developers connecting MCP (Model Context Protocol) servers to their AI coding tools — Cursor, Claude Code, VS Code — without IT knowing about it, approving it, or having any record of what those servers can access. Because these connections run locally on developer workstations rather than through the network, IT has no way to see them. In this article we’re going to give you a picture of the MCP supply chain attack surface, a practical audit process, a framework for building an approval workflow from scratch, and the language you need to brief your board.
What Is Shadow MCP and Why Is It Different From Regular Shadow IT?
Shadow MCP is what happens when developers connect MCP servers to their AI tools without IT knowledge or approval. It’s shadow IT for the AI agent era — but it’s technically harder to govern than the shadow IT you’re already dealing with.
Shadow SaaS leaves a trail. Proxy logs, DNS queries, web application firewalls — they’ll surface it eventually. STDIO-based MCP servers are a different matter. They run on the developer’s workstation as locally installed processes, invisible to the network, with no firewall rules to request and no DNS entries to raise a flag. Tray.ai frames this as “shadow IT for the agent era.” Kiteworks has a term for what follows: the governance-containment gap — the delta between your ability to monitor a risk and your ability to stop it. For shadow MCP, both sides of that gap are at zero.
JumpCloud research puts 8 in 10 office workers using public AI without IT’s knowledge, and 45% of developers using unsanctioned code assistants. That’s not an individual problem — it’s structural. And shadow servers carry the same CVE exposure as audited servers — without an inventory you can’t tell the governed ones from the ungoverned ones.
Why Do Developers Add MCP Servers Without Telling IT? The Incentive Structure
The short answer is productivity. Developers add MCP servers for coding speed, data retrieval, and workflow automation — and in most organisations there’s no governance policy telling them otherwise. STDIO is the path of least resistance: install a package, run it locally, no IT request, no firewall rule, no waiting. Only 15% of organisations have updated their Acceptable Use Policies to cover AI at all.
Without a clear path from sandbox to oversight, quick experiments become unmanaged systems touching real data. That’s the pattern.
Punitive approaches don’t work when the behaviour is structurally incentivised. The fix is making the approved path as frictionless as the unapproved one — and that starts with knowing what you’ve already got.
How Do I Audit Which MCP Servers Are Running in My Organisation Right Now?
Start with the workstations, not the network. STDIO connections leave no network footprint, so a perimeter scan will find nothing. MCP server configurations live in tool-specific config files on developer machines — the audit has to go there directly.
Tell your team to check three places: Claude Code (~/.claude/ and project-level .mcp.json files), Cursor (.cursor/mcp.json in project directories and user settings), and VS Code (MCP extension configurations in workspace and user settings).
The security research firm intuitem provides a useful per-server checklist: grep for shell execution paths; trace tool arguments to the first external boundary; check config for URLs, tokens, and trust settings; review sample configs. At fleet scale, Token Security integrates with CrowdStrike to automatically retrieve config files across developer machines and classify each MCP instance by authentication and data access.
The audit output you’re looking for is an asset register: server name, transport type (STDIO or HTTP), declared permissions, requesting developer, date first observed. Triage each entry into three buckets: low-risk local utility, data-access risk requiring review, external HTTP server requiring security assessment.
How Do I Build an MCP Server Inventory and Approval Process?
The inventory is the foundational governance artefact. Without it, no other control is possible — you can’t patch, monitor, or restrict what you haven’t recorded.
Here’s the minimum viable inventory record for each server: name and source (npm package, custom build, or vendor-supplied); transport type (STDIO or HTTP/SSE); declared and observed permissions; requesting developer and team; approval status and approving authority; date added and last reviewed.
The approval workflow has four stages:
- Developer submits an intake form: server name, source, intended use, requested permissions. Keep it under 10 minutes.
- Security review: known and maintained source? Necessary permissions only? Open CVEs?
- Approval decision: approved as-is, approved with restrictions, or rejected with documented rationale.
- Inventory update: approved server added to the register; developer gets confirmation and permitted configuration.
TrueFoundry’s four-pillar framework — discovery, policy, access control, monitoring — maps directly to this workflow and validates the structure. Inventory first, then approved catalogue, then enforcement. For HTTP/SSE connections, an AI gateway is the most scalable control plane — currently only 43% of organisations have deployed one (Kiteworks). The JFrog Universal MCP Registry is the first enterprise-grade option for server inventory, signing, and policy enforcement when you’re ready to formalise your governance tooling.
Local (STDIO) MCP Servers vs Remote (HTTP) MCP Servers — Which Creates More Shadow Risk?
STDIO MCP servers run as locally installed processes on the developer’s workstation. HTTP/SSE MCP servers are hosted remotely and communicate over the network. Neither is inherently safe, but STDIO is harder to govern — and here’s why.
No network footprint: STDIO connections generate no traffic, so your perimeter monitoring, SIEM, and DLP tooling cannot detect them. Easier to install: no firewall rules, no DNS, no IT provisioning required. And they inherit developer permissions: the STDIO server runs with the same OS-level access as the developer’s process — any file, credential, or API the developer can reach, the MCP server can reach. Researchers have demonstrated prompt-injection attacks that exfiltrate secrets via covert channels such as DNS queries.
HTTP/SSE servers are network-observable — findable via DNS, proxy logs, or network flow analysis. They introduce their own risks: external dependency, potential data transmission outside the organisation, TLS and authentication requirements. An AI gateway governs HTTP connections but cannot govern STDIO ones. The two control mechanisms are complementary, not interchangeable.
That distinction matters when you’re briefing upward. The question isn’t just “do we have MCP servers” — it’s “what type are they and what controls apply to each.”
How Do I Brief the Board on the MCP Security Disclosure?
54% of boards don’t have AI governance in their top five priorities (Kiteworks). The problem is urgency framing, not information volume.
Frame the briefing as a business risk: “We have AI tools operating with access to production data and no inventory of what they are or what they can do. That’s an audit exposure and a liability question, not just a security question.” Lead with numbers boards respond to: 70% enterprise MCP adoption (Tenable), 43% AI gateway deployment rate meaning the majority operate without a control plane (Kiteworks), and Gartner‘s projection that 1 in 4 compliance audits in 2026 will include specific inquiries into AI governance.
Three things the board needs to hear: what we have (audit results by risk tier), what we are doing (the approval process being built and its timeline), and what the residual risk is (what remains ungoverned while the process is being built).
Don’t recommend a blanket block. Blocking all MCP tools removes developer productivity without improving security if the ban isn’t enforceable. For healthcare organisations: Kiteworks reports 55% board disengagement on AI governance in healthcare — the highest of any vertical. Adjust the urgency framing accordingly.
Here’s draft language for the board: “Our engineering teams use AI coding tools that connect to local and remote data sources via the MCP protocol. We are conducting an audit to inventory these connections and building an approval process. Until that process is in place, we are operating with an incomplete picture of our AI-related data access.” Board members who want deeper background will find it in our complete MCP security guide.
FAQ
For answers to specific questions about MCP governance, see below.
How do I find all MCP servers running in my organisation?
Conduct an endpoint-based audit, not a network scan — STDIO MCP servers leave no network footprint. Check MCP configuration files in Claude Code (~/.claude/), Cursor (.cursor/mcp.json), and VS Code workspace settings on developer machines. Token Security’s automated discovery integrates with CrowdStrike for fleet-scale enumeration.
Do I need to block all MCP servers until the vulnerabilities are patched?
Blanket blocking is rarely enforceable and removes the developer productivity gains that drove adoption in the first place. A risk-tiered approach works better: restrict servers with broad data access or external HTTP endpoints, permit low-risk local utilities under monitoring, and establish an interim approved list while the full approval process is being built.
What should I tell the board about MCP security risk?
Frame it as a business risk: an incomplete inventory of AI-connected tools with access to production data is an audit exposure and a liability question. Lead with numbers — 70% enterprise adoption (Tenable), 43% AI gateway deployment rate (Kiteworks), and 1 in 4 compliance audits in 2026 including AI governance inquiries (Gartner). Present a remediation timeline.
Is shadow MCP the same problem as shadow IT?
Shadow MCP extends shadow IT but is technically more opaque. STDIO connections generate no network traffic, so traditional shadow IT detection methods — proxy logs, DNS, network flow analysis — don’t surface them. The governance response is similar (inventory plus approval process) but the discovery method must be endpoint-based, not network-based.
What permissions can an MCP server access?
STDIO MCP servers inherit the OS-level permissions of the developer’s process — any file, credential, or API the developer can access, the MCP server can access. HTTP MCP servers access whatever credentials and API keys the developer provides in the configuration. Both types require explicit least-privilege scoping, which most organisations haven’t done yet.
Which developer tools expose the most MCP shadow risk?
Token Security identifies Claude Code, Cursor, and VS Code as the primary surfaces where unauthorised MCP configurations are found. Risk correlates with tool adoption, not the tool itself. A fleet audit should cover all three regardless of which is the officially sanctioned choice.
What is the governance-containment gap and how does it apply to MCP?
The governance-containment gap (Kiteworks) is the delta between your ability to monitor a risk and your ability to stop it. For shadow MCP via STDIO, both are currently absent — you can’t see STDIO connections and you can’t stop what you can’t see. Closing the gap requires endpoint visibility before any control mechanisms can be applied.
What is TrueFoundry’s four-pillar MCP governance framework?
TrueFoundry’s framework covers discovery, policy, access control, and monitoring. It’s a useful structural reference for organisations building their first MCP governance programme, but it doesn’t provide a concrete approval workflow template — the intake and sign-off process has to be built separately.
How is shadow MCP different from other AI security risks in 2026?
Most AI security risks in 2026 involve cloud-hosted services observable via SIEM and DLP tooling. Shadow MCP via STDIO is unusual because existing security tooling has no visibility without specific endpoint-based discovery capability — it’s structurally similar to a removable media risk: the threat travels with the developer workstation, not through the network perimeter.
Should I use an AI gateway to control MCP traffic?
An AI gateway is the most scalable control plane for HTTP/SSE MCP connections, centralising policy enforcement, logging, and rate limiting. Gartner projects 70% of software engineering teams building multimodal apps will use AI gateways by 2028; current adoption is 43% (Kiteworks). An AI gateway cannot govern STDIO connections — endpoint controls are required for those.
What happens after a shadow MCP server is discovered — what do I do next?
Triage immediately: low-risk utility, data-access risk requiring review, or external HTTP server requiring security assessment. For data-access risk servers: freeze the configuration, review what data has been accessible, and decide whether to approve with restrictions or block. Document everything for audit and board reporting.
What does Tenable’s 70% MCP adoption figure mean for my organisation?
Tenable’s Cloud and AI Security Risk Report 2026 found 70% of enterprises have integrated at least one AI or MCP package. If your organisation hasn’t conducted an MCP audit, the statistical expectation is that integrations are already present. Audit now rather than wait for an incident to force the discovery.
