Kubernetes makes production MCP servers governable at scale

At a glance

What this is: This is a comparison of why Kubernetes is the right production substrate for MCP servers, with the key finding that MCP’s protocol layer does not solve isolation, identity, networking, or observability on its own.

Why it matters: It matters because IAM, platform engineering, and security teams need to govern MCP servers like production identities and workloads, not like disposable integrations.

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.

👉 Read Stacklok's analysis of why Kubernetes is the right platform for MCP servers in production

Context

Model Context Protocol solves tool and data integration for AI systems, but it does not solve the production governance problems that determine whether those systems can be operated safely at scale. For MCP servers, the same control questions that shaped container platform adoption still apply: isolation, network reach, identity attribution, ingress policy, and observability. Stacklok’s argument is that Kubernetes already provides those controls in one place, which is why MCP server governance should be treated as a workload and identity problem, not a protocol novelty.

That framing matters for IAM and platform teams because shared credentials, weak namespace boundaries, and unclear request attribution create the same kind of operational blind spots seen in broader NHI estates. The practical comparison is not between MCP and containers, but between ad hoc deployment and governed runtime control. Teams that already run Kubernetes have a control plane they can extend, rather than a new layer they need to invent.

Key questions

Q: How should teams govern MCP servers once they are exposed through Kubernetes CRDs?

A: Treat MCP servers like any other governed identity surface. Use reusable CRDs for shared OIDC, telemetry, and tool permissions, assign ownership to each server or catalog entry, and review who can add backends or widen discovery. The goal is to keep identity, observability, and authorization controls stable as the fleet grows.

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. That pattern turns a convenience shortcut into a governance gap. It also creates a high-value credential that can be reused across tasks and backend systems.

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. Once that happens, the server is no longer just retrieving content. It is acting as a bridge from user input into protected infrastructure, which dramatically increases blast radius.

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.

Technical breakdown

Namespace isolation and pod boundaries for MCP servers

MCP servers inherit the same multi-tenant risks as any containerised workload. Namespace isolation separates teams and environments, while pod-level boundaries keep runtime state, environment variables, and process space from being shared across servers. That matters when one server handles sensitive backend access and another serves lower-trust document workflows. A compromise in one pod should not become implicit reach into adjacent workloads. Kubernetes adds security context controls such as non-root execution, dropped capabilities, read-only filesystems, and seccomp, which reduce what an attacker can do after code execution. These are containment controls, not optional hardening extras.

Practical implication: treat every MCP server as a separately governed workload and enforce pod security controls by default.

NetworkPolicy, ingress, and tool call containment

The biggest production risk in MCP is often outbound reach, not inbound exposure. If a compromised MCP server can call any destination the cluster can reach, the blast radius is defined by network reach rather than business need. Kubernetes NetworkPolicy lets teams allowlist only the specific egress paths a server requires, such as one database host on one port. Ingress controls and gateway layers add policy enforcement before requests reach the server. This is the difference between a server that is reachable and a server that is governable. For MCP, network policy is a security boundary, not a documentation aid.

Practical implication: define egress allowlists for each MCP server and block all other traffic paths.

OIDC federation, service accounts, and request attribution

MCP deployments fail fast when they rely on shared service account tokens. A single credential used by every request hides who authorised the action, which agent initiated it, and whether the invocation was in scope. Kubernetes service accounts plus OIDC federation allow per-workload identity, while projected short-lived tokens make credentials more auditable and less reusable. When integrated with enterprise identity providers, the request path can carry an authenticated principal through to the tool invocation. That creates the audit trail operators need, especially when multiple users or agents can trigger the same backend action. Identity without attribution is not governance.

Practical implication: replace shared tokens with federated workload identity and preserve principal-level attribution end to end.

NHI Mgmt Group analysis

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.

Shared credentials are the wrong identity model for MCP servers. A service account token reused across requests collapses the very attribution that IAM and IGA teams need. Per-request identity only becomes meaningful when the server identity, the user identity, and the workload identity can be distinguished in logs and policy decisions. Without that separation, the audit record names a server, not the principal who caused the action.

Network reach is the hidden blast-radius variable for MCP workloads. The article makes the right operational point: a server that can reach anything the cluster can reach is not constrained by intent. Kubernetes NetworkPolicy turns outbound access into an explicit governance decision rather than a developer habit. For identity teams, that is the difference between tool scope that can be reviewed and tool scope that can only be assumed.

Runtime containment now matters more than deployment convenience for AI tool infrastructure. MCP servers may be easy to install, but production readiness depends on namespace boundaries, non-root execution, read-only filesystems, and declarative lifecycle management. That is a familiar NHI pattern: the more automation and integration increase, the more the governance burden shifts to control consistency and evidence. Practitioners should treat MCP as part of the workload identity estate, not as an application plugin.

Identity and platform teams should stop evaluating MCP as a standalone protocol and start evaluating it as an operating model. The durable question is whether an organisation can reconcile workload identity, network policy, ingress control, and observability under one governed runtime. If it cannot, MCP deployments will reproduce the same invisible access patterns that already complicate NHI oversight elsewhere.

From our research:

• 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.
• For a broader threat lens, see 52 NHI Breaches Analysis, which shows how identity gaps repeatedly turn into real-world exposure.

What this signals

Kubernetes-native control is now the practical baseline for MCP governance. The organisations most likely to operate MCP safely are the ones that already treat workload identity, namespace boundaries, and egress policy as part of identity governance rather than as platform extras. That is why the conversation is shifting from protocol adoption to runtime accountability.

Runtime governance for MCP will converge with broader NHI lifecycle management. If a server can be created, scoped, rotated, and removed declaratively, then the same governance logic that applies to service accounts, API keys, and certificates can be extended to MCP servers without inventing a new discipline. Teams should align this work with the Ultimate Guide to NHIs and their workload identity standards.

For practitioners

• 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.
• Require declarative lifecycle management for every server Register MCP deployments as version-controlled resources so images, namespaces, permissions, and ownership are all visible before a server reaches production.
• Preserve end-to-end attribution in the request path Ensure the identity carried from user authentication through gateway enforcement to backend tool execution remains visible in logs, traces, and access decisions.

Key takeaways

• MCP standardises tool connectivity, but it does not solve production governance on its own.
• Identity attribution, egress control, and pod hardening are the controls that determine whether an MCP server is governable.
• Teams that already run Kubernetes can extend their existing runtime controls to MCP instead of building a separate control plane.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Network Policy: A Kubernetes Network Policy is a rule that controls which pods can communicate with each other and with external endpoints. It is a policy object, not a complete security boundary, and its effectiveness depends on accurate labels, current topology, and continuous maintenance as the cluster changes.
• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Per-Request Attribution: Per-request attribution is the ability to trace each action back to the principal or workload that initiated it. For MCP, this means the tool call should carry enough identity context to show who authorised the action, which server executed it, and whether the request stayed within scope.

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

👉 Stacklok's full post covers the Kubernetes operator model, gateway enforcement, and identity federation details

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.