View a markdown version of this page

MCP 控管策略 - AWS 方案指引
身分驗證和授權控制負載操作指標

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

MCP 控管策略

MCP 為組織提供的其他重要功能支援集中式控管。您的 MCP 控管策略應針對 MCP 伺服器及其存取的資源進行身分驗證和授權。它還應解決速率限制，以保護下游資源、監控工具用量和效能的操作指標，以及管理 MCP 伺服器的部署和分佈。

身分驗證和授權

身分驗證和授權策略最重要的部分之一，就是從 MCP 伺服器管理下游資源存取。當使用者呼叫代理程式時，會執行身分驗證和授權，以確保使用者具有呼叫代理程式的許可。然後，代理程式會協調呼叫 MCP 伺服器中的特定工具。您需要決定如何根據每個工具授權存取。

其中一個選項是machine-to-machine授權，其中不需要使用者同意或互動。例如，以時間為基礎的代理程式調用使用 MCP 伺服器從應用程式收集日誌並對其進行分析。在此案例中，代理程式會預先授權存取指定的資料。第二個選項是使用者委派的存取，其中使用者同意存取使用者特定的資料和資源。

下表顯示身分驗證和授權模式。

因素

使用者委派的存取

Machine-to-machine

資料擁有權

資料的使用者特定授權

系統或整個組織的資料

使用者互動

使用者存在且可以同意

沒有使用者互動

操作時間

互動式或即時

背景、排程或批次

許可範圍

許可因使用者而異

客服人員層級的一致許可

使用者委派存取需要謹慎實作，並且應該與您的安全團隊一起開發。客服人員必須能夠評估 LLM 已選取的工具，以及是否需要額外的授權。MCP 工具必須包含說明，以指出其身分驗證和授權需求，以及擷取存取權杖的位置。用戶端應用程式必須支援中繼身分驗證請求，且 MCP 用戶端必須針對每個工具呼叫，將擷取的登入資料傳回給客服人員。

您應該確保 MCP 工具一律擁有自己的權杖來存取外部功能，以及記錄和稽核存取權。使用者登入資料不應透過您的代理系統傳播。例如，您的 MCP 伺服器不應使用相同的字符來存取用來叫用代理程式的資料。下游呼叫應使用明確範圍、用途產生的權杖。這有助於提供額外的護欄，以防止代表動作進行意外的資料存取。它也可以協助防止幻覺產生意外的結果。假設具有完整管理員許可的使用者要求代理程式複製生產資料庫，以便在生產前使用。若要這樣做，使用者只需要 READ和 CREATE許可。假設 LLM 會美化並認為需要清除舊資料庫，作為此請求的一部分。如果重複使用使用者的登入資料，可能會成功，因為使用者的原始登入資料具有DELETE許可。反之，如果 MCP 伺服器只針對具有 READ和 CREATE許可的請求使用刻意縮小範圍的權杖，則刪除生產資料庫的嘗試將會失敗。

您可以使用 Amazon Bedrock AgentCore Identity 來協助實作這些模式。請務必刻意選擇列出和叫用 MCP 伺服器託管工具的許可是否意味著 MCP 伺服器公開的外部功能的許可。此身分從 MCP 伺服器流向資源，再流回使用者，取決於使用的身分驗證和授權服務類型。您必須決定 MCP 伺服器的大規模處理方式。

設計身分驗證和授權模式時，請實作權杖隔離機制，針對每個要存取的工具擷取不同的存取權杖。請勿在工具和伺服器之間重複使用權杖。AgentCore Identity 提供此字符隔離功能。它會自動管理工作負載字符 （用於machine-to-machine身分驗證） 和使用者字符 （用於使用者委派存取），以確保適當的分離並防止許可升級。這在整合遠端 MCP 伺服器或 MCP 閘道時特別重要。

MCP 身分驗證和授權的最佳實務

  • 權杖分離 – 請勿將承載權杖從發起人傳遞至下游服務。驗證 aud (audience) 欄位是否符合接收字符的伺服器。對象宣告指定權杖要用於哪個服務，防止在不同 MCP 伺服器上未經授權的權杖重複使用。

  • 選取存取方法 – 針對 MCP 伺服器提供的每個工具，選擇machine-to-machine和使用者委派存取。考慮在使用相同身分驗證模式的相同 MCP 伺服器中將工具分組在一起。

控制負載

如同任何分散式系統，您必須考慮如何控制 MCP 伺服器機群中的負載。首先，您會考慮是否要在 MCP 伺服器中實作速率限制，以及在何處實作限制。如果您選擇不實作速率限制，則會傳遞下游資源執行的任何速率限制。許多系統會根據請求屬性選擇評分限制，例如使用者或帳戶 ID。驗證傳送至下游服務的請求是否具有這些相同的屬性，以便多個使用者不受另一個使用者驅動的負載影響。

如果您選擇實作速率限制，建議的方法是在 MCP 伺服器層級實作主要速率限制，使用後端服務提供次要保護，且客服人員會根據速率限制回饋調整其行為。考慮速率限制是每個 MCP 伺服器還是每個工具。每個 MCP 伺服器速率限制有助於保護多租戶環境中的 MCP 伺服器機群和服務。不過，這可能非常粗粒。每個工具速率限制旨在防止可能無法自行充分速率限制的大量下游資源。如果工具呼叫多個 APIs，您應該設定速率限制，以符合這些 APIs 允許的最低速率。

在 HTTP 標頭中傳遞速率限制資訊也可能是使用者和自動化系統的實用指標，以協助管理自己的請求速率和重試策略。例如，您可以從 MCP 伺服器將這些標頭傳回給代理程式，如下列範例所示：

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640995200

此外，當沒有單一客戶超過速率限制，但負載影響系統效能時，請考慮卸載以保護整體服務。

控制負載的最佳實務

  • 選擇速率限制方法 – 計劃根據個別使用者使用下游資源或透過其使用 MCP 伺服器和工具來對其進行速率限制。

  • 考慮卸載 – 保護您的 MCP 伺服器機群免受非由單一或少數客戶驅動的一般過載影響。

操作指標

要擷取 MCP 實作的關鍵指標應專注於他們提供的客戶體驗。這些指標通常包括字符用量、工具選擇準確性、向代理程式註冊的工具數量，以及工具延遲。例如，監控每個工具傳回的輸出字符，可讓您在工具超過內容時段用量的閾值時設定警示。當工具超過該閾值時，您可能想要檢閱工具的行為。這也與 MCP 工具設計策略相關。工具選擇準確性指標指出客服人員為指定任務選擇適當工具的程度，而執行速度和成功率則強調效能瓶頸和可靠性問題。

例如，為了評估工具選擇和工具使用準確性指標， AWS 團隊建立了黃金資料集進行迴歸測試。在使用者查詢時，使用歷史 API 調用日誌LLMs，以合成方式產生資料集。使用預先定義的工具選擇和工具使用指標 （例如工具選擇準確度、工具參數準確度和多迴轉函數呼叫準確度）， AWS 團隊可以客觀地評估 AI 代理器在對話迴轉期間正確識別適當工具、填入其參數，以及維持一致工具調用序列的能力。

測量向 代理程式註冊的工具數量指標，可協助您識別潛在的內容時段管理挑戰，以及 MCP 伺服器所提供可用工具的變更。您應該定期檢閱指出 MCP 伺服器和工具使用者體驗的操作指標。