Topic starter
27/08/2026 8:35 am
TL;DR: MCP moved from niche integration layer to enterprise infrastructure in under two years, with more than 10,000 active public servers and broad exposure risks around typosquatting, tool poisoning, and invisible delegated access, according to Unixi. The core issue is that existing IAM and authorization models can record sign-ins without governing what an MCP server can actually reach.
Editorial analysis by NHI Mgmt Group, based on content published by Unixi: “Shadow MCP: The Servers Nobody Approved”.
Key questions
Q: What breaks when MCP servers run locally without governance?
A: Local MCP servers inherit workstation privileges, which means they can read plaintext secrets, access user-scoped tools, and operate without a central approval point.
Q: Why do shadow MCP servers create higher risk than ordinary shadow IT in AI environments?
A: Shadow MCP servers matter because they let an AI assistant act, not just observe.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Inventory every MCP server and its owner Record approved servers, local servers, and registry-sourced servers in the same inventory so you can see which tools have corporate reach and who is accountable for each one.
- Gate server adoption before any delegated grant Require review and approval before a user or agent can connect a server to corporate data, especially where the server can reach databases, repositories, or internal APIs.
- Track identity-to-tool connections continuously Log which identity holds which server connection, what resources that server can reach, and when the approved behaviour changes after onboarding.
Bottom line: MCP server security is really an identity governance problem because sign-in visibility does not describe tool reach.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
27/08/2026 8:35 am
Identity governance for MCP must start at server adoption, not at sign-in. The article shows that a valid login does not tell you which server was installed, what it can reach, or whether it should have been approved in the first place. That breaks the old assumption that authentication visibility is enough to explain delegated access. Practitioners should treat MCP server adoption as a governed access event, not a passive integration choice.
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 block local MCP servers or govern them differently?
A: Blocking may be appropriate for high-risk environments, but most organisations will need to govern local MCP servers rather than assume they can eliminate them. The decision should follow the value of the use case, the sensitivity of the connected systems, and the maturity of secret handling. If local execution is allowed, it needs compensating controls and strict package approval.
👉 Read our full editorial: MCP server security exposes the gap in identity governance