• Posted by: Michal Zuberek
• March 18, 2026

MCP Servers and the Supply Chain Risk Nobody Is Watching

Over the past year, the Model Context Protocol has quietly become the dominant standard for connecting AI assistants to external tools and data sources. Developers install MCP servers to give their AI agent access to a file system, a database, a code repository, a browser, or an internal API. The ecosystem has grown fast — there are now hundreds of third-party MCP servers available, covering everything from Slack integrations to AWS management to custom business logic.

And almost nobody is asking where those servers come from, what they actually do on the network, or who maintains them.

What an MCP server actually is

An MCP server is a process that runs on your machine (or in your infrastructure) and exposes a set of tools to an AI agent. When you ask your AI assistant to "check my calendar" or "run the tests" or "push this to staging," it is calling functions in an MCP server that you installed. Those servers run with whatever permissions you granted them — often broad ones, because that is the point. They have access to your files, your credentials, your network. They can make outbound connections. They can read and write data.

The supply chain angle

MCP servers are typically installed from public registries or directly from GitHub repositories, often with a single command. The install instructions in a README are trusted implicitly because the AI assistant recommended the server, or a colleague shared a link, or it appeared in a curated list. The vetting process is rarely more rigorous than that. This maps almost exactly onto the conditions that made npm and PyPI attractive supply chain attack surfaces — a large volume of small, trusted-by-convention packages, installed with minimal scrutiny, running with significant permissions.

Observed patterns worth flagging

Several patterns have already begun appearing in the wild. Typosquatted MCP server names in public registries that differ by one character from popular legitimate servers. Servers that perform their advertised function while also exfiltrating environment variables or API keys over outbound HTTPS to attacker-controlled infrastructure. Servers that appear dormant but activate based on the content of the prompts they receive — a technique sometimes called prompt-triggered exfiltration. Because MCP servers are expected to make network calls (that is often their entire purpose), outbound connections attract little suspicion.

Why this is hard to catch with conventional tools

Antivirus and EDR solutions are largely blind to this. The server code is often interpreted (Python, Node.js), not a compiled executable with a known signature. The network traffic is TLS-encrypted and goes to cloud infrastructure that would not appear on any threat intelligence blocklist. Static analysis of the server code requires actually reading it carefully — and most developers do not review the full source of every MCP server they install, any more than they audit every npm package.

What behavioral monitoring changes

The same approach that detects a compromised software update or a trojanized installer applies directly here. An MCP server for managing your local file system should not be making HTTPS requests to infrastructure outside your organization. An MCP server for your calendar integration should not be connecting to IP ranges that have no association with your calendar provider. Establishing a baseline of what each MCP server legitimately communicates with — and alerting when that baseline is violated — provides detection that is independent of whether the server code has been reviewed, signed, or vetted by any registry.

The attack surface around AI tooling is expanding faster than the security practices that should accompany it. If you want to understand what the MCP servers and AI agents running in your environment are actually doing on the network, we would be glad to help you find out.