Notifications
Clear all
Topic starter
19/08/2026 3:54 pm
TL;DR: MCP servers inherit the same production problems containers once exposed, including isolation, egress control, identity attribution, ingress policy, and observability, according to Stacklok. The governance gap is not protocol design but runtime control, because enterprise IAM and platform teams need a substrate that can enforce per-workload identity, scope, and auditability.
NHIMG editorial — based on content published by Stacklok: Why Kubernetes Is the Right Platform for Running MCP Servers in Production
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: How should teams govern MCP servers once they are exposed through Kubernetes CRDs?
A: Treat MCP servers like any other governed identity surface.
Q: Why do shared service accounts create problems in MCP deployments?
A: Shared service accounts make the backend see one identity for many users, so attribution disappears and privilege usually expands to make the account usable everywhere.
Q: What breaks when MCP servers can reach internal services directly?
A: A single untrusted tool call can become a pivot into cloud metadata, localhost services, or internal admin planes.
Practitioner guidance
- Map every MCP server to a distinct workload identity Issue dedicated Kubernetes service accounts for each MCPServer resource and federate them through enterprise identity so request attribution stays per workload rather than per environment.
- Enforce egress allowlists at the namespace boundary Use NetworkPolicy to limit each MCP server to the specific databases, APIs, or internal services it genuinely needs, and deny all other outbound traffic by default.
- Apply pod hardening as a baseline control Run MCP servers as non-root, drop all Linux capabilities, enable a read-only root filesystem, and enforce a default seccomp profile across the fleet.
What's in the full article
Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:
- Detailed examples of Kubernetes manifests for MCPServer deployment and policy enforcement
- Operator lifecycle behaviour for provisioning, cleanup, and namespace-scoped management
- Implementation detail for the ToolHive gateway, registry, and embedded authorisation flow
- Observed token reduction figures and deployment-specific performance characteristics for vMCP
👉 Read Stacklok's analysis of why Kubernetes is the right platform for MCP servers in production →
Kubernetes for MCP servers: what changes in production governance?
Explore further
19/08/2026 4:30 pm
Kubernetes is becoming the default control plane for MCP governance because protocol-level integration is not enough. The article correctly separates packaging from operations. MCP standardises how agents talk to tools, but it does not define isolation, egress policy, identity attribution, or auditability. That means the real security question is not whether MCP works, but whether it can be operated inside a control plane that already enforces runtime governance.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why workload identity governance fails when server identity is shared or opaque.
A question worth separating out:
Q: What is the difference between Kubernetes governance and MCP protocol controls?
A: MCP controls how agents and tools speak to each other, while Kubernetes governs where the server runs, what it can reach, and how its identity is enforced. Protocol controls do not replace runtime controls. Production security depends on both layers, but the operational authority sits in the substrate.
👉 Read our full editorial: Kubernetes makes production MCP servers governable at scale
