Topic starter
18/08/2026 2:33 pm
TL;DR: Ungoverned MCP servers are already spreading through developer environments, and Stacklok argues that security teams need registry, policy, audit, and isolation controls before the footprint scales further. The governance gap mirrors the early container era, when teams that delayed standardisation paid the remediation tax.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Your developers are already running MCP servers you don’t know about”.
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 ungoverned MCP servers create compliance and security risk?
A: Because they introduce machine-level access paths without the controls normally used to approve, log, and limit that access.
Q: What are the signs that MCP governance is failing?
A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose.
Practitioner guidance
- Define an MCP server inventory process Create a single authoritative catalog for every MCP server, including owner, environment, connected tools, and approved use cases.
- Centralise access decisions through a gateway Enforce scoped runtime access so teams do not implement server-by-server policy differently across products or departments.
- Require structured logging for tool calls Record who initiated each call, what was requested, and what was returned so audit teams can reconstruct activity later.
Bottom line: Ungoverned MCP servers create a control gap because teams cannot reliably inventory them, scope access to them, or prove what they did.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:20 pm
MCP server sprawl is a non-human identity governance problem before it becomes an AI problem: the first failure is not model behaviour, it is uncontrolled service-level access. Once teams can deploy servers faster than governance can enumerate them, the organisation loses the ability to assign ownership, scope permissions, or prove auditability. The implication is that MCP governance belongs with NHI and platform controls, not only with AI enablement teams.
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 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How should teams govern MCP server installation in developer environments?
A: Treat MCP server installation as a controlled enrollment step, not a convenience action. If the installer can collect API keys, register tools, or establish persistent session authority, then approval, logging, and ownership need to happen at install time. The key control is deciding who can add trusted tools before they become part of daily developer workflow.
👉 Read our full editorial: MCP server governance is lagging behind developer adoption