MCP存取治理：誰可以使用哪些工具和數據
將每個 MCP 請求與一個人聯繫起來，透過團隊授予存取權限，根據工作需要保留工具和數據，並在人們改變角色時保持最新的存取權限。
決策摘要
MCP 存取治理決定誰可以使用哪個 MCP 連線、工具和數據，並隨著時間的推移保持答案的正確性。將每個請求與一個人而不是共享密鑰聯繫起來，透過團隊授予存取權限，根據工作需要保留工具和數據，定期審查存取權限並測試撤銷是否有效。網關可以將這些規則應用於它收到的請求；上游系統本身的權限仍然設定外部限制。
MCP存取治理意味著什麼
模型上下文協定 (MCP) 允許 Claude Code、Cursor 或 Codex 等 AI 用戶端透過提供工具的伺服器連接到公司係統：搜尋工單佇列、讀取文件、更新客戶記錄。每個工具請求都會代表某人到達系統。
Access 治理會詢問您的身分團隊已經針對應用於這些要求的任何應用程式提出的問題。誰可以使用這個連線？每個人需要哪些工具和數據？誰同意了該存取權限？當他們的角色發生變化時，存取權限會以多快的速度結束？
有一個差別很重要。 智能體通常根據剛剛讀取的內容來選擇呼叫哪個工具以及要發送什麼內容。一個人可能有權使用某個工具，而無需考慮智能體可以使用該工具提出的每項請求。這使得狹窄的權限和每個請求的清晰記錄比平時更重要。
訪問是分層決定的
單一工具請求會傳遞多個存取決策。把它們寫下來可以看出哪個系統強制執行每一項，以及哪裡還有差距。
上游系統本身的權限是外部限制。網關規則可以縮小某人可以透過它執行的操作，但它無法授予他們憑證缺乏的權限。
| 圖層 | 問題 | 範例控件 |
|---|---|---|
| 身分 | 誰提出請求？ | 使用智能體的人員單一登入 |
| 成員資格 | 他們還屬於組織和團隊嗎？ | 自動同步的目錄組 |
| 客戶端會話 | 該客戶是否仍獲得授權？ | 每個客戶端可以撤銷的會話 |
| 連線 | 他們能使用這個系統嗎？ | 連線分配給特定團隊 |
| 工具 | 他們可以使用哪些操作？ | 審查了工具，並再次審查了更改 |
| 資源 | 哪些記錄、資料夾或項目？ | 允許的資源或路徑前綴 |
| 憑證 | 上游系統看到誰的權限？ | 每個人自己的 OAuth 授權範圍較窄 |
將每個請求與一個人聯繫起來
共享 API 金鑰是治理存取崩潰的常見位置。當每個人的智能體使用一個Token時，上游系統會看到單一用戶，撤銷它會影響每個人，並且記錄無法顯示誰請求了什麼。
優先選擇每個人自己對上游系統的授權（通常透過 OAuth），並讓他們使用您的常規身分提供者登入任何網關。 MCP 授權規範基於 OAuth 2.1。它期望伺服器只接受為其頒發的令牌，並且禁止將客戶端的令牌直接傳遞到另一個服務。
有些工作適合服務身份，例如無人在場的預定工作。為該身分提供負責任的所有者、有效的最窄權限及其自己的記錄，因此其活動永遠不會被誤認為是一個人的活動。
透過團隊授予存取權限
將連線一次分配給一個人很難回顧，而且很容易忘記。相反，將它們分配給團隊，最好是來自您的身分提供者的群組，以便新加入者獲得正確的存取權限，而離開者在目錄變更時會失去該存取權限。
開始狹窄。將敏感的連線提供給需要它的團隊而不是整個組織，然後為特定工具或資源添加條件。在示例性的財務團隊中，每個人都可以閱讀一個資料夾中的發票，而一小部分人可以更新付款詳細資訊。
注意間接到達的存取。兩個團隊中的某人可以透過任一團隊存取連線，因此將他們從一個團隊中刪除並不一定會刪除他們的存取權。
讓智能體能夠存取工作所需的內容
OWASP 將過度代理列為基於大型語言模型建立的應用程式的主要風險之一。如果智能體被賦予比其任務所需更多的功能、權限或自主權，則當它被誤導或完全錯誤時，可能會造成傷害。提示注入是發生的一種方式，其中智能體讀取的文字嘗試重定向它。
MCP 的最小特權在三個層級上運作。僅啟用工作流程所需的工具。將這些工具限制在工作涉及的資源範圍內。僅請求啟用的工具所需的 OAuth 範圍，因為連線的令牌通常可供該連線上的每個工具使用。 MCP 安全指南建議從最小範圍開始，僅在需要時要求更多範圍。
閱讀值得關懷，也值得改變。只能讀取客戶記錄的工具仍然可能會暴露它們。一個實用的模式是為試點小組提供唯讀存取權限，確認邊界成立，並在團隊了解智能體的行為方式後允許進行更改。
審查存取權限和測試撤銷
访问漂移。專案結束，人員更換團隊，暫時的例外變成永久性的。將 MCP 連線包含在您已經執行的存取審核中，每個連線的擁有者確認誰應該保留存取權限。有用的審查涵蓋以下幾點。
然後直接測試撤銷。刪除測試成員並重複已登入用戶端的請求。應拒絕該請求，並且較早的核准不應恢復存取權限。
- 今天誰可以使用每個連線，以及透過哪個團隊或例外。
- 啟用了哪些工具和資源，以及是否仍需要它們。
- 連線使用誰的憑證以及它們授予哪些範圍。
- 哪些客戶會話仍然處於活動狀態，尤其是已經離開的客戶。
- 期間使用的內容與允許的內容進行比較。
将请求与批准分开
對於產生嚴重後果的行為，例如發送付款、刪除記錄或向客戶發送電子郵件，僅存取可能是不夠的。其他人可以在運行之前查看建議的操作。該審核者不應該是請求者，並且決定應該涵蓋具體操作而不是授予開放式許可。
保持此審查的適當性。要求對每一個小動作進行審查會造成疲勞，並使重要的請求更難發現。根據錯誤可能造成的危害程度來選擇需要審查的操作。
保留存取和使用的證據
兩種證據回答不同的問題。目前訪問顯示了今天誰可以使用連線以及原因。請求記錄顯示誰使用了它、決定了什麼以及接下來發生了什麼。訪問審查需要兩者。
保持記錄相稱。決策記錄很少需要完整的提示或回應，儲存這些內容本身就產生了隱私義務。記錄也只涵蓋他們觀察到的路線；繞過網關的請求需要自己的控制。
Durin 的適用位置
Durin 將存取治理套用於透過其閘道路由的 MCP 要求。在應用團隊規則之前，每個請求都必須通過當前身分、成員資格、團隊、連線、憑證、經過審查的工具、資源和檢查檢查。 連線的範圍可以限定為團隊，團隊規則可以為特定工具、資源或人員新增條件。
人們登入自己的 Durin 端點，上游請求使用為該連線配置的提供者憑證；Durin 不會將自己的令牌傳遞給提供者。撤銷會員資格或用戶端會話適用於以後的請求，早期的核准無法恢復存取。 Enterprise 組織可以從其身分提供者同步使用者和群組；每個套餐都提供本地用戶、群組和邀請。
經過檢查的請求可以在預設情況下繼續進行這些檢查。管理員可以選擇預設拒絕工具存取或要求其他管理員審核建議的變更。存取圖顯示目前誰可以使用連線以及原因，而稽核顯示請求執行時間記錄的決策。不透過 Durin 的請求需要自己的控制。