MCP security best practices for Kubernetes teams

At a glance

What this is: This is a how-to analysis of MCP security in Kubernetes, with the key finding that container isolation, workload identity, gateway policy, and observability can turn MCP from an ungoverned access path into a controlled identity surface.

Why it matters: It matters because MCP servers behave like non-human identities with tool access, so IAM, PAM, and NHI teams need consistent controls for identity, policy, logging, and lifecycle management before sprawl creates blind spots.

👉 Read Stacklok's MCP security best practices for Kubernetes teams

Context

Model Context Protocol security becomes an identity governance problem the moment an MCP server can reach tools, data, or internal services on behalf of a user or agent. The article argues that Kubernetes already provides the core primitives needed to contain that access, but those primitives only work if they are applied as identity controls rather than generic infrastructure settings.

For IAM and NHI teams, the central challenge is not whether MCP servers can be deployed quickly. It is whether each server has bounded access, verifiable workload identity, and auditable tool-level policy so that the environment does not quietly accumulate an unmanaged access surface.

Key questions

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.

Q: Why do hardcoded credentials create the wrong trust model for MCP?

A: Hardcoded credentials prove only that a secret was used, not which workload or user authorised the action. For MCP, that creates an audit gap because tool use needs identity, context, and policy at the point of invocation. Verified workload identity and token exchange replace opaque credential reuse with traceable authorisation.

Q: What breaks when MCP access is not centrally enforced?

A: When MCP access is not centrally enforced, agents can bypass the sanctioned protocol and reach the same data through alternative connectors or direct application paths. That breaks policy consistency, weakens auditability, and leaves security teams with multiple uncontrolled routes to the same backend system.

Q: How do security teams decide whether MCP observability is enough?

A: MCP observability is enough only when it produces actionable evidence for ownership, scope, and session-level behaviour. If the telemetry cannot show who invoked a tool, which client initiated the call, and whether the action matched the approved workflow, then the organisation still lacks governable identity evidence.

Technical breakdown

Kubernetes namespace isolation for MCP server blast radius

The article treats each MCP server as a discrete execution boundary, which is the right starting point for non-human identity control. Namespace isolation, default-deny network policy, and explicit ingress and egress rules reduce the chance that a compromised server can move laterally or reach unintended services. Resource limits also matter because a runaway server can create availability impact even when it cannot exfiltrate data. The security value comes from making every exception visible and auditable.

Practical implication: assign each MCP server to its own namespace and enforce default-deny network policy before allowing any tool traffic.

Workload identity for MCP servers instead of hardcoded API keys

The article correctly rejects credential-based authentication as the governing model for MCP. Hardcoded API keys only prove that something acted, not which workload or which user authorised the action. SPIFFE and SPIRE give each server a cryptographically verifiable workload identity that can be rotated automatically, while token exchange preserves the human identity behind the session. That produces an identity trail rather than a credential trail, which is a much stronger basis for governance and investigation.

Practical implication: replace static secrets with workload identity and ensure every tool call carries both workload and user context.

Gateway policy, tool-level authorisation, and observability

A single enforcement point matters because MCP tool access is finer-grained than server access. Policy at the gateway can distinguish between reading a schema and executing a query, which is the level at which many real risks appear. Declarative policy also keeps authorisation reviewable rather than hidden in per-server configuration. OpenTelemetry then closes the loop by capturing who called what, from which session, with which inputs and outputs, so security teams can reconstruct behaviour instead of guessing after the fact.

Practical implication: centralise access control at the gateway, then instrument every tool call with session-linked telemetry.

Threat narrative

Attacker objective: The objective is to turn a single MCP foothold into broader internal access that bypasses ordinary application and identity checks.

1. Entry occurs when an MCP server is introduced into the environment as a new access path to internal tools and services.
2. Escalation happens if that server lacks namespace boundaries, network restrictions, or tool-level policy, allowing lateral movement and privilege abuse.
3. Impact follows when the server is used to reach adjacent systems, run unauthorized tools, or exfiltrate data through approved-looking interactions.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP security is really NHI governance with a new protocol surface. The article frames MCP servers as access points into internal systems, which places them squarely in the non-human identity domain. That means the governance question is not whether the server is convenient to deploy, but whether its identity, permissions, and lifecycle are managed with the same discipline applied to service accounts and workload credentials. Practitioners should treat MCP as an NHI control plane problem, not an integration convenience problem.

Hardcoded credentials are the wrong trust primitive for MCP because they collapse identity and authorisation into one opaque secret. A secret tells you that access happened, but not who approved it, which workload invoked it, or whether the call was within policy. That is a governance failure, not just a hygiene issue. The implication is that teams need identity trails and policy decisions at the point of use, not after the fact.

Gateway centralisation creates a governable policy surface, but only if the organisation accepts that tool-level access is the real unit of control. Server-level allow or deny decisions are too coarse for MCP because most risk appears inside specific tools, not the server as a whole. This is where NHI governance becomes more precise than traditional application control. Practitioners should structure policy around tool scope, not just server membership.

Runtime observability is part of identity governance, not just detection. If every tool call is tied to a workload, a user, and a session, teams can investigate misuse without guessing which actor was responsible. That becomes especially important when MCP sprawl grows faster than ownership discipline. The practical conclusion is that traceability must be designed into the access model, not bolted on after deployment.

MCP sprawl creates a governed registry problem before it becomes a security incident. The article describes the familiar pattern of easy installation, weak review, and unclear ownership. That pattern is the same one seen across unmanaged NHI estates. A governed catalog does not solve everything, but it gives security and platform teams a default path that supports review, ownership, and update cadence.

What this signals

MCP governance will increasingly be measured like any other NHI programme. The key question is no longer whether a server can connect to a tool, but whether ownership, scope, and revocation are visible enough to survive growth without sprawl. Teams that already struggle with service-account inventories should expect the same failure mode here, only with faster deployment velocity and more runtime decision points.

The next maturity step is to align MCP controls with existing identity architecture rather than treat them as a separate AI project. That means NHI governance, Kubernetes policy, gateway authorisation, and observability should be managed as one control chain, with the registry acting as the approved entry point for everything else.

For practitioners

• Isolate every MCP server by default Place each server in its own namespace, apply default-deny ingress and egress, and only open the ports and destinations required for that specific tool set.
• Replace static API keys with workload identity Use SPIFFE and SPIRE for server identity, then pass verified user identity through token exchange so every tool call can be attributed to both the workload and the person who authorised it.
• Enforce policy at a single gateway Centralise access control, rate limiting, and audit logging so tool permissions can be governed declaratively instead of being scattered across individual server configurations.
• Instrument every tool call with session context Capture the agent session ID, tool name, inputs, outputs, latency, and result in structured telemetry so investigators can reconstruct the path from prompt to action.
• Curate a governed MCP registry Make the approved catalog the default deployment path and require security review before a server can be used in production.

Key takeaways

• MCP servers should be governed as non-human identities, because each one creates a distinct access path into internal systems.
• The strongest controls in this article are identity trail, gateway policy, and namespace isolation, not static secrets or per-server auth patches.
• A governed registry and full tool-call observability are what keep MCP sprawl from turning into unmanaged access sprawl.

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.
• Gateway Enforcement: Gateway enforcement is the use of the API gateway as the place where policy is applied before traffic reaches backend services. It combines authentication, rate limiting, quotas, segmentation, and logging so the organisation can control both access and consumption in one place.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step Kubernetes manifests for namespace isolation and NetworkPolicy enforcement
• Policy examples showing tool-level authorisation with Cedar and OPA Rego
• OpenTelemetry field recommendations for tracing MCP tool calls end to end
• Registry workflow details for curating approved MCP servers before deployment

👉 The full Stacklok post covers Kubernetes isolation, gateway policy, observability, and registry design in implementation detail.

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.