MCP security best practices for Kubernetes teams

At a glance

What this is: This how-to shows how Kubernetes teams can apply existing cluster primitives to secure MCP servers with isolation, workload identity, gateway policy, observability, and registry governance.

Why it matters: It matters because MCP security is quickly becoming an identity governance problem for both non-human and agent-driven access paths, not just a deployment problem.

Context

MCP security is the problem of governing tool access as an identity and policy boundary, not as a loose collection of server deployments. In Kubernetes environments, that means every MCP server needs isolation, identity, and audit controls that limit how far a compromise can move.

The article's core point is practical: teams do not need to invent new infrastructure to secure MCP. They can apply namespace boundaries, network policy, workload identity, gateway enforcement, and structured telemetry to make each tool call traceable and revocable.

For IAM and platform teams, the real question is whether tool access is managed with the same discipline as other high-risk access paths. If the answer is no, MCP sprawl becomes another unmanaged access layer with weak accountability.

Key questions

Q: What breaks when organisations let agents and MCP servers run without isolation?

A: Without isolation, an organisation loses the ability to contain the agent’s reach, observe its actions, and limit blast radius when something goes wrong. That means sensitive data exposure, unreviewed tool calls, and unclear post-incident reconstruction become more likely. Isolation is the control that turns agent activity into something security teams can bound, inspect, and govern.

Q: Why do hardcoded credentials create governance risk for MCP access?

A: Hardcoded credentials only prove that a secret was presented. They do not show which workload invoked the call, which user authorised it, or whether the action stayed within policy. That leaves teams with a credential trail instead of an identity trail, which is too weak for governed MCP access.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Technical breakdown

Kubernetes namespace and network policy isolation for MCP servers

Each MCP server should be treated as a separately governed execution boundary, not as a shared utility tier. In Kubernetes, namespace segmentation and default-deny NetworkPolicy rules reduce the blast radius if one server is compromised. The important detail is that isolation is not theoretical here: the attacker's next move is usually lateral movement to adjacent services, followed by privilege escalation or data exfiltration. Resource limits also matter because a runaway or malicious server can become a noisy neighbor or a stepping stone for denial of service.

Practical implication: Use namespace isolation and explicit deny-by-default network policy so a compromised MCP server cannot reach adjacent services by accident or design.

Why workload identity is stronger than API keys for MCP

Credential-based authentication only proves that something had a secret, not which workload or user authorized the action. For MCP, the better model is workload identity, where the server presents a cryptographically verifiable identity that is bound to the workload and rotated automatically. Pairing that with user identity passthrough creates an identity trail, not just a credential trail. This is why the article frames hardcoded API keys as insufficient: they obscure provenance, ownership, and policy context at the moment of tool use.

Practical implication: Move MCP authentication to workload identity and identity propagation so every tool call can be tied to both the workload and the initiating user.

Gateway enforcement, tool-level authorisation, and observability

A single gateway gives teams one enforcement point for access control, rate limiting, and audit logging across all MCP servers. That matters because MCP exposes capability at the tool level, so server-level permission alone is too coarse to govern real risk. Structured telemetry should capture user, agent session, tool name, inputs, outputs, latency, and result. Without that, teams can see that a call happened but cannot reconstruct why it happened or whether it fit policy.

Practical implication: Enforce policy at the gateway, authorise at the tool level, and log complete spans so investigators can reconstruct each MCP action end to end.

Threat narrative

Attacker objective: The attacker aims to use one compromised MCP server as a launch point for broader internal access, data theft, and uncontrolled tool execution.

1. Entry occurs when an MCP server is deployed without governed isolation or registry review, giving it a path into internal services beyond its intended scope.
2. Credential exposure or weak authentication turns a server into an untrusted access point, and the article warns that hardcoded API keys do not provide enough identity context to govern tool use.
3. Escalation follows when the compromised server can reach adjacent services, invoke higher-value tools, or consume resources without explicit policy boundaries.
4. Impact is broader tool abuse, lateral movement, and data exfiltration across the Kubernetes environment, with little ability to attribute or revoke access cleanly.

Breaches seen in the wild

• 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

MCP security is an identity governance problem before it is a platform problem. The article is right to frame MCP servers as access points into internal systems, because each tool call creates an authorisation decision that must be scoped, traced, and revoked. That places MCP squarely in the governance domain where NHI, workload identity, and policy enforcement converge. The practitioner conclusion is that tool access must be managed as governed identity, not as ad hoc integration.

Namespace isolation is the first meaningful boundary because it limits identity blast radius. Once an MCP server is compromised, the question is not whether the server was reachable, but how far its access could propagate. Kubernetes network policy and namespace boundaries provide the control surface that keeps one server from becoming a cluster-wide trust failure. The practical takeaway is to design containment around the service identity, not around deployment convenience.

Credential-based MCP access creates trust debt that workload identity reduces but does not eliminate. Hardcoded API keys tell you a secret was used, not whether the use was authorised, attributable, or still within policy. That makes workload identity the correct baseline because it binds access to the workload and the session rather than to a reusable secret. The implication for teams is to stop treating credentials as the governance model and start treating them as an implementation detail.

Tool-level policy is the real control plane for MCP. A gateway that authorises server access without checking the tool being called leaves the highest-risk decision ungoverned. MCP changes the unit of control from the server to the tool, which is why access control, rate limiting, and audit logging need to converge at a single enforcement point. The conclusion for practitioners is that coarse allowlists are no longer enough once agents and users can invoke distinct capabilities through the same server.

Governed registries prevent MCP sprawl from turning into unmanaged shadow access. The article's registry point is not just about inventory, but about deciding which servers are allowed to become part of the identity perimeter at all. That is the same governance pattern NHIs require across service accounts and tokens: approved path first, everything else blocked or contained. Practitioners should treat registry control as a lifecycle gate, not a catalog convenience.

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.
• Read next: NHI Lifecycle Management Guide

What this signals

MCP creates a new identity perimeter inside the Kubernetes cluster. The operational challenge is no longer just whether a server runs, but whether its tool access is bounded, attributable, and revocable like any other high-risk identity path. Teams that already manage namespaces, workload identity, and policy can extend those controls, but they need to treat MCP as a governed access layer rather than a convenience integration.

Ephemeral credential trust debt: MCP environments accumulate risk when access is easier to obtain than to explain. The more teams rely on reusable credentials and untracked server sprawl, the more they lose the ability to answer basic governance questions about who did what, when, and under which policy. That is the boundary where identity operations and platform engineering have to converge.

For practitioners

• Define a namespace per MCP server Assign each server to its own namespace and pair it with default-deny ingress and egress policies so every allowed path is explicit.
• Replace shared secrets with workload identity Use workload identity so the server presents a verifiable workload identity instead of a hardcoded API key that can be copied or leaked.
• Centralise policy at the gateway Move tool-level access control, rate limiting, and audit logging into one gateway so enforcement is consistent across all MCP servers.
• Instrument every tool call for observability Capture user, agent session, tool name, inputs, outputs, latency, and result in structured telemetry so you can reconstruct the full action chain.
• Use a governed registry as the approved path Require teams to deploy MCP servers from a curated registry and block unregistered servers from becoming part of the production access path.

Key takeaways

• MCP security is fundamentally about constraining tool access so one server cannot become an ungoverned entry point into internal systems.
• Kubernetes already provides the primitives needed to do this, but they only work when namespaces, network policy, workload identity, and gateway enforcement are applied together.
• Registry governance and full observability decide whether MCP remains a managed access layer or turns into shadow infrastructure with weak accountability.

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.
• 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.
• Tool-level Authorization: Tool-level authorization is the practice of checking permissions on each discrete action a client asks an MCP server to perform. It matters because LLMs can generate dynamic requests, so access control must be enforced where the action is executed, not only where the request is formed.
• Authentication Trail: An authentication trail is the record of login attempts, access events, and related identity activity across systems. It lets defenders trace who attempted access, when it happened, and from where. In incident response, this trail is essential for reconstructing attacker activity, identifying compromise points, and supporting containment and forensic analysis.

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.