MCP 閘道與 MCP 安全性：閘道涵蓋的內容
網關檢查存取並記錄其收到的智能體請求。查看它處理了哪些 MCP 安全風險以及哪些仍需要其他控制。
決策摘要
MCP 的閘道是 AI 用戶端與其使用的工具之間路徑上的檢查點。對於收到的請求，它可以檢查誰在請求，應用存取規則，將憑證分開，阻止未經審查的工具，路由敏感更改以供審查並記錄發生的情況。 MCP 安全性是更廣泛的工作：它還涵蓋提示注入、每台伺服器的程式碼、筆記型電腦上的本機伺服器以及繞過網關的每條路由。大多數團隊需要網關和其他控制項一起使用。
簡短的回答
模型上下文協定 (MCP) 將 AI 用戶端（例如 Claude Code 或 Cursor）連接到提供工具的伺服器：搜尋工單佇列、讀取檔案、更新客戶記錄。網關位於這些客戶端和伺服器之間。客戶端連接到一個受管端點，網關在傳遞每個請求之前檢查該請求。
MCP 安全性更廣泛。它涵蓋了智能體工具使用可能出錯的所有方式：模型遵循隱藏在內容中的指令、伺服器的工具與其聲稱的不符、令牌在不應該的地方使用、智能體的存取權超出其任務需求，或者無人知道連線Q 的存在。
因此，比較的重點不是兩種產品，而是範圍。網關是 MCP 安全性中的一種控制措施，也是對其接收的請求的強大控制措施。問題是它在您的部署中處理哪些風險以及誰擁有其餘風險。
每個 MCP 安全風險的處理位置
有兩個來源提供了一個很好的起始清單。 MCP 安全最佳實踐描述了特定於協定的攻擊，例如令牌直通和混淆代理問題。 OWASP 的 MCP Top 10（在撰寫本文時還是一個測試項目）將主要風險分為十類。
該表將這十個類別映射到網關可以貢獻什麼以及必須從其他地方獲得什麼。這是您自己審查的起點，而不是對任何特定產品的描述，因此請要求演示您所依賴的每一行。
| 風險 | 網關可以做什麼 | 還需要什麼 |
|---|---|---|
| Token管理不善和秘密暴露 | 讓上游憑證遠離設備並遠離提示，儘管這使得網關成為有價值的目標 | 秘密商店和短暫、範圍狹窄的Token |
| 透過範圍蔓延來提升權限 | 限制每個團隊的工具、資源和操作，並審查新的存取權限 | 縮小 OAuth 範圍和定期訪問審查 |
| 工具中毒 | 阻止工具，直到它們被審查並將更改的定義視為新審查 | 在核准之前審查伺服器和標記變更的用戶端 |
| 供應鏈攻擊和依賴篡改 | Little：它不能檢查伺服器程式碼，只能限制連接哪些伺服器 | 出處檢查、固定版本和軟體物料清單 |
| 命令注入和執行 | 部分：它可以拒絕超出審查模式的參數 | 伺服器中的輸入驗證和安全命令處理以及沙箱 |
| 透過智能體讀取的內容進行提示注入 | 限制被誤導的智能體可以達到的範圍並保留相應的變更以供審查 | 模型和客戶端辯護和確認提示 |
| 身份驗證和授權不足 | 檢查收到的每個請求的身份和存取權限 | 每個伺服器仍然強制執行自己的存取控制 |
| 缺稽核和遙測 | 記錄路由請求的決策和結果 | 其他所有內容的用戶端、伺服器和端點日誌 |
| 影子 MCP 伺服器 | 對於從未收到的請求，沒有任何內容 | 發現、端點清單、網路控制和簡單的批准路徑 |
| 上下文注入和過度共享 | 限制哪些工具可以讀取和檢查已設定的回應 | 資料分類和模型提供者的資料術語 |
網關的優點是什麼
網關很有價值，因為它收到的每個請求都會經過相同的檢查，無論哪個客戶端發送它。它可以確認誰在詢問，他們是否仍然屬於該團隊，以及他們是否可以使用這個連線、工具和資源。這些決策位於一個地方，而不是在每個客戶端和伺服器中不一致地重複。
它可以將憑證分開。人們登入網關，網關使用為該系統頒發的憑證來呼叫上游系統。 MCP 规范禁止直接传递客户端的Token，因为这样做会绕过上游系统的控制，并且不会留下有关谁操作的明确记录。
它可以將工具視為要審查的事物。工具名称和描述是模型读取和操作的文本，因此保留未经审查的工具并将更改的定义视为新审查的网关可以弥补协议留下的空白。它還可以將敏感變更發送給審閱者並記錄決策和結果。
網關有自己的安全職責
網關集中訪問，因此它值得與任何為其他許多人保存憑證的系統一樣受到相同的審查。在MCP安全最佳實務中，將客戶端連接到第三方API的伺服器稱為代理伺服器，它具有特定的義務。
此类代理必须在转发到第三方授权服务器之前征求每个客户端的同意，准确匹配重定向地址并验证 OAuth 状态参数。如果没有它们，攻击者可以利用用户之前的同意来获取用户从未授予的访问权限，规范中将其称为混淆代理攻击。
網關也代表人們獲取元資料並調用上游伺服器。该规范期望部署在服务器上的客户端能够防止服务器端请求伪造，例如通过要求 HTTPS、阻止私有地址范围和检查重定向。詢問網關如何處理這些流量，以及如果它儲存的憑證受到損害，會發生什麼情況。
網關外面有什麼
網關看到的是請求，而不是請求背後的推理。如果文档告诉模型将数据发送到某处，并且该请求是允许该人发出的请求，则仅政策检查无法区分指令的意图。 Anthropic 所描述的即時注入遠未解決問題。狹窄的權限和對後續行動的審查限制了危害；他們不會讓內容值得信賴。
本地伺服器也在其外部。在筆記型電腦上啟動的伺服器以使用者的權限運行，其流量永遠不會到達遠端網關。 MCP 專案指南將這些視為需要端點和軟體治理的普通軟體。
工具註釋（例如工具僅讀取資料的提示）也不是強制執行。 MCP 維護者建議在確定性控制中保持安全保證。最后，当通过另一个路由使用相同的憑證时，网关的规则不适用，并且它无法看到客户端发送到其模型提供者的内容。
範例：包含隱藏說明的支援票
考慮一個說明性支援智能體，它讀取票證並可以找到客戶記錄。收到的票證中包含告訴智能體匯出完整客戶清單並將其附加到回覆中的文字。
模型可能遵循也可能不遵循說明；這取決於型號和客戶。如果嘗試，網關會檢查此人是否可以在該資源上使用匯出工具。如果該工具從未啟用支持，則請求將被拒絕。如果已啟用且團隊需要審核匯出，則審核者會在運行任何內容之前看到確切的請求。
如果允許匯出且不需要審核，則網關沒有什麼可反對的：所給予的規則允許該請求。這就是為什麼工具設計和存取選擇與檢查點本身一樣重要。
MCP 安全工具如何配合
作為 MCP 安全出售的產品通常執行與網關不同的工作。掃描程式會在您批准伺服器套件和工具描述之前檢查隱藏的指令。運行時監視器在智能體工作時檢查內容和行為。發現工具尋找設備上配置的 MCP 伺服器。
這些是對網關的補充，而不是取代它。掃描會通知您批准哪些伺服器，檢查會新增政策單獨無法提供的內容檢查，而發現會顯示哪些路由仍繞過您的控制。當您評估網關時，這些問題會顯示它在您的部署中強制執行的內容：
- 網關實際上會看到哪些請求，哪些路由會繞過它？
- 客戶端登入和上游憑證如何保持分離？
- 如何審查工具定義？當工具定義發生變化時會發生什麼？
- 存取是否可以受到工具、資源和操作類型的限制，而不僅僅是連線？
- 擬議變更的審核如何進行？審核者會看到什麼？
- 記錄是否將存取決策與操作結果分開？
Durin 的適用位置
Durin 透過閘道為需要智能體請求一致規則和證據的團隊提供 MCP 治理。對於透過它路由的請求，每個呼叫必須通過當前身分、成員資格、團隊、連線、憑證、經過審查的工具、資源和檢查檢查。工具在經過審核之前會一直處於鎖定狀態，並且更改後的工具定義需要重新審核。 Durin 使用連線自己的憑證呼叫提供者，並且不會向上游傳遞自己的令牌。
經過檢查的請求可以在預設情況下繼續進行這些檢查。團隊可以預設拒絕存取或要求其他管理員審核建議的變更；然後，請求者在權限過期之前再次發送相同的請求。 Durin分別記錄決策和結果，不確定的結果永遠不會自動重複。
Durin 不會阻止提示注入，也無法控制繞過它的要求。其 Shadow MCP 發現報告註冊設備上配置的 MCP 伺服器，這可以幫助您找到這些路由；它不會阻止他們。模型、客戶端、端點和伺服器控制仍然是計劃的一部分。