Topic starter
20/08/2026 5:50 pm
TL;DR: MCP is not a single product but a fragmented ecosystem of servers, clients, registries, gateways, and agent frameworks that changes how tools, transport, and authentication are governed, according to Obot. The governance problem is no longer just deployment choice; it is controlling who or what can invoke tools, under what policy, and with what audit trail.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “The Practical MCP Tools Landscape — Who’s Building What, and How to Pick the Pieces”.
Key questions
Q: What breaks when MCP servers are connected without a trusted control plane?
A: Discovery and execution become the same decision, which removes the ability to review who published a tool, who can call it, and what trail exists after use.
Q: Why do remote MCP servers create more identity governance risk than local ones?
A: Remote MCP servers expand the potential client population from a small local set to any client that can reach the network endpoint.
Q: What are the signs that MCP registry governance is too broad?
A: If development tools appear in production discovery results, if agents can enumerate servers they should not be able to use, or if metadata is too vague to explain why a tool was visible, the registry boundary is too loose.
Practitioner guidance
- Define the MCP trust boundary before deployment Map which layer owns discovery, which layer enforces policy, and which layer records audit evidence for every tool call.
- Require authenticated remote access for any non-local server Do not allow clients to bind to remote MCP services unless OAuth or an equivalent identity mechanism is in place and reviewable.
- Separate registries from enforcement points Use registries for discovery only and place authorization, rate limits, and logging in the gateway or control plane.
Bottom line: MCP creates a distributed governance problem because tool access is now split across servers, clients, registries, gateways, and agent frameworks.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:30 pm
MCP governance is now a distributed identity problem, not a server-selection problem. The article makes clear that servers, clients, registries, gateways, and agent frameworks each create a different control point. That means identity policy cannot live in one team’s tooling decision and still claim coverage. The practical conclusion is that MCP adoption should be governed as a chain of trust, not a catalog of products.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations use gateways or registries to control MCP access?
A: Gateways should control access because they can enforce policy, proxy calls, and preserve audit evidence. Registries are still useful, but only for discovery and curation. The practical distinction is simple: if a component cannot stop a call, it should not be treated as the security boundary for MCP usage.
👉 Read our full editorial: MCP tooling fragments identity governance across servers and agents