Your developers are already running MCP servers you don’t know about
Your developers are already running MCP servers you don’t know about. Every ungoverned server is a potential compliance failure, a blast radius waiting to happen, and a security audit you are not prepared for.
Here’s what you’ll learn in this post:
- Why ungoverned MCP servers are a security and compliance problem that is already in your environment
- How the five questions your security team will ask map to concrete governance controls
- Why Kubernetes gives you a head start and what governed MCP deployment looks like in practice
The problem is already in your environment
You’ve seen this movie before. It was called containers. It ended with Kubernetes.
Before Kubernetes, containers were running everywhere: on developer laptops, in staging environments, in production, deployed by hand, managed inconsistently, governed by no one. The organizations that moved early to establish patterns, RBAC, network policy, secrets management, observability, are the ones running containers at scale today. Everyone else spent years cleaning up.
Model Context Protocol (MCP) servers are the current equivalent of containers. Right now, your developers are deploying them the same way they deployed containers in 2014. Some with your blessing. Most without. You probably don’t know how many.
The window to establish governance patterns while the footprint is still small is closing. Every week you delay, more ungoverned servers run in production, more tool calls go unlogged, and more access goes unchecked. When the security team finally asks, the answer “we’re working on it” gets harder to deliver.
“We’ve seen this before with containers. The organizations that got ahead of it early are the ones operating at scale today. The ones that didn’t are still paying the remediation tax.” — Craig McLuckie, co-creator of Kubernetes, co-founder of Stacklok
The five questions your security team will ask
Before you can get budget approved, you need answers to these. Here they are, and what Stacklok does about each.
How do we know what’s running? The Stacklok Registry Server is the authoritative catalog of every MCP server in your environment. It implements the official MCP Registry API specification, so your teams can discover and deploy from a curated list of trusted servers rather than pulling from wherever they find them.
Who has access to what? The Stacklok Gateway enforces policy centrally. Every request passes through a single controlled proxy. Access is scoped, not ambient. You define who can reach what, and the platform enforces it at runtime without requiring each team to implement controls themselves.
How do we audit this? Every tool call produces a structured log entry. When an agent calls a function, that call is recorded: who made it, what was requested, what was returned. When an auditor asks what your AI agents did last quarter, you have an answer.
What’s the blast radius if something goes wrong? MCP servers run in isolated containers. Access is scoped to what each server needs. A compromised server cannot traverse to infrastructure it was never meant to reach. Containment is structural, not policy-dependent.
What happens when we want to change models or frameworks? The control plane is yours. Stacklok is vendor-neutral and model-agnostic. You can swap underlying models or frameworks without rearchitecting governance. That is a structural advantage no model provider’s platform can offer: your governance layer does not belong to the vendor whose model you happen to be using today.
What governed looks like in practice
Governance is not an architecture diagram. It is a set of outcomes: visibility, access control, auditability, and blast radius containment.
If your team already runs Kubernetes, you are not starting from scratch. The primitives your team already trusts are doing the work:
- RBAC controls who can deploy and access MCP servers
- Network policy restricts traffic between servers and infrastructure
- Secrets management handles credentials without embedding them in containers
- Observability stack surfaces logs, metrics, and alerts across your deployment
Stacklok assembles these primitives for MCP the same way Kubernetes assembled them for containers. You get the governance layer without building it yourself.
Consider a platform engineering team of eight that deployed Stacklok’s Kubernetes Operator to govern 50+ MCP servers across three product teams. Within the first week, the registry surfaced six servers that had not appeared in any prior inventory. Two had access to production database credentials. Neither was in the on-call runbook. The team was able to scope access, update the registry and establish an approval workflow for new deployments, all before the quarterly security review.
Why the team that built Kubernetes
Craig McLuckie and Joe Beda co-created Kubernetes and donated it to the Cloud Native Computing Foundation (CNCF). They have seen the container governance problem from the inside. They know what happens when infrastructure outpaces the controls built to manage it.
Stacklok is built on the same principles that made Kubernetes the standard for container orchestration: isolation, identity, connectivity, ingress, and observability. Applied to MCP servers the same way Kubernetes applied them to containers.
No competitor can make this argument. The people who defined how the industry governs containers have defined how it will govern AI agents. That is not a marketing position. It is a design decision made by the engineers who wrote the original spec.
Make vs. buy vs. wait
This decision comes down to three options. Here is what each actually costs.
| Build it yourself | Use a platform | Wait | |
|---|---|---|---|
| Time to value | 6–18 months | Days to weeks | Zero (for now) |
| Engineering cost | High: registry, gateway, runtime, observability, policy engine | Low: deploy the operator, configure policy | Zero (for now) |
| Maintenance burden | Yours, permanently | Shared with Stacklok | Zero (for now) |
| Security posture | Depends on execution | Auditable from day one | Degrading weekly |
| Audit readiness | When you finish building | Immediate | No |
| Vendor lock-in | None | None (vendor-neutral) | N/A |
Building your own governance layer is not a bad decision. Teams that underestimate scope consistently deprioritize the registry, defer the policy engine, and ship the observability stack “in the next sprint.” When a security incident hits, those are exactly the components that are not there.
Waiting is a choice with a specific cost: more ungoverned servers in production, a harder remediation path, and a worse starting position when the security team finally forces the conversation.
Get started
Want to see what Stacklok can do for your organization? Book a demo or get started right away with ToolHive, our open source project. Join the conversation and engage directly with our team on Discord.
June 13, 2026