ToolHive 0.47 將 MCP 供應鏈驗證與 SPIFFE 工作負載身分寫入部署層

ToolHive 0.47.0 的重點不是增加更多 MCP 工具，而是替工具、技能與執行中工作負載補上可驗證的身分鏈。技能及外掛推送現在可使用 Cosign 金鑰簽署；安裝時會標示金鑰簽章狀態，鎖定檔則保存固定公鑰，後續同步與升級也必須使用同一信任錨。這比只鎖定 OCI digest 多一層發布者驗證，可降低映像或技能名稱遭接管後，惡意內容沿自動升級路徑進入代理的風險。

Kubernetes operator 同時新增 SPIFFE 信任網域、憑證來源及用戶端關聯的 CRD 設定。底層型別支援 X.509-SVID、JWT-SVID，以及透過 RFC 8693 token exchange 取得下游權杖；principal 可指定完整 SPIFFE ID 或末端萬用字元。Admission 驗證會拒絕互相重疊的 principal pattern，並檢查 RFC 8707 resource URI，避免兩條規則競爭同一工作負載。這讓 MCP 服務能依動態工作負載身分授權，不必把長效 client secret 放進 Pod。

其他防護包括禁止 OIDC discovery 指向私人 IP、OAuth callback 不再傳送 `Referer`，以及未指定 scope 時只取預設值與供應者 `scopes_supported` 的交集。私有 CA 現可用於 RFC 8693 的可信 issuer，較適合內部 PKI。

部署者仍不應把「支援 SPIFFE」視為開箱即用的零信任方案：信任 bundle、issuer、audience、resource 與 principal 對應仍須正確配置；公開金鑰也必須透過獨立可信通道取得。隨後發布的 0.47.1 僅調整 CI，沒有改變上述執行期能力。下一步值得觀察的是金鑰輪替流程、keyless Sigstore 支援，以及跨叢集 token exchange 的端到端測試。