AI 安全與基礎設施
ToolHive 0.47 Brings MCP Supply Chain Verification and SPIFFE Workload Identity into the Deployment Layer
ToolHive 0.47.0 can verify agent skills and plugins using pinned Cosign public keys and exposes SPIFFE trust configuration through Kubernetes CRDs. The release also tightens boundaries around OIDC discovery, OAuth permissions, and callback data leakage, though deployers must still configure trust roots for several mechanisms themselves.
ToolHive 0.47.0 focuses not on adding more MCP tools, but on establishing a verifiable identity chain for tools, skills, and running workloads. Skill and plugin pushes can now be signed with Cosign keys. Installation records the key-signature status, while the lockfile stores the pinned public key; subsequent synchronization and upgrades must use the same trust anchor. This adds a layer of publisher verification beyond pinning an OCI digest, reducing the risk that malicious content could enter an agent through an automatic upgrade path after an image or skill name is taken over.
The Kubernetes operator also adds CRD configuration for SPIFFE trust domains, credential sources, and client associations. The underlying types support X.509-SVID, JWT-SVID, and obtaining downstream tokens through RFC 8693 token exchange. A principal can specify either a complete SPIFFE ID or a trailing wildcard. Admission validation rejects overlapping principal patterns and validates RFC 8707 resource URIs, preventing two rules from competing for the same workload. This allows MCP services to authorize access using dynamic workload identities without placing long-lived client secrets in Pods.
Other safeguards include preventing OIDC discovery from targeting private IP addresses, removing the `Referer` header from OAuth callbacks, and—when no scope is specified—requesting only the intersection of the default scopes and the provider's `scopes_supported`. Private CAs can now be used for trusted issuers in RFC 8693 flows, making the feature better suited to internal PKI deployments.
Deployers should still not treat “SPIFFE support” as an out-of-the-box zero-trust solution. Trust bundles, issuers, audiences, resources, and principal mappings must all be configured correctly, and public keys must be obtained through an independent trusted channel. The subsequently released version 0.47.1 only adjusted CI and did not change the runtime capabilities described above. Areas to watch next include key-rotation workflows, keyless Sigstore support, and end-to-end testing of cross-cluster token exchange.