TL;DR: Shared policy objects, zero-downtime migration, and a clearer control plane for MCP server access are the material changes as ToolHive v0.23.0 graduates its MCP server CRDs to v1beta1, shifting shared OIDC, telemetry, tool filters, remote server entries, virtual servers, and registry management into referenced resources that are stable enough for production use, according to Stacklok. For IAM and NHI practitioners, the material change is not feature count but governability: reusable policy objects, zero-downtime migration, and a clearer control plane for MCP server access.
At a glance
What this is: ToolHive v1beta1 changes MCP server management from copy-pasted inline configuration to referenced, reusable CRDs with a stable production API.
Why it matters: IAM and NHI teams need stable, composable control surfaces when MCP servers multiply across clusters, because governance breaks when identity, telemetry, and tool policy are embedded per server.
Context
MCP server governance becomes difficult when every server carries its own inline identity, telemetry, and tool policy. In Kubernetes, that design turns repeated configuration into drift, makes review harder, and leaves operators managing the same control in dozens of places instead of one reusable object.
ToolHive v0.23.0 addresses that by graduating its MCP server CRDs to v1beta1 and shifting core settings into referenced resources. The practical question for IAM and platform teams is no longer whether MCP servers can run, but whether their identity and access model can be governed consistently as the fleet grows.
The article frames the change as a production stability milestone rather than a feature burst. That matters because the underlying issue is lifecycle control: once MCP servers scale across namespaces, remote endpoints, and shared tool sets, the governance model has to survive reuse, migration, and policy evolution without forcing disruptive rewrites.
Key questions
Q: How should teams govern MCP servers when configuration is shared across many workloads?
A: Use shared, referenced policy objects for identity, telemetry, and tool access so the same control can be reused across many servers without creating drift. The practical goal is to make review and change management happen once at the policy layer instead of separately in every manifest.
Q: Why do MCP servers create governance risk when agents scale across an enterprise?
A: MCP servers create governance risk because scale introduces duplicate servers, scattered credentials, unclear ownership, and inconsistent policy enforcement. When agents can connect to many tools without a central registry, platform teams lose visibility into who uses which server and under what conditions. That makes compliance, incident response, and access review much harder.
Q: What signs show that MCP configuration is becoming unmanageable?
A: Look for repeated OIDC blocks, duplicated telemetry settings, per-server tool lists, and one-off auth exceptions spread across many manifests. Those patterns usually mean the control plane is carrying policy in too many places to be reviewed consistently.
Q: What should teams do when MCP CRDs move from alpha to beta?
A: Reapply manifests under the new API version, confirm existing objects still reconcile, and watch storedVersions until the deprecated version disappears. That is the operational checkpoint that tells you whether the old schema can be retired safely.
Technical breakdown
Why referenced CRDs matter for MCP server governance
ToolHive moved OIDC, telemetry, tool filters, and external auth from inline spec blocks into reusable CRDs. That changes the management model from per-server configuration to shared policy objects, which is easier to audit, reuse, and update across a fleet. For operators, the important detail is that the same identity or observability configuration can now be attached to multiple MCPServer, MCPRemoteProxy, or VirtualMCPServer resources without duplicating state. This is a governance improvement, not just a syntax change, because policy intent is no longer scattered across manifests.
Practical implication: Treat shared CRDs as the unit of control and review them separately from individual server manifests.
How remote MCPServerEntry objects change the control plane
MCPServerEntry models remote MCP servers without creating a local proxy pod. That distinction matters because the operator is now cataloging a server that exists elsewhere, rather than managing runtime infrastructure for it. ToolHive also validates remote URLs to block loopback, RFC 1918, link-local, metadata, and other internal targets, which closes off a common SSRF path. In practice, the registry-like object becomes the governance boundary: what is reachable, what is trusted, and what can be referenced by policy. The result is a cleaner separation between server inventory and execution footprint.
Practical implication: Use remote entries to govern externally hosted MCP servers as catalog objects, not as implicit infrastructure.
Why v1beta1 stability changes the upgrade story
The v1alpha1 and v1beta1 schemas are byte-compatible, so ToolHive can migrate without a conversion webhook and without a hard cutover. Existing objects continue to reconcile, while stored versions are rewritten gradually as manifests are reapplied. That means the real operational problem is not code translation but stored state: clusters have to clear deprecated versions from etcd before the old API can disappear. For identity and platform teams, this is the difference between a packaging change and a control-plane change. A stable version only helps if the migration path preserves service continuity.
Practical implication: Plan migration around storedVersions cleanup, not just manifest edits.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- Carbonato botnet 2026: A botnet puts a Hermes AI agent on exposed Docker hosts to steal AI API keys, SSH keys and tokens, powering the operators' own LLM gateway.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Referenced policy objects are the real governance breakthrough here: ToolHive’s move away from inline blocks means identity, telemetry, and tool controls can finally be managed as reusable resources instead of per-server exceptions. That reduces manifest drift and makes reviewable policy composition possible across a growing MCP fleet. The practitioner takeaway is that MCP governance becomes scalable only when configuration is reference-driven.
Stable CRDs matter because MCP governance is now a lifecycle problem, not a deployment problem: once servers, proxies, remote entries, and virtual front doors all share a common control surface, the central issue becomes how policy survives reuse and migration. That aligns closely with NHI governance patterns, where the hard part is not initial setup but preserving control integrity as objects are replicated, referenced, and retired. Teams should evaluate whether their MCP operating model can survive version churn without losing control intent.
Remote server cataloging is a named governance concept worth tracking: the article shows a shift from managing an MCP server as a runtime workload to governing it as a cataloged access target. That matters because many MCP deployments will combine local servers, hosted endpoints, and composed virtual fronts in the same trust domain. The practitioner conclusion is that inventory, routing, and authorisation now have to be designed together, not treated as separate layers.
Zero-downtime migration is only useful if the control plane stays honest about storage: ToolHive’s compatibility story works because deprecated versions remain served long enough for stored objects to be rewritten. That is a reminder that operational stability in identity-adjacent infrastructure depends on what is still persisted in the backend, not only what the API advertises. Teams should validate deprecated-version cleanup as part of governance, not as an afterthought.
MCP scale is pushing identity control toward shared policy boundaries: the more servers, tools, and upstream identity claims are composed, the less sense it makes to govern each server as an isolated unit. This article points to a broader direction in the market where access policy, cataloging, and composition converge into one control plane. Practitioners should expect MCP security to look increasingly like fleet governance, not endpoint administration.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Shared-policy MCP governance is the new baseline: clusters that still treat OIDC, telemetry, and tool rules as inline manifest content will keep producing drift as server counts rise. Referenced CRDs give teams a durable control boundary, which is the prerequisite for any meaningful audit or recertification process.
The wider signal is that MCP infrastructure is maturing from isolated server deployment toward fleet-level governance. That puts pressure on platform teams to define ownership for catalog objects, remote endpoints, and virtual front doors as separate control domains rather than one undifferentiated app layer.
For practitioners
- Standardise on referenced policy objects Move OIDC, telemetry, tool filters, and external auth into shared CRDs so policy can be reviewed and reused across multiple MCP servers without copy-paste drift.
- Separate remote servers from runtime workloads Model hosted MCP endpoints with catalog-style resources rather than proxy pods so ownership, reachability, and trust decisions are visible without adding unnecessary infrastructure.
- Validate remote URL restrictions Keep SSRF validation in place for remote server entries, including loopback, RFC 1918, link-local, metadata, IPv6 ULA, and kubernetes.default.svc targets.
- Plan for stored version cleanup Reapply manifests under v1beta1 and verify storedVersions drops the deprecated API version before scheduling any future removal of v1alpha1.
Key takeaways
- ToolHive’s v1beta1 graduation is less about new features than about making MCP server governance repeatable across a larger fleet.
- Shared policy objects and remote server cataloging reduce manifest drift, but they also force teams to treat MCP control as a lifecycle problem.
- Zero-downtime migration is only real if deprecated versions are still reconciled, rewritten, and removed from stored state before the old API disappears.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Remote MCP endpoints and reused policy objects raise API-style configuration risk. |
| Recommendation — Apply API8 checks to eliminate unsafe defaults and repeated misconfigurations in MCP-facing resources. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The post centers on governing access and authorization across reusable MCP resources. |
| Recommendation — Define and review MCP permissions at the shared policy layer instead of per-server manifests. | ||
| NIST Zero Trust (SP 800-207) | access enforcement and trust evaluation — Access enforcement and trust evaluation | Virtual servers and remote entries require explicit trust boundaries and policy enforcement. |
| Recommendation — Enforce trust decisions at the MCP control plane rather than assuming backend reachability is safe. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | MCP servers rely on reusable identity and auth configuration that must stay consistent. |
| Recommendation — Harden MCP authentication paths so reused configs do not create inconsistent trust across servers. | ||
| CIS Controls v8 | CIS-5 — Account Management | ToolHive’s graduation changes how identities and access settings are managed at scale. |
| Recommendation — Centralise account and access ownership for shared MCP policy objects under CIS-5. | ||
Key terms
- Referenced Policy Object: A referenced policy object is a shared configuration resource that multiple workloads can point to instead of duplicating settings inline. In MCP governance, this reduces drift, makes review easier, and creates a single place to manage identity, telemetry, or tool access decisions across many servers.
- MCPServerEntry: A governable record for a remote MCP server that the operator does not host directly. It lets teams catalogue external or hosted endpoints, attach auth and trust metadata, and manage access as inventory rather than as a proxy workload.
- Stored version migration: The process of rewriting persisted Kubernetes objects so they are stored under the current API version rather than a deprecated one. It matters because old stored versions can block CRD cleanup and turn a simple upgrade into an operational dependency.
- Zero-Downtime Upgrade: A release approach that allows software updates to be applied without taking the service offline. It relies on deployment techniques such as rolling changes, canary releases, and rollback paths so users keep access while the platform is updated. For identity services, this is essential because maintenance windows can create security and operational gaps.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org