Best self-hosted MCP platforms expose the governance trade-offs

At a glance

What this is: This comparison evaluates self-hosted MCP platforms and concludes that private-cloud deployment only matters if identity, policy, and supply-chain controls stay inside the customer boundary.

Why it matters: It matters because MCP is becoming an identity-bearing control plane for tools and agents, so IAM, PAM, and NHI teams need deployment models that preserve residency, isolation, and auditability.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.

👉 Read Stacklok's comparison of self-hosted MCP platforms for secure deployment

Context

MCP has turned tool invocation into an identity and access problem, not just a developer-experience problem. If the runtime, registry, gateway, and authorization plane do not stay inside the customer boundary, organisations lose control over credentials, agent context, and audit evidence.

For regulated environments, the key question is whether a platform can deliver private-cloud operation without outsourcing the critical trust functions. That means embedded authentication, container isolation, policy enforcement, and provable supply-chain controls, all managed as part of the identity programme rather than bolted on later.

Key questions

Q: What should security teams check before choosing a self-hosted MCP platform?

A: They should confirm that the runtime, registry, gateway, identity flow, and telemetry all stay inside the organisation’s boundary. They should also verify container isolation, enterprise identity integration, and supply-chain provenance. If any critical control-plane function remains vendor-hosted, the deployment is not truly self-hosted for regulated use.

Q: Why do self-hosted MCP platforms matter for identity governance?

A: Because MCP now governs tool access, agent context, and credential use in the same way other identity platforms govern application access. If those functions sit outside the enterprise boundary, IAM teams lose control over auditability, residency, and least privilege. The issue is governance completeness, not deployment style.

Q: Where do MCP platforms usually fail in practice?

A: They fail when they expose shared runtime surfaces, weakly scoped tool permissions, or vendor dependencies in the critical path. Those gaps expand lateral movement risk and make it harder to prove who or what accessed which tool. The result is a larger identity blast radius than most teams expect.

Q: How should organisations decide between SaaS and self-hosted MCP?

A: Choose self-hosted when data residency, internal security policy, or regulated compliance mandates require full control over identity and runtime decisions. Choose SaaS only if the vendor-hosted management plane and data processing are acceptable under policy. If the control boundary is unclear, treat it as a governance risk, not a convenience trade-off.

Technical breakdown

Private-cloud MCP architecture and trust boundaries

A self-hosted MCP platform is only truly private when the runtime components, registry, gateway, and authorization flow all execute inside the customer’s infrastructure. The important distinction is between where tool calls run and where identity decisions are made. If a vendor retains control over telemetry, auth endpoints, or policy evaluation, the trust boundary still leaves the organisation. For IAM teams, this is a control-plane question as much as a deployment question, because the identity surface now includes tools, agents, and the data they can reach.

Practical implication: validate every external dependency in the MCP request path before approving self-hosted use.

Container isolation, RBAC, and lateral movement risk in MCP servers

Container isolation matters because MCP servers often handle heterogeneous tools with different blast radii. A flat process model, where servers share runtime space, expands the chance that one compromised server can reach another server’s credentials or context. Kubernetes-native RBAC and namespace isolation reduce that risk, but only if permissions are actually scoped per server and per workload. This is the same identity logic that applies to workload isolation elsewhere in the stack: the fewer shared privileges, the smaller the path an attacker can reuse.

Practical implication: require per-server isolation and deny shared runtime surfaces across MCP services.

Supply chain provenance and observability for MCP governance

Signed images, SBOMs, attestation, and standard telemetry are not optional extras in self-hosted MCP. They are what let security teams verify what is running, trace what it did, and prove that the platform fits into existing detection and audit pipelines. When MCP servers are deployed like ordinary software without provenance controls, the organisation loses the chain of custody that regulated environments expect. In practice, the best platforms treat image trust and observability as part of identity governance for non-human workloads.

Practical implication: align MCP server deployment with your existing attestation and observability requirements before go-live.

Threat narrative

Attacker objective: The attacker wants to turn one exposed MCP component into broader tool access, credential reuse, and sensitive context exposure across the organisation.

1. Entry occurs when a self-hosted MCP platform exposes credentials or context outside the customer boundary through a SaaS gateway or shared runtime.
2. Escalation follows when a weakly scoped server or flat process model lets one tool or identity reach another server’s secrets, context, or permissions.
3. Impact is credential reuse, context leakage, or cross-server lateral movement that breaks both residency expectations and least-privilege assumptions.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Self-hosted MCP is an identity boundary decision, not a hosting preference. If tool invocations, credentials, and agent context leave the enterprise boundary, the platform no longer fits regulated deployment requirements. That changes how IAM teams should assess MCP: the question is not whether it works, but whether the identity and policy plane remains under customer control. Practitioners should treat MCP architecture as part of the non-human identity estate.

Tool permissions without per-server scoping create an identity blast radius. MCP platforms that do not isolate servers or enforce granular tool permissions inherit the same lateral movement risk seen in poorly segmented workload estates. The problem is not simply overexposure of a single tool, but the reuse of shared runtime trust across servers. That makes server-level isolation and scoped authorization the minimum acceptable baseline for enterprise use.

Supply chain provenance is now part of NHI governance. Signed images, verifiable artifacts, and auditable source code are no longer procurement niceties when MCP servers become part of production access paths. Enterprises that already enforce SBOM and attestation for containers should apply the same standard here. In other words, the governance model for MCP must extend from identity to integrity, or the trust boundary is incomplete.

Kubernetes-native operation is the practical dividing line for governance maturity. Platforms that integrate with existing clusters, CRDs, Helm, and RBAC fit into real enterprise control structures more cleanly than bespoke gateway deployments. That matters because governance only scales when it maps to the operational model teams already use for workload identity and policy enforcement. Practitioners should prefer architectures that inherit existing control planes instead of creating a parallel one.

Stacklok’s comparison highlights a broader market shift toward governed agent infrastructure. The market is moving away from standalone gateways toward platforms that bundle identity, registry, runtime isolation, and policy in one deployable unit. That signals a convergence between NHI governance and application platform engineering, where the best control point is the infrastructure that issues and constrains tool access. Security leaders should plan for platforms, not point products.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security.
• For practitioners building control narratives, Ultimate Guide to NHIs , Static vs Dynamic Secrets helps explain why long-lived credentials keep creating avoidable exposure.

What this signals

Identity blast radius: MCP platforms will increasingly be judged by whether they reduce the number of identities, secrets, and policy boundaries a tool invocation can touch. Teams should expect procurement to shift from feature comparison to boundary verification, especially where regulated data or internal IP is involved.

As agent-driven tool use expands, the safest path is to treat MCP servers like other privileged non-human workloads and apply the same runtime, attestation, and access-scoping discipline. That means integrating MCP into existing Kubernetes and identity governance workflows rather than creating a separate exception process.

For practitioners

• Verify the full trust boundary Map every MCP runtime dependency, including auth endpoints, telemetry sinks, and registry lookups, to confirm they remain inside your infrastructure boundary.
• Require per-server isolation Insist that each MCP server runs in its own container or equivalent isolated execution unit with minimal filesystem and network permissions.
• Align MCP with existing identity controls Tie MCP access to enterprise OIDC or OAuth, and reject designs that rely on stored developer credentials or vendor-hosted authorization flows.
• Extend attestation to MCP images Apply your SBOM, image-signing, and provenance checks to MCP server artifacts before they are allowed into production clusters.
• Test governance at scale before standardising Pilot the platform in the same Kubernetes, RBAC, and observability environment you use in production so the deployment model matches your operating reality.

Key takeaways

• Self-hosted MCP only satisfies regulated use cases when identity, runtime, and policy controls stay inside the customer boundary.
• Weak tool scoping and shared runtime surfaces create an identity blast radius that IAM teams should treat as a core governance risk.
• Enterprises should evaluate MCP platforms using the same standards they apply to workload identity, container provenance, and access auditability.

Key terms

• Self-hosted MCP platform: A self-hosted MCP platform runs the runtime, registry, gateway, and identity functions inside the customer’s own infrastructure. In practice, that means the organisation controls data residency, policy enforcement, and audit boundaries instead of relying on vendor-hosted management planes.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.
• Supply chain attestation: Supply chain attestation is cryptographic proof that a running artifact matches a known, trusted build. For MCP servers, it gives security and procurement teams evidence that the code they approved is the code operating inside their environment.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

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

• A deeper breakdown of how ToolHive components map to Kubernetes Operators, CRDs, and namespace-scoped deployments.
• Configuration-level detail on embedded authorization, per-server permissions, and policy enforcement in the private-cloud runtime.
• Platform-by-platform procurement notes on Docker MCP Gateway, IBM ContextForge, Obot, and MintMCP for teams at implementation stage.
• Operational guidance on when a self-hosted option is sufficient versus when a fully private deployment is required.

👉 Stacklok's full comparison covers the deployment models, governance limits, and implementation trade-offs across the short list.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.