The Model Context Protocol (MCP) ecosystem has exploded to over 10,000 public servers by mid-2026, but the infrastructure supporting trust in this network is showing critical fractures. A recent census of 21,643 registry servers reveals that 51% of multi-version servers change what they advertise between updates, with 40.6% of these changes occurring silently. This drift means that developers who vet a server once and pin their trust to its name are likely running code that behaves differently than what was originally approved.

The Illusion of Registry Safety

Current trust models rely heavily on name-based verification, which proves insufficient against dynamic server behavior. The official MCP registry does not review code or scan for malware; it only verifies ownership of the GitHub repository or domain. Security scanning is delegated to "downstream aggregators," leaving a significant gap between registration and runtime safety. Furthermore, popularity metrics like star counts have been identified as weak signals for security, failing to correlate with actual safety or stability in the ecosystem. Additionally, 4.2% of servers redirected their remote endpoint to a different host while keeping the same registry identity.

Runtime Enforcement vs. Static Scanning

Static scanners check a snapshot of the code, but they cannot predict or detect behavior changes that occur after the scan. To address this, new tools like CleiMesh propose runtime enforcement rather than one-time validation. By wrapping MCP servers with a signed, hash-chained receipt system, developers can tie each call to the specific server digest that executed it. This approach ensures that if a server swaps its underlying implementation or adds new capabilities, the change is provably recorded in the logs, preventing silent drift. Unlike a scanner, this method is continuous and after-the-fact provable.

Bounding the Attack Surface

CleiMesh’s approach focuses on two key properties: making drift non-silent and bounding the surface area of each call. Using a command-line interface like cleimesh mcp wrap, developers can restrict a server’s capabilities to only those granted by a specific token. If a server version attempts to expose a new tool, such as run_shell, when the token only grants search, the request is refused and the refusal is receipted. This ensures that a malicious or buggy update cannot expand its privileges without detection, and the server's SHA256 hash change is logged.

Limitations and Containment Strategies

It is important to note that cleimesh mcp wrap does not sandbox the native server process; it relies on OS-level user permissions. For developers requiring physical containment, such as preventing access to sensitive directories like ~/.ssh, the tool offers cleimesh mcp serve, which runs tools in a WebAssembly (WASM) sandbox. This distinction highlights the difference between logical bounding via receipts and physical isolation via sandboxing, giving builders options based on their threat model.

Key Takeaways

  • 40.6% of multi-version MCP servers change behavior silently between versions.
  • Official MCP registries do not perform malware scanning or code review.
  • Runtime receipting can detect and prove server drift, unlike static scanners.
  • Token-based grants can prevent unauthorized tool exposure even if the server advertises it.
  • WebAssembly sandboxing is available for physical containment of server processes.

The Bottom Line

Name-based trust is dead in the MCP ecosystem; without runtime receipting and token-bounded grants, your AI agent is flying blind against silent server drift.