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.
Editorial analysis by NHI Mgmt Group, based on content published by Stacklok: “MCP security best practices for Kubernetes teams”.
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.
Q: Why do hardcoded credentials create governance risk for MCP access?
A: Hardcoded credentials only prove that a secret was presented.
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.
Practitioner guidance
- 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.
Bottom line: MCP security is fundamentally about constraining tool access so one server cannot become an ungoverned entry point into internal systems.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:27 pm
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.
A few things that frame the scale:
- 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.
A question 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. 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.
👉 Read our full editorial: MCP security best practices for Kubernetes teams