Because Kubernetes only changes the runtime, not the trust model. The service still depends on stored secrets, federated tokens, and exposed endpoints, so governance must cover who can authenticate, what can be exchanged, and whether the public path is actually intended for production use.
Why Kubernetes Runtime Does Not Remove MCP Identity Controls
Kubernetes gives you orchestration, scheduling, and deployment mechanics, but it does not replace the trust decisions around an MCP service. The service still needs a defensible way to authenticate callers, constrain token handling, and separate intended production exposure from accidental reachability. In practice, runtime placement and identity governance answer different questions.
For teams building MCP services, that distinction matters because Kubernetes can make a service easier to run without making it safer to trust. A pod that is reachable, carries credentials, or accepts federated access still needs policy decisions about who may connect, what the service is allowed to exchange, and whether the endpoint should exist outside controlled paths.
Identity controls also remain necessary because the service boundary is not the cluster boundary. Even if the workload is containerised and redeployed often, the real risk sits in the authentication material, the exchange path, and the authorisation model behind the endpoint. If those are weak, Kubernetes simply hosts the same exposure more neatly.
What Still Needs Governing in a Kubernetes-Hosted MCP Service
Three control areas stay material: caller authentication, token and secret handling, and exposure management. If an MCP server accepts federated tokens, forwards credentials, or relies on mounted secrets, those choices must be explicit and reviewed rather than assumed safe because the workload runs in-cluster. The relevant control question is whether the service can prove caller identity and limit what that caller can do.
The other issue is scope. A cluster-local service is not automatically non-production, and a public endpoint is not automatically acceptable just because it is technically reachable. A Kubernetes deployment can publish an MCP service cleanly while still leaving open an unauthorised access path, an overbroad tool invocation surface, or a token replay opportunity.
That is why practitioners should treat MCP services as identity-bearing workloads, not just containerised apps. The trust model includes the service account, any upstream federation, and any downstream tool or data access that the service can trigger. Kubernetes helps with deployment consistency, but it does not decide whether the service should be trusted to act.
For an implementation lens, the most useful internal references are Kubernetes NHI Security Guide, which covers service accounts, bound tokens, RBAC, and workload identity in Kubernetes, and NHI Authentication Guide, which focuses on how non-human workloads authenticate with client credentials, mTLS, federation, and short-lived tokens. For the MCP-specific trust boundary, MCP Security Guide explains why authorisation, token passthrough, and gateway design are central rather than optional.
Where Identity Failures Show Up First
The failure pattern is usually not a dramatic cluster break. It is a quiet overtrust problem: a workload gets a secret, a token is passed through too broadly, or a service endpoint is exposed before the intended access policy is in place. Once that happens, the runtime platform may still look healthy while the access model has already failed.
This is why Kubernetes-hosted MCP services are attractive targets for abuse. Attackers and accidental misconfiguration alike can use exposed endpoints, stale credentials, and overly permissive service identities to turn a convenience layer into a pivot point. A service that can act on behalf of someone else, or reach tools and data it should not, creates impact well beyond the container boundary.
There is also a governance gap that teams miss: if the service is reachable from outside the cluster, someone must be able to explain why that path exists, who approved it, and what authenticates it. If no one can answer that cleanly, the service may be operationally deployed but not actually governed.
Failure mechanism: Kubernetes can mask identity weakness by making deployment look standardised while the MCP service still relies on weak token handling, broad service access, or uncontrolled exposure. The attack path is then simple: obtain or reuse the credential, reach the endpoint, and exercise the service’s permitted actions.
Impact: The result is often privilege amplification rather than simple service misuse, because the MCP layer may inherit access to tools, data, or downstream systems that the original caller should never have reached.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Kubernetes-hosted MCP services still need caller authentication and token handling controls. |
| NHI-05 — Overprivileged NHI | The service can still be overtrusted even when Kubernetes manages the runtime. | |
| NHI-07 — Long-Lived Secrets | MCP services in Kubernetes often still depend on stored secrets and tokens. | |
| Recommendation — Require strong workload authentication and short-lived tokens for MCP service access. Reduce service privileges to the minimum needed for each MCP action. Replace durable secrets with short-lived, scoped credentials wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | MCP services authenticate to other services and need explicit machine-to-machine trust. |
| AC-6 — Least Privilege | The service’s permissions must be limited even when Kubernetes deploys it safely. | |
| SC-7 — Boundary Protection | Public or cluster-exposed MCP endpoints need explicit boundary decisions. | |
| Recommendation — Authenticate service-to-service calls with approved cryptographic credentials. Limit each MCP workload to the minimum permissions needed for its function. Restrict and monitor the network paths that can reach the MCP endpoint. | ||
Practitioner Guidance
What to verify: Confirm whether the MCP service authenticates callers directly, whether it forwards bearer tokens, and whether the endpoint is intentionally public, cluster-only, or gateway-restricted. Those are the decisions that define the real trust boundary.
Decision rule: If the service can exchange or reuse credentials to reach anything of value, treat it as an identity-governed workload and require short-lived credentials, explicit audience restriction, and least-privilege authorisation before production exposure.
Common mistake: Treating “runs in Kubernetes” as equivalent to “internal and trusted” is the shortcut that most often hides the control gap. Container scheduling is not an access policy.
Practitioner takeaway: For MCP services, Kubernetes is the execution environment, not the trust model, so the control objective is to make every caller, token, and reachable path explicit before the service is allowed to act.