TL;DR: MCP server sprawl is creating fragmented auth, uneven vetting, and hidden blast radii, according to Obot’s analysis of enterprise AI deployments and practitioner experience. The core issue is not routing alone, but that unmanaged MCP integrations turn tool access, credential handling, and policy enforcement into per-server decisions that no IAM programme can reliably scale.
NHIMG editorial — based on content published by Obot: Understanding the Importance of MCP Gateways for Enterprise AI
By the numbers:
- 52% of public MCP servers are effectively dead, creating a maintenance and trust problem for enterprises adopting the protocol.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: What breaks when MCP servers are added without a gateway?
A: Authentication, authorization, and audit responsibilities fragment across servers, which makes policy inconsistent and revocation slow.
Q: Why do MCP servers create new risk for IAM teams?
A: MCP servers can collapse the boundary between human intent and machine execution.
Q: How do you know if MCP security controls are actually working?
A: You know MCP controls are working when untrusted endpoints are blocked, privileged tool calls are minimal, and audit logs show only approved commands and data flows.
Practitioner guidance
- Inventory every MCP server as a governed NHI asset Record owner, upstream systems, credential type, tool scope, and retirement trigger before approving any server for production use.
- Centralize authentication and authorization at the gateway layer Use one dispatch layer for OAuth validation, credential injection, RBAC or ABAC policy enforcement, and per-user revocation across the fleet.
- Inspect tool metadata before it reaches model context Normalize and allowlist tool descriptions, then block servers that inject unreviewed instructions or ambiguous tool labels into the context window.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step gateway architecture for centralizing OAuth, routing, and policy enforcement across MCP servers
- Practical guidance on vetting community MCP servers before they touch production systems
- Deployment considerations for STDIO, multi-server environments, and catalog-based governance models
- Examples of how the dispatch layer can handle credential injection and per-user revocation
👉 Read Obot's analysis of MCP gateways, sprawl, and enterprise AI governance →
MCP sprawl and gateway governance: are your controls keeping up?
Explore further
MCP gateways are becoming the identity control plane for AI tool access. The core issue is not whether MCP is useful, but whether enterprises can govern many identity-bearing integrations without fragmenting auth, audit, and revocation across every server. Once tool access is distributed, security teams lose the single enforcement point they need for consistent lifecycle control. The practical conclusion is that MCP should be treated as governed identity infrastructure, not as an isolated developer convenience.
A few things that frame the scale:
- 52% of public MCP servers are effectively dead, creating a maintenance and trust problem for enterprises adopting the protocol, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why server-level governance gaps keep reappearing.
A question worth separating out:
Q: Who is accountable when a malicious MCP server exposes enterprise data or actions?
A: Accountability sits with the organisation operating the agent, the team approving the server, and the owners of the connected systems. The important governance question is whether provenance checks, runtime policy, and audit logging were in place before the server was trusted. If they were not, the failure is shared and preventable.
👉 Read our full editorial: MCP gateways are becoming the control plane for enterprise AI access