Notifications
Clear all
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.
NHIMG editorial — based on content published by Stacklok: Your developers are already running MCP servers you don’t know about
By the numbers:
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create a bigger governance problem than ordinary third-party packages?
A: Because they sit inside an active decision layer.
Q: What breaks when MCP servers are not registered centrally?
A: Unregistered servers create shadow deployment.
Practitioner guidance
- Inventory every MCP server before expansion Create a mandatory registry process for all MCP servers, including owner, business purpose, environment, and approved tool set.
- Enforce runtime-scoped tool permissions Place MCP access behind a central policy point so every tool call is checked at runtime against explicit permissions.
- Treat secrets in MCP servers as revocable identity material Move credentials out of configuration files, track where they are used, and tie revocation to offboarding and ownership changes.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- The concrete registry and gateway workflow used to govern MCP server discovery and runtime access.
- The Kubernetes Operator deployment pattern for teams that want to operationalise MCP governance at scale.
- The make vs buy comparison showing the practical trade-offs between building, adopting, or waiting.
- The approval workflow and deployment sequence used when an MCP server is brought under control.
👉 Read Stacklok's analysis of how to govern MCP servers before sprawl grows →
MCP server sprawl: what IAM teams need to govern now?
Explore further
18/08/2026 3:20 pm
MCP server sprawl is really NHI sprawl with a newer interface: Each unmanaged server is an identity-bearing runtime that can act, call tools, and access data. The governance failure is not protocol adoption itself, but the absence of ownership, inventory, and enforceable access boundaries. Security teams should treat each server as a governed non-human identity rather than as a benign infrastructure component.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: What should teams do when an MCP server needs access to production tools or data?
A: Apply the same discipline you would use for privileged non-human access: scope the permissions, isolate the runtime, and require an audit trail for every action. If the server needs broad access, that access should be explicit, time-bound, and reviewable rather than ambient.
👉 Read our full editorial: MCP server governance is lagging behind developer adoption
