Most Remote MCP Servers Run on Cloudflare, and You Can't Scan Them

The Model Context Protocol (MCP) is the plumbing layer that lets AI agents talk to external tools. An agent looking up stock prices, querying a database, or calling an API does so through an MCP server. As these servers move from local processes to remote HTTP deployments, the infrastructure they run on starts to matter in ways nobody has measured until now. This paper from the University of Calgary, accepted at an IEEE ICNP workshop, is the first systematic server-side measurement of the remote MCP ecosystem. The findings are blunt: the ecosystem is highly centralized, and the authentication mechanisms that secure most servers also block the security scanning needed to verify they are safe.

What the Ecosystem Looks Like Right Now

The researchers built a three-tier observability framework to characterize MCP servers at increasing levels of depth. Tier 0 is catalog metadata: what a gateway operator would know from the registry listing before making any network connection. Tier 1 is passive probing: what you learn after completing a protocol handshake. Tier 2 is live security analysis: actively scanning tool schemas for prompt injection and tool poisoning payloads.

They sampled 179 remote endpoints from two public registries: the Official MCP Registry (29 endpoints) and Smithery, the largest commercial PaaS registry (150 endpoints). Of those 179, only 76 (42.5%) were actually reachable. The rest returned connection timeouts or HTTP errors, meaning they exist in catalog metadata but are not actively deployed. This gap between registration and deployment is itself a signal about the ecosystem's maturity.

Cloudflare Eats Everything

The hosting concentration numbers are striking. Of the 76 reachable servers, 65 (85.5%) are hosted on Cloudflare's autonomous system (AS13335). The remaining 11 are scattered across Google Cloud (3), AWS (3), and smaller providers. The Herfindahl-Hirschman Index, the standard metric for quantifying market concentration, comes out to 0.736. For context, the DOJ considers any market with an HHI above 0.25 to be highly concentrated. The remote MCP ecosystem is nearly three times that threshold.

This concentration creates systemic fragility. If Cloudflare experiences a routing disruption, a BGP prefix hijack, or a platform-level outage, the majority of the remote MCP ecosystem goes down simultaneously. The dependent entities are not passive web servers but autonomous agents making real-time decisions. A disruption does not just take down websites; it takes down the tool-use layer of active AI systems.

The cross-registry analysis adds another dimension. There is zero overlap between the hosting infrastructure of the two registries. None of the Official Registry servers run on Smithery's PaaS. None of the Smithery-listed servers run on third-party providers. The two registries are completely siloed at the infrastructure level, which means the centralization is not just at the network layer but also at the organizational layer.

Authentication Is a Platform Decision, Not an Operator Decision

The second major finding concerns who decides whether an MCP server requires authentication. Of the 56 Smithery-hosted servers, 53 (94.6%) returned authentication-gated responses, meaning the gateway requires OAuth 2.1 tokens before completing the MCP handshake. Zero Smithery servers permitted unauthenticated tool enumeration. Of the 20 externally-hosted servers, 10 (50%) were auth-gated and 7 (35%) permitted open access.

The conditional probability tells the story: P(auth-gated | Smithery) = 0.946, while P(auth-gated | External) = 0.500. That 44.6 percentage-point gap strongly suggests that authentication is a consequence of the hosting platform's defaults rather than individual developer configuration. Smithery implements OAuth 2.1 with PKCE at the gateway layer, fronting all hosted servers behind a centralized authorization server. From the outside, you cannot tell whether a developer chose to add authentication or whether the platform imposed it.

This matters because the MCP specification mandates OAuth 2.1 with PKCE for all hosted multi-tenant deployments. But in practice, that mandate is being implemented at the platform level by a single provider, not independently by hundreds of developers. The security baseline of the ecosystem is effectively controlled by Smithery's infrastructure choices.

The Security-Observability Tradeoff

This is the paper's central conceptual contribution. The platform-level authentication that secures the majority of servers simultaneously blocks automated vulnerability scanning. To scan a server's tool schemas for poisoning vectors, you need to complete the MCP handshake, which requires authentication on auth-gated servers. Without valid credentials, you cannot enumerate the tools, read the schemas, or check for embedded prompt injection payloads.

The numbers make this concrete. Of 76 reachable servers, 63 (82.9%) are auth-gated and therefore opaque to Tier 2 analysis. Only 7 servers permitted unauthenticated scanning, and all 7 received a SAFE verdict from the AgentSeal vulnerability scanner. This means the entire population accessible to automated security analysis is seven servers, and all of them happen to be clean. The 63 auth-gated servers, which represent the vast majority of the ecosystem, cannot be scanned at all without prior credential provisioning.

The authors formalize this as a structural property of the current ecosystem. Let S be the full population of reachable servers. Let S_auth be the auth-gated subset and S_open be the complement. The Tier 2 security analysis function is defined only over S_open. As platform-level authentication adoption increases, S_open shrinks, reducing the domain of the analysis function. The tradeoff is not a bug in any individual server's configuration; it is an emergent property of the ecosystem's architecture.

Why This Matters for Tool Poisoning

The threat model is straightforward. A malicious or compromised MCP server can embed adversarial instructions in tool name strings, description fields, or schema annotations. When an LLM-based client enumerates available tools, these instructions enter the context window as legitimate context. The agent may then exfiltrate data, execute unauthorized tool calls, or follow the attacker's instructions instead of the user's.

Previous work has confirmed that this vector is exploitable in production settings. The question is whether gateway operators can pre-screen servers for poisoning before provisioning them in an active agent pipeline. The Security-Observability Tradeoff says: not for 82.9% of the ecosystem. You cannot verify that a server's tools are safe without first authenticating, which requires trusting the server enough to obtain credentials, which requires knowing whether the tools are safe. The circularity is the problem.

What Gateway Operators Should Do

The paper offers practical guidance for developers building AI gateways and agent routing fabrics. Since active scanning is structurally unavailable for most servers, integration workflows should require credential provisioning before any security assessment. An auth-gated classification confirms that platform-level authentication exists but provides no information about the safety of the tool schemas behind it.

Concrete recommendations include maintaining a local trust ledger of catalog-level and passive compliance signals aggregated during the integration handshake, requiring server operators to provide signed tool manifests at onboarding, and applying differential trust policies based on hosting platform. PaaS-hosted servers (where platform-level audit commitments may exist contractually) warrant different treatment than externally-hosted servers, where the 50% authentication adoption rate indicates higher variance in operator security practice.

Protocol-Level Fixes the Authors Propose

The authors suggest two protocol extensions for the Linux Foundation AAIF, which governs the MCP specification. Neither is validated; they are design directions motivated by the measurement results.

The first is a Tool Schema Transparency Log, structurally analogous to Certificate Transparency for X.509 certificates. A server's tool schemas would be submitted to a public, append-only, cryptographically-signed log at deployment time. Gateway operators could verify schema hashes against the log without needing unauthenticated access to the server itself. This would preserve security signals in the presence of authentication.

The second is standardized security metadata fields at the catalog level: schema hash, scan attestation URI, and last scan timestamp, surfaced in registry API responses. These fields would allow registry-level security characterization before any protocol-level connection, addressing the measurement gap exposed by the single-class degeneracy without changing the wire protocol.

Limitations

The dataset is a cross-sectional snapshot from a single point in time. The MCP ecosystem is evolving rapidly, and the hosting distribution, authentication rates, and registry composition may shift significantly in coming months. The sample is drawn from two public registries; enterprise-internal and privately-hosted servers are not represented. The Tier 2 analysis is constrained to seven servers, which is too small for statistical generalization about tool-poisoning prevalence. The correlation between hosting platform and authentication posture, while strong, cannot be interpreted as causal without a controlled experiment or longitudinal design.

The Bigger Picture

This paper maps the physical infrastructure beneath the abstraction layer that AI agent developers interact with. When you call an MCP server, you are making a network request to a specific autonomous system, behind a specific platform's authentication gateway, with a specific set of tools exposed through a specific schema format. The security of that interaction depends on choices made at every layer, most of which are invisible to the agent developer and unverifiable without credentials.

The centralization finding is not just a network measurement curiosity. It means that the reliability and security properties of the MCP ecosystem are largely determined by a small number of infrastructure providers. The security-observability tradeoff means that the mechanisms designed to protect servers also prevent external verification of their safety. For anyone building or deploying AI agents that rely on remote tool access, these structural constraints are not theoretical. They are the current reality.

Read the paper on arXiv