從方便的外掛，變成企業的權限入口
Model Context Protocol（MCP）讓 AI 助理能以共同介面呼叫檔案系統、資料庫、程式碼平台與企業 SaaS。然而，接上工具也等於打開新的權限入口。原始報導指出，開發者常直接以 npx 或 pip 安裝第三方 MCP server，再把 API token 放進環境變數；程式於是繼承使用者的檔案、網路與憑證權限。個人測試時尚可勉強管理，一旦擴展至數十名工程師與大量伺服器，資安團隊就很難回答「AI 目前究竟碰得到什麼」。來源：https://medium.com/programmed-iq/toolhive-how-to-actually-secure-every-mcp-server-your-ai-agents-touch-2b70397c60cd?source=rss——machine_learning-5
來源事實：報導介紹的 ToolHive 是 Stacklok 推動、採 Apache 2.0 授權的開源 MCP 平台。專案文件顯示，它不只執行伺服器，也涵蓋閘道、受信任登錄庫、執行環境及管理介面，並可在本機容器或 Kubernetes 上部署。官方專案頁：https://github.com/stacklok/toolhive
ToolHive 解的是執行邊界，不只是安裝問題
ToolHive 的商業與技術邏輯，是把散落在每台電腦上的 MCP server，轉化成可由平台團隊治理的工作負載。每個伺服器置於隔離容器，檔案掛載可區分唯讀與讀寫，網路連線可限制主機與連接埠；代理層則承接驗證、授權、遙測與稽核。登錄庫負責列出核准的伺服器、設定與來源，降低員工任意下載套件所形成的「影子 MCP」。
合理推論：它的價值並非宣稱容器能消滅所有風險，而是建立可強制執行的控制點。若工具遭提示注入誘導，或套件本身惡意，模型的文字指令未必可靠；作業系統權限、網路白名單與閘道政策，才可能在呼叫真正落地前阻擋越權。這也符合 OWASP 對第三方 MCP server 的獨立建議：採最小權限、沙箱、可信登錄庫、人工核准及持續監控，而非只在安裝時掃描一次。https://genai.owasp.org/resource/cheatsheet-a-practical-guide-for-securely-using-third-party-mcp-servers-1-0/
OAuth 已能登入，卻仍有三個身分缺口
MCP 並非完全沒有授權規格。現行核心規格以 OAuth 2.1 為基礎，要求 HTTP 型伺服器驗證 access token 是否確實簽發給自己，並禁止把收到的 token 原封不動轉交下游服務，以免產生權限混淆。https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
但「某個人已登入」不等於「伺服器知道是哪一個代理、依何種委派、為何執行這一步」。以下三個缺口，是依官方路線圖與實務架構所作的分析，而非宣稱規格毫無進展：
- 代理本身的身分：同一位員工可能同時使用聊天助理、程式代理與背景排程。若它們只共用人的 token，伺服器難以針對不同代理分配風險等級與權限。
- 委派鏈的語意：代理可能代表使用者行動，又把子任務交給其他代理。系統需要保留「誰代表誰、可做什麼、有效多久」，而不能讓下游只看到一張範圍過大的通行證。
- 可歸責的稽核：只記錄帳號與工具名稱仍不足以重建事件。企業還需連結使用者、代理工作負載、模型或版本、政策判定、工具參數與下游結果，並避免敏感資料反而大量進入日誌。
來源事實：MCP 官方最新路線圖明確把 agent identity、代表使用者行動及向子代理委派較窄權限列為待持續標準化的方向，並提到工作負載身分聯邦、ID-JAG 與標準 token exchange。這證明問題已被規格社群正式承認，但也表示跨產品的一致答案仍在演進。https://blog.modelcontextprotocol.io/posts/mcp-roadmap/
為何現在值得注意
企業管理授權已有實質進展。MCP 的 Enterprise-Managed Authorization 擴充讓組織可透過既有身分提供者集中核准與撤銷員工對 MCP server 的存取；另有 OAuth Client Credentials 處理無人在場的機器對機器情境。不過，官方也說明這些擴充必須由客戶端與伺服器共同宣告支援，不會自動生效。https://modelcontextprotocol.io/extensions/auth/overview
作者觀點：這正是 ToolHive 類閘道現在重要的原因：標準尚未一次補齊所有代理身分語意，企業仍需要在協定外建立一致的部署、政策及稽核層。但閘道是過渡期的治理支點，不應成為自創永久身分格式的藉口；否則今日解決分散安裝，明日可能換成供應商鎖定與另一套互通障礙。
容易忽略的限制與台灣企業的起步方式
容器隔離不會自動判斷一次匯款、刪除資料或寄信是否符合人的真正意圖；登錄庫也不能保證已核准版本日後不出現漏洞。遠端 MCP server 更可能只是經由代理轉送，未必實際運行在本地容器內。此外，若企業允許過寬的網路出口、可寫入整個家目錄，或把長效憑證交給多個服務共用，形式上採用平台仍可能失去最小權限效果。
對台灣的金融、製造、醫療與政府供應鏈而言，務實起點不是等完整標準定案，而是先建立四項基線：列冊所有 MCP server 與負責人；為每個代理或背景工作負載配置獨立身分；將工具權限細分為讀取、建立、修改與刪除；為高影響動作保留人工確認及可串接既有 SOC 的稽核事件。個資或營業祕密也應在送往外部模型與工具前分級，而非把「已登入」誤當成資料可以離境的同意。
後續觀察指標
- MCP 是否完成跨供應商可互通的代理身分、代表關係與子代理委派規範。
- 主流客戶端與伺服器對企業管理授權及機器身分擴充的實際支援率。
- ToolHive 能否把身分、政策判定與工具呼叫串成完整且可匯出的稽核軌跡。
- 企業是否能量測未登錄 MCP、長效 token、過度掛載與不受限網路出口，而不只統計已安裝多少工具。
真正的零信任不是替 MCP 加上一個登入畫面，而是讓每一次工具呼叫都能回答：誰提出、哪個代理執行、代表誰、根據哪項政策、能碰哪些資源，以及事後如何還原。ToolHive 提供了執行與治理的骨架；代理身分標準能否補上其間的語意，才是下一階段能否安全規模化的關鍵。