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

Why This Matters for Security Teams

A self-hosted MCP platform is only defensible if the organisation actually controls the runtime, the registry, the gateway, identity enforcement, and telemetry. Once a vendor retains any of those control-plane functions, the deployment may look on-premises while still depending on external trust and external availability. That is especially risky for regulated environments, where tool access, secrets handling, and audit evidence must remain under direct organisational control.

The practical issue is not just data locality. MCP servers often become the junction point where agent tools, credentials, and workflows meet, which means weak control-plane design can expose secrets and authorisation paths even when the underlying workload is containerised. NHIMG research on Analysis of Claude Code Security shows how fast agentic tooling can expand the attack surface when governance is bolted on after deployment. Current guidance from OWASP Agentic AI Top 10 and NIST’s control baseline in NIST SP 800-53 Rev 5 Security and Privacy Controls both point in the same direction: verify control ownership before trusting the platform.

In practice, many security teams discover that “self-hosted” still means vendor-mediated access only after an audit, incident, or procurement review has already exposed the gap.

How It Works in Practice

The first check is architectural, not contractual. A genuine self-hosted MCP platform should keep the runtime, registry, gateway, policy decision point, and telemetry pipeline inside the enterprise boundary. That means the team can inspect where requests are routed, where tool manifests are stored, where authentication is enforced, and where logs are retained. If identity or policy checks happen in a vendor cloud, then the platform is not fully self-hosted in the operational sense that matters for regulated use.

Security teams should then validate four implementation layers:

• Container isolation: confirm strong isolation between MCP server instances, especially where multiple tools share hosts or Kubernetes clusters.
• Identity integration: require enterprise SSO, workload identity, and service-to-service trust that map to existing IAM and PAM controls.
• Supply-chain provenance: verify signed images, pinned dependencies, and traceable builds for every server component and plugin.
• Telemetry retention: ensure logs, traces, and audit records stay in-house and are queryable without vendor mediation.

This is where NHI thinking matters. Secrets and tokens used by MCP servers should be short-lived, scoped, and revocable, because the server is effectively a non-human identity with tool authority. NHIMG’s Ultimate Guide to NHIs frames this as an identity problem, not just an infrastructure problem. For practitioners, the most useful test is simple: can the organisation rotate, revoke, and inspect the platform’s access path without opening a vendor ticket or relying on an external control plane? If the answer is no, the deployment is only partially self-hosted. These controls tend to break down when the gateway or identity broker is outsourced because the trust boundary becomes split across environments.

Common Variations and Edge Cases

Tighter self-hosting requirements often increase operational overhead, so teams must balance sovereignty and auditability against patching speed, supportability, and staffing constraints. Best practice is evolving here, and there is no universal standard for what counts as “fully self-hosted” across every MCP deployment model.

Some environments can tolerate a vendor-managed registry if it stores no secrets and only publishes signed metadata. Others cannot, especially when the platform handles regulated data, privileged tooling, or agent actions with production impact. The deciding factor is where trust is anchored. If the gateway enforces policy outside the boundary, or if telemetry leaves the environment before review, the security team loses effective control even if compute is local.

NHIMG’s OWASP Agentic Applications Top 10 is useful here because it highlights how quickly tool-using systems can accumulate hidden privilege and weak observability. The safest pattern is to treat self-hosted MCP as a control-plane residency question first and a deployment question second. In higher-assurance settings, that usually means insisting on local enforcement, local evidence, and local revocation, even if that reduces convenience. Organisations that mix on-prem execution with remote policy enforcement often create a false sense of sovereignty while leaving the most sensitive decisions outside their own perimeter.

Related resources from NHI Mgmt Group

• What should teams check before replacing a self-hosted identity platform?
• How do security teams know when a self-hosted analytics platform has become a privilege exposure point?
• How should security teams validate relationship-based access controls before production?
• How should security teams decide whether JIT access is safe for non-human identities?