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.
At a glance
What this is: This is a governance analysis of why Kubernetes is the operational substrate Stacklok argues MCP servers need in production, with the key finding that the protocol solved integration but not runtime control.
Why it matters: It matters because IAM, platform, and NHI teams need a control plane that can enforce per-workload identity, network scope, and auditability before MCP use spreads beyond pilots.
Context
MCP servers create a familiar governance problem in a new runtime: the protocol can connect tools and systems, but it does not by itself solve isolation, network reach, identity attribution, ingress policy, or observability. In practice, that means production teams still need a substrate that can enforce controls at the workload layer rather than relying on developer convention.
Stacklok's core argument is that Kubernetes already provides the primitives needed to govern MCP servers the way enterprises govern other production workloads. Namespace boundaries, NetworkPolicy, service accounts, OIDC federation, and GitOps let platform teams apply control to identity, traffic, and lifecycle without building a separate MCP-specific control plane.
For IAM and NHI programmes, the important point is not that MCP is special but that it behaves like a governed workload with machine identity, delegated access, and traceable execution. That makes it a platform engineering problem as much as an application integration problem.
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. That breaks auditability, makes revocation harder, and weakens scope control because one credential can represent many distinct actions. Production governance needs per-workload identity, not a shared token model.
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. NetworkPolicy makes egress and ingress rules enforceable at the cluster layer, so each server can only talk to approved backends and ports. That containment is what keeps one broken workload from becoming a general-purpose pivot point.
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. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.
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.
Technical breakdown
Why MCP servers need namespace and pod isolation
MCP does not enforce isolation between servers, so a compromised deployment can inherit the same lateral movement risk containers once created. Kubernetes solves this by separating workloads into namespaces and pods, then constraining runtime behaviour with security contexts such as non-root execution, dropped capabilities, and read-only filesystems. Those controls matter because an exploited server still has to operate inside a limited process, filesystem, and network surface. Namespace isolation is organizational as well as technical: it lets teams align production, development, and trust boundaries without sharing runtime state.
Practical implication: Use Kubernetes namespaces, pod boundaries, and hardened security contexts to keep one MCP server failure from becoming a cluster-wide compromise.
How NetworkPolicy and gateway controls limit MCP blast radius
The central networking issue is outbound reach, not just inbound exposure. If an MCP server can reach every backend the cluster can reach, compromise turns into broad data and control-plane access. Kubernetes NetworkPolicy lets teams allowlist exact destinations and ports, while gateway layers centralize policy enforcement before tool traffic reaches the server. That combination is stronger than developer intention because it enforces the boundary declaratively. When paired with service mesh identity, the transport layer can verify which orchestrator or workload is allowed to call the server at all.
Practical implication: Define egress allowlists and edge enforcement for each MCP server instead of trusting application code to behave correctly.
Per-request identity depends on OIDC federation and workload identity
The identity problem in MCP is attribution. Shared service account tokens erase the link between a user, an agent workflow, and the tool invocation that actually happened. Kubernetes service accounts, federated OIDC tokens, and short-lived workload credentials restore that link by giving each server a distinct identity and scoping access to what that workload is allowed to do. In stronger deployments, SPIFFE-based workload identity extends the same idea across cluster and cloud boundaries. The practical effect is that logs, authorisation, and audit trails stop collapsing everything into one shared server identity.
Practical implication: Move from shared credentials to federated workload identity so every MCP action is attributable to a specific server and request path.
Threat narrative
Attacker objective: Use one compromised MCP server to reach adjacent systems, misuse delegated access, and erase attribution across tool calls.
- Entry occurs when an MCP server is deployed with broad network reach or shared credentials, giving an attacker a large starting surface if the server or its dependencies are compromised.
- Credential access becomes identity confusion when a shared service account token or reused credential lets every tool invocation appear to come from the same server.
- Escalation and lateral movement follow when that compromised server can reach adjacent systems without network policy or workload-scoped authorization.
- Impact is broader tool abuse, poor auditability, and the inability to prove which user or workflow triggered a sensitive action.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Shared service account identity is the wrong operating assumption for MCP at scale. The production failure is not merely weak authentication, it is identity collapse: logs, authorisation, and accountability all converge on the same credential. That undermines auditability for human-triggered workflows and becomes even more problematic as agentic tooling spreads through the same control plane.
Namespace boundaries, egress policy, and federated identity are the minimum viable control set for governed MCP. Those controls do not just reduce risk, they make MCP operationally legible to IAM, PAM, and platform teams. Without them, every tool call looks like a generic server action rather than an attributable, scoped, and reviewable identity event.
Identity blast radius is the named concept this article sharpens. An MCP deployment without workload-specific identity and network boundaries can turn one compromised server into a broad trust event. The implication is that governance must be designed around the blast radius of each workload, not around the existence of the protocol alone.
GitOps matters because it turns MCP from an opaque service into an inventoryable identity surface. Declarative manifests create the evidence trail that lifecycle governance requires, including what exists, where it runs, and who can modify it. Practitioners should expect MCP governance to be judged on the same standards as other production workloads: traceability, least privilege, and enforceable drift control.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Identity blast radius: MCP governance should be measured by how far one compromised server can reach, not by whether the protocol itself is authenticated. Namespace isolation, scoped network policy, and workload identity are the controls that shrink that blast radius before tool usage expands further.
Kubernetes changes the question from whether MCP can be deployed to whether it can be governed as infrastructure. For platform and IAM teams, the control objective is to make every server discoverable, attributable, and limited by default rather than inspectable only after an incident.
For practitioners
- 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.
- Manage MCP servers declaratively Deploy MCP servers through GitOps and the Kubernetes Operator model so every server has a manifest, version history, and automated cleanup on removal.
- Centralize ingress and tool authorization Put MCP traffic behind a gateway or service mesh that can enforce policy before a request reaches the server and record the invocation path for audit.
Key takeaways
- MCP servers expose the same operational gaps that containers exposed earlier, especially around isolation, egress, identity, and observability.
- Kubernetes provides the primitives to govern those gaps at the workload layer through namespaces, NetworkPolicy, service accounts, OIDC federation, and GitOps.
- Teams that treat MCP as declarative infrastructure can make tool use attributable and bounded, while teams that rely on shared credentials and manual setup will lose control quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | MCP servers depend on delegated machine identities and external integrations that can expand trust unexpectedly. |
| NHI-05 — Overprivileged NHI | The article centres on excessive reach through shared tokens and broad backend access. | |
| Recommendation — Inventory each MCP server as a governed non-human identity and bound its delegated access to the minimum required scope. Reduce MCP server privilege to the exact tools, namespaces, and backends each workload requires. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article discusses short-lived, rotatable workload credentials and the failure of shared tokens. |
| Recommendation — Manage MCP credentials as lifecycle-bound authenticators and eliminate shared secrets where possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Per-workload identity and scoped tool access are central to the governance model described. |
| Recommendation — Apply entitlement controls so every MCP server and tool call has a defined, reviewable authorization scope. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article highlights how broad MCP access turns compromise into pivot opportunities. |
| Recommendation — Map MCP blast-radius concerns to credential access and lateral movement paths in your detections. | ||
Key terms
- Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
- 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.
- 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.
- GitOps: GitOps is an operating model that uses Git as the authoritative record for infrastructure, deployment, and policy changes. Teams declare desired state in version-controlled files, then use automation to reconcile the live environment back to that state and preserve a clear change history.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org