Topic starter
24/06/2026 7:13 pm
TL;DR: MCP Server fleets create authentication sprawl, uneven observability, and unclear authorization boundaries, according to Kong. AI access then requires separate governance decisions for each connection, which makes approval and audit work harder across production deployments.
Editorial analysis by NHI Mgmt Group, based on content published by Kong: “What Is an MCP Server? Architecture, Use Cases, and How to Get Started”.
Key questions
Q: Why do many MCP servers create more risk than a single development server?
A: Because scale turns a simple integration pattern into a distributed access problem.
Q: How should teams govern tool access differently from resource access in MCP?
A: Tools should be treated as state-changing actions and reviewed more strictly than resources, which are read-only context.
Q: What breaks when MCP servers are exposed without identity controls?
A: Without identity controls, anyone with a link, key, or copied credential can reach tools and data outside policy.
Practitioner guidance
- Inventory every MCP server as a governed identity surface Track server owner, purpose, connected systems, credential source, and exposed capability types so the fleet is visible before production use expands.
- Separate authorization by capability type Apply stricter approval and scoping to tools than to resources or prompts, and require explicit review for any capability that can change state.
- Centralize discovery through an approved registry Replace hardcoded server connections with an approved inventory so agents can only discover MCP servers that have been reviewed and authorised.
Bottom line: MCP servers make AI access more structured, but they also turn each connection into a separate governance decision that security teams must own.
Glossary terms: MCP Server, Capability Boundary, Capability Negotiation, MCP trust debt
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 21 hours ago by NHI Mgmt Group
25/06/2026 4:25 am
MCP governance is becoming an identity-plane problem, not an integration problem: Once AI applications consume many servers, each server becomes an access decision with its own credentialing, policy, and visibility requirements. That means the control model has to move from point-to-point integration management to governed non-human identity access. Practitioners should treat the server fleet as a distributed entitlement surface, not a developer convenience.
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.
- 71% of organizations use third-party APIs, according to Gartner’s 2024 data.
A question worth separating out:
Q: When should security teams require an MCP registry or gateway?
A: They should require one as soon as server count or business criticality makes manual allowlisting unreliable. A registry and gateway help centralize approved discovery, policy enforcement, and observability so agents cannot freely connect to unvetted servers or bypass fleet-wide controls.
👉 Read our full editorial: MCP servers create new governance gaps for enterprise AI access
This post was modified 21 hours ago by NHI Mgmt Group