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.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “Why Kubernetes Is the Right Platform for Running MCP Servers in Production”.
Key questions
Q: What breaks when MCP servers share service account tokens in production?
A: Shared service account tokens collapse attribution, so every tool invocation appears to come from the same server regardless of which user or workflow triggered it.
Q: Why do MCP servers need Kubernetes network policy instead of developer conventions?
A: Developer conventions do not stop a compromised server from reaching adjacent systems.
Q: How should teams evaluate an MCP server before production use?
A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions.
Practitioner guidance
- Harden MCP server runtime boundaries Run each MCP server in its own namespace and pod, with non-root execution, dropped capabilities, and a read-only filesystem to limit post-compromise movement.
- Enforce egress allowlists per server Use NetworkPolicy to constrain each MCP server to the exact backends and ports it legitimately needs, and deny broad cluster or internet reach by default.
- Replace shared credentials with federated workload identity Issue each MCP server a dedicated service account and federated OIDC or SPIFFE-backed identity so tool calls remain attributable and short-lived.
Bottom line: MCP servers expose the same operational gaps that containers exposed earlier, especially around isolation, egress, identity, and observability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:30 pm
Kubernetes is not just a convenient runtime for MCP servers, it is the governance boundary the protocol itself lacks. MCP standardises tool connectivity, but standardisation does not equal production control. The article shows that the same runtime primitives that solved container governance now map directly onto MCP servers, which means platform teams should treat MCP as a workload-class problem rather than a protocol novelty.
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.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is the difference between shared service credentials and federated workload identity for MCP?
A: Shared service credentials identify the server only once and then blur every downstream action into that same identity. Federated workload identity gives each server a distinct, short-lived, and auditable credential path, so the platform can tie a tool invocation back to a specific workload and authorisation decision.
👉 Read our full editorial: Kubernetes makes production MCP servers governable at scale