Topic starter
19/08/2026 3:26 pm
TL;DR: MCP server adoption creates a governance gap when tools are discovered through scattered URLs, public catalogs, and chat threads, because there is no authoritative source for approval status or access scope, according to Stacklok. The security issue is not discovery alone but whether registry filtering and claims-based authorization happen at the API layer, where AI agents inherit the same controls as users.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “MCP server governance starts with discovery”.
Key questions
Q: How should teams govern MCP servers once they are discovered?
A: Classify recurring MCP servers as managed access objects, not personal tooling.
Q: Why does hidden UI filtering not solve MCP access risk?
A: Because access can still be exercised through the API even when a server is hidden in the interface.
Q: What breaks when MCP servers are approved once but allowed to change later?
A: The original approval no longer describes the current access surface.
Practitioner guidance
- Define a canonical MCP inventory Consolidate approved server sources into one registry-backed list so teams stop relying on scattered URLs, wiki pages, and chat threads for tool discovery.
- Enforce claims-based visibility at the API Validate identity tokens on each registry request and filter tool exposure by role or group claims before any catalog data is returned.
- Separate discovery from authorization decisions Allow servers to be discoverable only after they are explicitly tagged for registry exposure, then gate their visibility with source-level claims.
Bottom line: MCP governance fails when discovery is scattered and no authoritative source records approval and access scope.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:10 pm
Discovery without authorization is not governance: a shared MCP URL list can tell users what exists, but it cannot prove who approved it or who may invoke it. That makes discovery a visibility layer, not a control layer, and the difference matters because a tool that is merely discoverable is functionally reachable. The implication is that MCP programmes need a canonical access decision point, not a better directory.
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.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How do AI agents change the way MCP catalog access should be controlled?
A: AI agents inherit the same catalog visibility as the user or service identity acting on their behalf, so any weakness in registry filtering also becomes an agent access problem. Teams should govern the catalog as an authorization surface, because discoverable tools are available to both humans and agents unless the API blocks them.
👉 Read our full editorial: MCP server governance starts with discovery and claims-based access