Run MCP on Kubernetes

The team behind Kubernetes is building AI infrastructure for companies that want to use their cloud native capabilities to become AI native.

Running MCP outside your existing infrastructure creates new risk

Most organizations start by deploying MCP servers the fast way: standalone containers, local runtimes, or vendor-hosted endpoints outside their core infrastructure perimeter. It works well enough for a proof of concept. In production, it creates problems that compound quickly.

New Patterns

MCP is a new protocol. There is no ten-year body of operational knowledge to draw from and no established runbooks for auth flows, tool governance, multi-tenant isolation, etc. Every team is building the blueprint as they go.

Siloed Data

MCP servers deployed outside your core infrastructure generate telemetry that never reaches your observability stack or your compliance tooling. AI activity happening in a parallel universe frustrates security teams.

Identity Gaps

Standalone MCP deployments often default to service accounts and hardcoded API keys. The result is audit trails that show a credential, not a person, and access controls that are all-or-nothing rather than granular.

Without a production-grade runtime that integrates with your existing infrastructure, MCP deployments stay in perpetual pilot mode.

Kubernetes is the right foundation, and we know it better than anyone

Stacklok did not choose Kubernetes because it was convenient. We chose it because it’s incredibly relevant for enterprises. Our team brings deeper Kubernetes expertise to MCP than any other vendor in this space, and we’ve built a platform on top of systems that platform engineers already trust.

Production Operator

Our Kubernetes operator manages MCP servers as first-class Kubernetes resources via CRDs. MCP servers get the same lifecycle management, versioning, and declarative configuration as any other workload in your cluster.

Simple Integrations

Our platform is designed to extend infrastructure you already have, not replace it. SPIFFE/SPIRE for workload identity, OpenTelemetry for observability, Cedar and OPA/Rego for policy, Envoy-compatible gateway patterns.

Kubernetes Pedigree

Stacklok’s CEO is one of the original creators of Kubernetes and donated it to the CNCF in 2015. The architectural principles that made Kubernetes the standard are at the core of our platform.

AI agent challenges solved by Kubernetes

Agents need many of the same things that containers need. The building blocks already exist in the cloud native ecosystem. Stacklok assembles them into something that helps you run MCP and AI agents in production.

1

Isolation

  • Agent workloads need sandboxing. A single misconfigured or compromised MCP server should not be able to take down production, exfiltrate credentials, or access systems it was never meant to reach.

Stacklok Advantage

Run each MCP server in its own isolated container with constrained network and filesystem access. Kubernetes-native deployment means isolation is enforced at the platform level.

2

Connectivity

  • Agents need a standard protocol to talk to your systems. That protocol is MCP. But getting MCP servers deployed consistently across local developer environments, Kubernetes clusters, and air-gapped infrastructure requires more than a spec. It requires a runtime that treats MCP as a first-class primitive.

Stacklok Advantage

Stacklok’s Kubernetes operator manages MCP servers as native Kubernetes resources: declarative configuration, versioned deployments, and lifecycle management via CRDs.

3

Identity

  • You need to know which agent is acting on behalf of which user, with what permissions. Today, most MCP deployments route everything through a single service account. Downstream systems log a credential, not a person.

Stacklok Advantage

Stacklok integrates with your existing IdP (Entra ID, Okta, etc.) and handles OAuth token exchange so that every tool call is attributed to a verified user identity; downstream systems log the actual end user.

4

Gateway

  • Without a gateway, every MCP client connects directly to every server, credentials are hardcoded, and there is no intercept point for policy. You cannot govern what you cannot intercept.

Stacklok Advantage

Stacklok’s MCP gateway provides a single, stable endpoint for all agent traffic. Cedar and OPA/Rego-based policies enforce access at the tool level, with both rate limiting and token optimization at the gateway layer.

5

Observability

  • When an agent makes a decision you did not expect, you need to trace exactly what happened. Raw traffic logs are not enough. You need intent-level observability across the entire MCP control plane.

Stacklok Advantage

Stacklok emits structured OpenTelemetry data on every MCP call and routes it to your existing  observability platform. Audit logs ensure your security team can establish baselines, detect anomalies, and close compliance reviews.

Best practices for running MCP on Kubernetes

Do

  • Treat MCP servers as first-class Kubernetes resources.
  • Enforce identity at the platform level using your existing IdP or SPIFFE-based workload identity.
  • Use a gateway as your single intercept point for policy, rate limiting, and audit logging.

Don’t

  • Hard-code credentials into MCP server configurations when you can use token exchange instead.
  • Deploy MCP servers without network and filesystem constraints.
  • Accept a governance model that is captive to a single model provider or cloud platform.

Your control plane needs to be vendor neutral

The major model providers are shipping full-stack agent platforms: hosting, orchestration, tool integration, identity, all bundled together. It is a fast way to get started. But when your isolation, identity, policy, and observability layers are all owned by your model provider, switching models means rearchitecting everything.

We have been here before. That is exactly the kind of lock-in that Kubernetes was built to prevent.

Stacklok’s core is Apache 2.0 open source. The control plane is yours; it’s not captive to any model provider, cloud vendor, or agent framework. You should be able to swap models, swap frameworks, and swap providers without rebuilding the infrastructure underneath.