MCP Server Sprawl: Governing the API Layer AI Agents Built
Over 16,000 MCP servers appeared on public registries in the first half of 2026. AWS, Datadog, and Vercel shipped production servers. Microsoft disclosed that 26% of policy-tested MCP configurations violated safety rules. The protocol that connected AI agents to external tools has produced the same governance problem API proliferation created a decade earlier — only faster, and with a non-deterministic consumer that cannot read error messages.
The Sprawl in Numbers
The Model Context Protocol gave AI agents a standard way to reach tools, data sources, and services. The specification was technically sound — as covered in the technical guide to MCP, it defined clear primitives (tools, resources, prompts) and a session-based architecture. What the specification did not define was governance.
The result: mcp.so now lists over 16,000 servers. AWS shipped a generally available MCP server in May. Datadog, DigitalOcean, Adobe Marketo, and Vercel all released servers between March and April. Qualys launched TotalAI specifically to discover MCP endpoints that security teams did not know existed. The ecosystem grew faster than any API boom in memory — and arrived with less operational guardrail.
Sixteen thousand servers appeared in months. Authorization is optional. STDIO transport has no authentication. The protocol's own specification treats security as someone else's problem.
The credential statistics tell the story. An analysis of over 5,200 open-source MCP servers found that 88% require credentials to operate. Of those, 53% use long-lived static secrets and only 8.5% implement OAuth. In the API boom of 2015–2020, static API keys in config files were the exact vulnerability that gateway vendors built products to solve.
API Governance, Repeated Faster
MCP server sprawl mirrors the API proliferation problem that consumed platform teams from 2015 to 2020. Then, the pattern was: every team exposed a REST endpoint, no one tracked which endpoints existed, credentials leaked everywhere, and shadow APIs operated outside governance. API gateways, service meshes, and centralized registries eventually brought order.
| Dimension | API Boom (2015–2020) | MCP Sprawl (2025–2026) |
|---|---|---|
| Growth rate | ~5 years to saturation | ~18 months to 16,000+ servers |
| Authentication | API keys → OAuth 2.0 | Optional in spec; STDIO has none |
| Authorization model | Scope-based (OAuth scopes) | Does not exist in protocol |
| Discovery | Swagger/OpenAPI registries | Ad hoc (mcp.so, mcpmarket.com) |
| Consumer | Deterministic (code) | Non-deterministic (LLM) |
| Credential style | Static keys → vault-managed | 53% static secrets today |
| Gateway solution | Kong, Envoy, Apigee | Emerging (MCP Gateway, Envoy AI Gateway) |
The structural similarity is clear. The critical difference is in the consumer column. When a microservice calls a rogue API endpoint, it returns an error code that a developer reads in logs. When an LLM calls a rogue MCP server, the model interpre the response — including hostile tool descriptions or exfiltrated data — and may act on it without human review.
Where the Specification Falls Short
Earlier coverage of MCP's STDIO command injection exposed the implementation vulnerabilities in the SDK layers. The governance gaps sit one level above — in what the specification explicitly omits.
Optional Authorization
The MCP specification defines an authorization flow based on OAuth 2.1 — but only for the HTTP transport. The STDIO transport, which runs the server as a local subprocess, has no authentication mechanism. Any process on the same machine can connect to a STDIO-based MCP server. The specification treats authorization as an implementation concern, not a protocol guarantee.
The practical consequence: an MCP server running on a developer machine with access to a company Slack workspace, a GitHub organization, and a cloud billing account has no protocol-level mechanism to verify that the connecting client is authorized to perform any given action.
Advisory-Only Safety Hints
The specification defines destructiveHint, idempotentHint, and openWorldHint annotations that servers attach to tools. A tool marked destructiveHint: true signals that invoking it causes irreversible side effects. These hints are advisory — the host (the application controlling the model) can ignore them entirely. No protocol mechanism enforces confirmation, rate limiting, or audit logging based on these annotations.
Advisory hints that models can ignore are not guardrails. They are suggestions to a non-deterministic system that cannot read documentation.
Server Recommending Servers
One of the more consequential features in the specification is the ability for an MCP server to recommend additional servers to the host. A server that provides GitHub access can suggest the client also connect to a Slack server, a CI/CD server, or any other endpoint. This is a trust propagation mechanism without a trust model — a server the user never explicitly approved can recommend connections that expand the attack surface.
In the API world, this is equivalent to a microservice telling your API gateway to route traffic to a new endpoint the gateway has never seen. API gateways reject this by design. MCP hosts are not required to.
No Tool-Call Authorization
The specification defines that a tool exists and how to call it. It does not define who is allowed to call it, under what conditions, or with what parameters. The OAuth flow authenticates the connection between client and server — it does not authorize individual operations. There is no equivalent to API gateway scopes, RBAC per endpoint, or ABAC policies per tool invocation.
The Incident Record So Far
The governance gaps are not theoretical. AuthZed cataloged 10 confirmed real-world MCP security incidents between April 2025 and April 2026. The VulnerableMCP project documents 50 vulnerabilities across public MCP servers, 13 rated critical.
The most notable incidents include:
- MCPwned (Token Security, RSA 2026): An Azure MCP server using Streamable HTTP mode shared a single Entra ID identity across all connected clients. An unauthenticated attacker with network access gained full Azure environment access through command injection via the
azmcp-extension-aztool — a confused deputy scenario amplified by the protocol's assumption of a single shared identity per server. - OX Security systemic vulnerability (April 2026): Four attack families were documented across all four official Anthropic SDKs (Python, TypeScript, Java, Rust): unauthenticated UI injection, config file manipulation (
.cursor/rules,CLAUDE.md,mcp.json), model self-modification of its own config, and typosquatting on npm/PyPI. Anthropic's response: the behavior is "by design" and sanitization is "the developer's responsibility." - EscapeRoute filesystem bypass: A documented path traversal vulnerability that bypasses MCP filesystem restrictions, allowing agents to read files outside intended boundaries.
Microsoft's own red-team testing, published in their Agent Governance Toolkit documentation, found a 26.67% policy violation rate when safety instructions relied on prompts alone — meaning over one in four tool invocations violated intended safety boundaries when guardrails were text instructions to the model rather than enforced infrastructure.
Twenty-six percent of tool calls violated policy when safety was a prompt rather than a gate. That number is the argument for infrastructure-layer governance.
The Governance Patterns That Work
Several patterns are emerging that address the sprawl. They map to three layers: infrastructure, policy, and discovery.
Layer 1: MCP Gateways
An MCP gateway sits between the host (the AI application) and the upstream MCP servers. It performs the same functions API gateways performed during the REST boom: centralized authentication, rate limiting, auditing, and request filtering. Four implementations are actively developed:
| Gateway | Approach | Key Differentiator |
|---|---|---|
| Microsoft MCP Gateway | Policy engine between agent intent and tool execution | Allow/deny/require-approval per call |
| Envoy AI Gateway | Infrastructure-grade L7 proxy | First-class MCP in Envoy ecosystem |
| Tyk MCP Gateway | Reverse proxy with semantic tool filtering | BM25 semantic filtering: expose 3–5 tools per query instead of all |
| IBM ContextForge | Enterprise context assembly | Aggregates multiple MCP servers into governed context |
The Tyk approach of semantic tool filtering addresses a problem unique to MCP: most servers expose dozens or hundreds of tools, and an LLM will attempt to use whichever tools it discovers regardless of relevance. Exposing 3–5 contextually relevant tools per query reduces both the attack surface and the likelihood of the model choosing a destructive operation.
Layer 2: Policy Engines and Hardening Frameworks
Gateways handle network-level governance. Policy engines handle the logic: who can call which tool, under what conditions, with what parameter constraints.
Microsoft's Agent Governance Toolkit (AGT) is the most developed. AGT sits between the agent's intent and the tool execution, evaluating each tool call against configurable policies. The toolkit supports allow, deny, and require-approval actions per tool invocation — turning the advisory destructiveHint annotations into enforceable rules.
The COMPEL framework provides a 12-control hardening baseline mapped to NIST CSF 2.0. It addresses all seven documented MCP threat classes with layered defenses: transport encryption, authentication, tool-scope restrictions, audit logging, and human-in-the-loop requirements for destructive operations.
Advisory hints and prompt-only safety instructions fail at scale. Infrastructure-layer enforcement — gateway, policy engine, or both — is how production MCP deployments govern tool access.
Layer 3: Discovery and Inventory
Before governing MCP servers, teams need to know which ones exist. Qualys TotalAI and mcp.so serve different halves of this problem: Qualys discovers and fingerprints MCP endpoints running in production environments that security teams did not know about (the "shadow IT for AI" problem), while mcp.so and mcpmarket.com catalog public servers for developer discovery.
The Agentic Community MCP Registry attempts a governance layer on top of discovery, providing a federated registry where servers carry attestations — security audits, compliance certifications, and known vulnerability disclosures. This is the Docker Hub model applied to MCP: a central catalog with optional trust signals.
Honest Assessment
| Dimension | State Today | State in 12 Months |
|---|---|---|
| Authentication | Optional in spec; 53% static secrets | OAuth 2.1 for HTTP widespread; STDIO still unauthenticated |
| Authorization | No protocol-level model | Gateway-based RBAC per tool call (AGT, Tyk) |
| Discovery | Ad hoc registries, no attestation | Federated registries with security attestations |
| Tool filtering | All-or-nothing exposure | Semantic filtering in gateways becomes standard |
| Audit logging | Not in spec; manual per-server | Gateway-level structured audit logs |
| Server trust | Blind trust of recommended servers | Explicit allowlists replace recommendation chains |
The comparison to API governance is instructive but incomplete. API gateways succeeded because the consumer was deterministic code that returned verifiable error codes. MCP gateways face a harder problem: the consumer is an LLM that interprets responses, may follow adversarial instructions embedded in tool descriptions, and cannot reliably distinguish between a legitimate failure and a social engineering prompt.
This is why prompt-only safety instructions fail. Microsoft's 26.67% violation rate under prompt-only conditions is not a fixable prompt engineering problem — it is a structural property of non-deterministic consumers operating without infrastructure-level gates. The fix is the same pattern that worked for APIs, adapted for agents: central gateways, enforceable policies, and structured audit trails.
Actionable Takeaways
Deploy an MCP gateway before you have 10 servers. The gateway pattern works at any scale. Microsoft AGT and Envoy AI Gateway are available today. The cost of adding a gateway at 3 servers is a configuration change. The cost at 30 servers is a security incident.
Implement tool-level allowlists, not server-level trust. Connecting to a GitHub MCP server means trusting everything it exposes — repositories, issues, pull requests, code search, and admin functions. Use a gateway or policy engine to expose only the tools your agent needs, not the entire server manifest.
Replace static secrets with OAuth, or wrap them in a vault. The 53% static-secrets statistic is a credential-stuffing invitation. If OAuth is not available for a server, use a secrets manager (HashiCorp Vault, AWS Secrets Manager) and inject credentials at runtime. Never commit MCP configuration files with embedded tokens.
Audit what your agents connect to. Run Qualys TotalAI or equivalent discovery against your development and production environments. The "shadow IT for AI" problem — MCP servers running that no one in security knows about — is the same shadow API problem that took three years to solve in the REST era. Solve it this time in three months.
Disable server recommendation chains by default. Configure your MCP host to ignore serverRecommendations from connected servers. Trust propagation without a trust model is how confused-deputy attacks scale from one compromised server to an entire environment. Explicit allowlists are the correct default.
Treat destructiveHint as a configuration signal, not a safety boundary. Use it to route destructive tool calls through a gateway that enforces human-in-the-loop approval. Do not rely on the LLM to respect the hint — Microsoft's data shows it will not, over one in four times.