MCPServerVetting
title: MCP Server Supply-Chain Vetting type: technique created: 2026-07-16 last_updated: 2026-07-16 related: ["radar/platforms/ModelContextProtocol", "radar/techniques/MCPServerDesignPatterns", "radar/techniques/SecureByDesign", "radar/techniques/SelfHostedSecurityReview"] sources: ["https://www.canopii.dev/State%20of%20MCP%20Security%202026.pdf"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
Treating third-party Model Context Protocol servers as untrusted supply chain rather than as trusted plugins. An MCP server is not a library that sits inert until called. It is code running on the same machine as the agent, holding whatever credentials the agent holds, and describing its own capabilities to the agent in text the user rarely reads. Installing one is closer to granting shell access than to adding a dependency.
Adoption of MCP servers has outpaced any practice for checking them. The default install flow is a single command, the default trust signal is a GitHub star count, and the default posture is that a server approved once stays approved forever. Each of those defaults fails under measurement.
Canopii scanned the public MCP registry in June 2026 and scored 11,524 servers using static analysis, supply-chain checks, live probes against running endpoints, and AI-assisted review (State of MCP Security 2026). The results contradict each default in turn.
Popularity is not a safety signal, and mildly inverts one. Servers with more than 1,000 GitHub stars are over five times likelier to be high-risk than obscure ones, and score lowest of any popularity bucket. Six of the fifteen most-starred servers in the registry grade D or F. Stars measure adoption, not scrutiny.
A meaningful fraction can execute attacker-supplied code. 232 servers ship a confirmed reachable path that evaluates arbitrary code, spawns shell commands from tool input, or deserializes untrusted data. These are the primitives that turn a prompt injection into code execution on the host running the agent.
The dependency floor is unpinned. 78% of scanned servers do not pin their dependencies, so the next upstream release runs unreviewed. 1,617 ship dependencies with known published vulnerabilities, and 260 run install scripts that execute before the server ever starts. The packages aging worst include a JWT library and three crypto libraries, which are the ones guarding authentication.
Approval does not persist. 184 server versions quietly changed their tool definitions after publication. Because clients trust the server's live tool definitions, the change takes effect with no re-approval prompt. The affected servers span crypto signing, payments, email, and enterprise auth.
Declared authentication is not enforced authentication. Of 77 remote endpoints declaring auth in their manifest, 24 served their full tool list to anonymous callers anyway.
Isolation is rare. 81% of servers ship with no sandboxing, and 86% bind to all network interfaces by default.
The technique is a small set of gates applied before and after adoption, replacing the implicit trust the install flow assumes.
Before adoption, check the server's score in a public index rather than its star count, and read what its tools actually claim to do. Prefer servers that pin dependencies and publish a security policy, noting that 86% publish none.
At install, pin the exact version. Run the server sandboxed rather than with full host access, and bind it to loopback rather than every interface.
On upgrade, treat a changed tool definition as requiring fresh approval rather than silent acceptance. This is the gate that the rug-pull finding exists to justify, and the one no client enforces by default.
For remote endpoints, verify that declared authentication is actually enforced by probing the endpoint anonymously, rather than trusting the manifest.
Canopii sells an enterprise MCP gateway and has a commercial interest in the conclusion that the ecosystem needs governing. The underlying data is published free as a continuously updated Trust Index, the methodology is stated, and the figures are falsifiable per server. The bias is worth naming; it does not void the measurements.
Model Context Protocol (Platforms/Assess/inner) is the prerequisite. MCP Server Design Patterns (Techniques/Assess/center) is the mirror image of this technique, covering how to build a server others will consume; this covers consuming a server someone else built. Secure by Design (Techniques/Assess/inner) argues that safety should come from ecosystem structure rather than per-user diligence, which is precisely what MCP currently lacks and what makes this manual practice necessary. Self-Hosted Application Security Review (Techniques/Assess/inner) is the same checklist-driven posture applied to web applications.
MCP Server Supply-Chain Vetting sits in the Assess ring of the Techniques quadrant, at inner position. The evidence base is strong and specific, and the practice applies directly to MCP servers already on this radar, including context7 MCP, mcp-knowledge-graph, memory-mcp, and Chrome DevTools MCP. Inner position reflects that the gates are concrete and cheap to apply rather than aspirational. It remains in Assess rather than Trial because no first-person production use has occurred: the vetting gates have not yet been applied to a running MCP setup and confirmed to catch anything. The gate for promotion is one deliberate pass over the MCP servers currently in use, pinning versions, checking scores, and sandboxing.
