什麼是 MCP 治理？何時需要它？

MCP 治理的用途

模型上下文協定 (MCP) 定義應用程式如何連接到公開工具和資源等功能的伺服器。 MCP 治理將存取規則、核准要求和稽核控制套用至這些連線和請求。

該協定描述了主機、客戶端和伺服器。身份檢查、獨立核准和稽核記錄是在特定治理實作中進行驗證的功能。

Durin 將存取檢查和政策套用於透過其閘道路由的請求。它可能需要精確寫入核准並記錄與執行結果分開的授權決策。 Durin 不託管或訓練 AI 模型。

它與 MCP 伺服器有何不同

MCP 伺服器公開功能並實現或調整底層操作。 MCP 治理控制對這些功能的存取。 Durin 為經過審查的連線提供共用存取點；對於用戶端來說，該存取點充當 MCP 伺服器。

伺服器仍然有安全責任。 MCP 工具規格需要存取控制和輸入驗證。設計良好的伺服器可以強制執行自己的授權；新增網關並不會使伺服器端或提供者端控制變得可選。

集中式治理何時有用

當多個客戶或團隊需要一致的存取規則、連線所有權、書面審查或工具活動證據時，請考慮集中式 MCP 治理。共享生產連線是檢視這些需求的有用點，但團隊規模本身並不能決定架構。

如果伺服器已提供所需的授權和稽核，則直接的連線可能足以滿足有限的用例。只讀存取仍然需要審查：無法更改資料的工具仍然可以洩露敏感資訊。

• 存取：您能否識別請求者並限制連線、工具和資源？
• 變化：上游工具能否在不默默擴大存取權限的情況下進行變更？
• 寫道：您的團隊決定需要核准進行操作嗎？
• 證據：你能區分執行許可和確認結果嗎？
• 覆蓋範圍：使用者是否可以透過這些控制之外的路線到達相同的系統？

透過 Durin 的請求

請求者將核准的客戶端連接到其 Durin MCP 端點。工具呼叫必須通過目前身分、成員資格、團隊、連線、憑證、審查工具、資源和檢查檢查。僅成功登入並不能授權每個連線。

經過這些檢查後，預設情況下會允許已審核的請求。管理員可以拒絕所有工具存取、獨立要求其他管理員進行寫入或拒絕寫入。相同的政策控制適用於沙箱和生產；提供者授權和工具準備情況仍然很重要。

如果需要核准，則不會執行該操作。不同的活動管理員會審核該要求，且請求者必須在核准之後且到期前重試確切的呼叫。 核准單獨不啟動動作。

Durin記錄調度前的決定和嘗試後的結果。沒有可靠確認的可能已完成的寫入仍然不確定，並且不會自動重複。

推出前要測試什麼

從一份經過審查的連線和一份低靈敏度的讀物開始。確認允許的請求、拒絕的請求、結果記錄。然後使用受支援的沙箱寫入來測試核准、精確重試、過期和不確定的結果。

作為相同審查的一部分，檢查身分吊銷、工具變更、憑證所有權和旁路路徑。網關無法管理它從未收到的請求。與成功的演示分開審查供應商的安全證據和合約承諾。

與現有控制項相符的地方

您的身分提供者提供身分和會員資訊。現有的 API 控制保護上游服務。 MCP 治理將這些控制項連接到工具發現和呼叫；它可以由專用網關或現有平台中的功能提供。

將 MCP 治理與您的 API 閘道控制項進行比較以找出差距，然後依照開發人員指南評估受管控的連線。