ToolHive sandboxes every MCP server in a container

The default way to install an MCP server is still npx something from a README straight onto the machine holding your AWS keys. ToolHive is Stacklok's answer to that: an Apache 2.0 platform that runs every MCP server inside its own container with a minimal permission profile and no local credentials attached. It is the least glamorous fix to the MCP security problem, which is usually a sign it is the right one.

What actually happened

ToolHive is not one binary. It ships as four pieces, all under Apache 2.0, all self-hostable:

• Runtime — starts MCP servers in containers locally via Docker or Podman, applying permissions, network filtering, and secrets management on the way in.
• Kubernetes operator — Custom Resource Definitions so servers are declarative objects with service discovery and fleet-wide orchestration, managed like anything else in your cluster.
• Registry server — implements the official MCP Registry API, signs servers, and verifies provenance, so "which build of this tool are we running" has an answer.
• Virtual MCP Server — a gateway that collapses several backends behind one endpoint with OIDC or OAuth SSO, OpenTelemetry traces, and Prometheus metrics.

There is also a desktop app for one-click installs, which is how most people will meet it. The important design choice is underneath: the server gets a container, a permission file, and network egress rules, and it does not get the ambient credentials sitting in your shell environment.

Why this matters for your business

MCP is now the connective tissue between agents and your real systems — CRM, database, ticketing, payments. The threat model has been demonstrated repeatedly and recently. We covered a CVSS 10.0 MCP server listening on 0.0.0.0 and a LiteLLM bypass where any bearer token could call your tools. OWASP moved excessive agency to third on its 2026 LLM Top 10. None of that is exotic. It is what happens when a tool process inherits more than it needs.

The practical value here is boring and real: a container boundary turns "this MCP server can read anything my laptop can read" into "this MCP server can read what I declared." Egress filtering means a compromised tool cannot quietly phone home. The registry with signing and provenance gives you a supply-chain answer for a category that currently has almost none.

Two caveats before you standardize on it. Containers are isolation, not a sandbox against everything — a server you deliberately grant database credentials still has database credentials. And the Kubernetes operator is where the auth, audit, and gateway features live, so the full model assumes you have a cluster. If you are a five-person shop running agents on laptops, the runtime and permission profiles are the part that pays for itself today.

Apache 2.0 with no license flip in sight is the other reason to look. You can run the registry yourself and you are not renting the boundary that protects your data.

Sources: ToolHive on GitHub, Stacklok documentation, Help Net Security.