Kubernetes MCP secrets governance needs controlled vault access

At a glance

What this is: This is a Stacklok integration guide showing how Vault and ToolHive can provide controlled secrets access for MCP servers running in Kubernetes.

Why it matters: It matters because MCP workloads still depend on secrets governance, and IAM, PAM, and NHI teams need to control how Kubernetes services obtain and use credentials.

👉 Read Stacklok's integration guide for securing MCP secrets with Vault and ToolHive

Context

MCP servers running in Kubernetes inherit the same secrets governance problem seen across modern workload estates: credentials are often too easy to expose and too hard to control once deployed. In this case, the article focuses on replacing hardcoded or directly mounted secrets with governed access patterns, which is a familiar identity and NHI control issue even when the implementation is framed as an integration guide.

For identity teams, the important question is not whether Vault can store secrets, but whether MCP workloads have a lifecycle-aware way to retrieve, limit, and rotate those secrets without expanding standing access. That makes this a practical NHI governance topic as much as a Kubernetes operations topic.

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 MCP workloads increase secrets governance risk in Kubernetes?

A: MCP workloads can touch many tools and data sources, which increases the number of credentials they need. In Kubernetes, that can turn into sprawl if secrets are copied across namespaces or baked into deployment artifacts. The risk is less about storage and more about uncontrolled distribution and standing access.

Q: What breaks when secrets are stored in MCP configuration files?

A: A single exposed config can turn a helper process into a durable access path. If API keys, tokens, or credentials are stored in plaintext or environment variables, any process that reads the file may reuse the privileges. That makes secret rotation necessary but insufficient unless the underlying integration is also reviewed and constrained.

Q: What is the difference between vault-based secret access and secret mounting?

A: Vault-based access retrieves secrets only when needed and allows policy-based control over who or what can request them. Secret mounting places credential material directly into the runtime environment, which is simpler to deploy but harder to segment, revoke, and trace across Kubernetes workloads.

Technical breakdown

How Vault changes secrets handling for MCP servers

Vault centralises secrets retrieval so workloads do not need credentials embedded in configuration files or directly mounted into containers. In a Kubernetes setting, that usually means the application authenticates to Vault at runtime and receives only the secret material it needs for the task, rather than holding broader access indefinitely. The security value comes from separating secret storage from secret consumption, which reduces the number of places a credential can leak. For MCP servers, this matters because the server may need to reach multiple tools or data sources, making static secret distribution especially difficult to govern.

Practical implication: move MCP secret access to runtime retrieval with narrow, task-scoped access instead of embedding credentials in manifests or container images.

Why Kubernetes makes MCP secret sprawl easier

Kubernetes simplifies deployment, but it also makes secret propagation easy to lose track of across namespaces, pods, and environments. If MCP servers rely on long-lived credentials or copied mounts, each additional deployment path becomes another exposure point and another offboarding problem. That is the core NHI pattern here: the workload is acting like a non-human identity with permissions that should be explicit, limited, and revocable. The article’s approach tries to reduce that hidden spread by making secret access controlled through Vault rather than distributed across the cluster.

Practical implication: inventory every MCP workload credential path in Kubernetes and remove duplicated or directly mounted secrets wherever possible.

What controlled access means for MCP governance

Controlled access is not just a storage choice. It requires a policy boundary that determines which MCP service can request which secret, from where, and for how long. That is where identity governance overlaps with workload security: the access decision should reflect workload identity, environment, and purpose, not just the presence of a valid token. In practice, this is closer to workload identity governance than to simple secret management. If the access rule is too broad, the vault becomes a centralised place to distribute over-privileged credentials rather than a control that reduces exposure.

Practical implication: pair Vault use with workload identity and least-privilege policy so MCP servers only receive the secrets they actually require.

NHI Mgmt Group analysis

MCP servers in Kubernetes should be treated as non-human identities, not just applications. Once a server can request secrets to reach tools and data, it becomes part of the identity governance surface. That means lifecycle, authentication, and privilege boundaries matter just as much as pod scheduling or service configuration. Teams that ignore the identity dimension will keep solving deployment mechanics while leaving secret exposure unchanged.

Secret centralisation only helps when access is narrower than the workload's runtime needs. A vault can reduce sprawl, but it can also concentrate risk if permissions are broad or poorly segmented. The governing question is whether each MCP server receives secrets tied to a specific function, environment, and time window. If not, the architecture still behaves like standing privilege with better packaging.

Controlled retrieval is a stronger pattern than static secret distribution for agent-connected systems. MCP increases the number of tool and data interactions a workload may perform, which makes long-lived credentials harder to defend and harder to audit. The right control model is lifecycle-aware secret access, backed by revocation, rotation, and workload scoping. Practitioners should treat this as an NHI governance problem, not merely a Kubernetes integration task.

Secret sprawl is the named concept this article reinforces: credentials become ungovernable when every runtime path can carry them independently. Vault-based access reduces that sprawl only if policies, identity bindings, and offboarding logic are all enforced together. Otherwise, the organisation has moved the problem rather than resolved it. The practitioner conclusion is to govern the secret path, not just the secret store.

What this signals

MCP adoption will force more security teams to treat application runtimes as identity-bearing systems, especially where tool access depends on secrets rather than federated workload identity. That shifts the operational question from where the secret lives to how the workload is authenticated, scoped, and revoked across its lifecycle.

Secrets path governance: the next control gap will be the chain between workload identity, vault policy, and runtime retrieval. Teams that can prove each hop is explicit and narrow will be better positioned to contain agent-connected and tool-connected systems as they scale.

For practitioners

• Define MCP workloads as governed non-human identities Assign each MCP server a distinct workload identity, then map secret access to that identity rather than to cluster-wide convenience. This creates an auditable boundary for authentication, authorisation, and revocation.
• Remove hardcoded and directly mounted secrets Eliminate secret values from manifests, images, and shared configuration paths. Use runtime retrieval so the secret exists only when the MCP server needs it, and reduce the number of places it can be copied or exposed.
• Scope Vault policies to function and environment Create policies that bind each secret to a specific workload, namespace, and purpose. Review whether any policy grants broader access than the MCP server actually requires for tool calls or data access.
• Link secret rotation to workload offboarding Make revocation and rotation part of the deployment lifecycle, not a separate cleanup task. When an MCP service is retired or reconfigured, rotate the secrets it used and remove any access path that remains in place.

Key takeaways

• MCP servers in Kubernetes create an identity and secrets governance problem, not just a deployment problem.
• Vault reduces exposure only when secret access is tied to workload identity, runtime need, and lifecycle revocation.
• The control gap is secret sprawl across runtime paths, which makes offboarding, auditing, and rotation materially harder.

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.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Runtime Secret Retrieval: Runtime secret retrieval is the practice of fetching credentials from a vault or controlled service only when they are needed. It reduces secret exposure in repositories and configs, but it only works when the retrieval path is scoped, logged, and tied to a specific workload or agent.

What's in the full article

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

• Step-by-step Vault and ToolHive integration guidance for Kubernetes-based MCP servers.
• Configuration details for controlled secret access patterns that avoid hardcoded credentials.
• Video demo material that shows the integration workflow in practice.
• Implementation context for teams that are already standardising MCP runtime access.

👉 Stacklok's full guide covers the Kubernetes integration steps and demo walkthrough in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and workload identity. It gives security practitioners a practical foundation for governing non-human access across modern platforms and pipelines.