Notifications
Clear all
Topic starter
18/08/2026 2:44 pm
TL;DR: MCP servers expand the attack surface from isolated tools into governed access points, and Stacklok argues Kubernetes teams can reuse namespaces, network policy, workload identity, and gateway enforcement to control blast radius, identity, and auditability. The real issue is not deployment convenience but whether tool access can be scoped, traced, and revoked as an identity problem rather than a credential problem.
NHIMG editorial — based on content published by Stacklok: MCP security best practices for Kubernetes teams
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Stacklok's MCP security best practices for Kubernetes teams →
MCP security in Kubernetes: are your controls keeping up?
Explore further
18/08/2026 3:27 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: MCP security best practices for Kubernetes teams
