AI News HubLIVE
站内改写5 分鐘閱讀

在Amazon Bedrock AgentCore網關中使用策略和Lambda攔截器保護AI代理

本文介紹瞭如何使用Amazon Bedrock AgentCore網關中的策略（Policy）和Lambda攔截器（Interceptor）來保護AI代理。策略基於Cedar語言實現確定性訪問控制，攔截器支持動態驗證和上下文注入。通過一個湖倉數據代理示例，展示瞭如何結合兩者實現分層安全架構，包括基於地理位置的訪問控制。

來源AWS Machine Learning Blog作者: Bharathi Srinivasan

人工智能代理的安全性是企業在構建代理解決方案時面臨的關鍵挑戰。隨着企業迅速採用AI代理來自動化工作流程，他們面臨着管理組織內工具安全訪問的規模化挑戰。現代統一的企業AI平台擁有數百個代理，為組織內的用户提供服務。這些代理需要訪問跨不同團隊、組織和業務部門的數千個模型上下文協議（MCP）工具。這種平台的規模帶來了根本性的治理問題。傳統應用程序執行固定邏輯，而由大語言模型（LLM）驅動的代理在運行時決定調用哪些工具、使用什麼參數以及按什麼順序調用。由於工作流程的動態性，預先審計調用圖變得困難。必須構建機制以確保LLM按預期行為。

您可以使用Amazon Bedrock AgentCore網關通過兩種互補機制來保護代理和工具：Amazon Bedrock AgentCore中的策略用於確定性訪問控制，AgentCore網關的攔截器用於動態驗證。Amazon Bedrock AgentCore中的策略允許您定義附加到網關工具的策略。策略使用Cedar編寫，Cedar是一種聲明式策略語言，它根據主體、操作和資源評估每個請求，並可選地基於請求上下文的條件。結果是確定的允許或拒絕決定，並自動記錄在審計日誌中。Lambda攔截器允許您定義在每次工具調用之前或之後運行的自定義代碼，支持動態驗證、負載增強、令牌交換和響應過濾。您可以結合這兩種機制為您的代理解決方案構建分層安全架構。

在這篇文章中，我們使用一個湖倉數據代理來演示如何將策略用於確定性訪問控制，以及將Lambda攔截器用於動態驗證。然後，我們展示如何結合Lambda攔截器和策略來實現基於地理位置的訪問控制，這需要動態驗證和確定性訪問控制。

前提條件

在實施此解決方案之前，您需要：

  • 一個AWS賬户。
  • 訪問GitHub存儲庫。
  • AWS Identity and Access Management (IAM) 權限來設置先決條件。

解決方案概述

湖倉數據代理是一個AI助手，允許保險公司員工查詢索賠數據。數據存儲在Amazon S3表（Apache Iceberg）中，並通過Amazon Athena和AWS Lake Formation查詢。應用程序中存在三個用户角色：保單持有人（只能查看自己的索賠）、調解員（管理分配的索賠）和管理員（具有完整的數據訪問權限，包括審計日誌）。Streamlit UI通過Amazon Cognito對用户進行身份驗證，並將JSON Web令牌（JWT）傳遞給代理。

MCP服務器公開了五個工具：query_claims、get_claim_details、get_claims_summary、query_login_audit和text_to_sql。角色到工具的訪問、租户IAM角色映射和用户地理位置存儲在Amazon DynamoDB中。AWS Lake Formation在查詢時實施行級和列級安全性。在這種情況下，即使代理構建了廣泛的SQL查詢，結果也會自動限定在調用者的IAM角色被允許查看的範圍內。

下圖顯示了湖倉數據代理的架構：

[圖片描述] 用户通過Streamlit UI訪問湖倉代理，Amazon Cognito對用户進行身份驗證並頒發承載令牌。AgentCore Runtime託管湖倉代理，驗證這些令牌併為每個用户建立隔離會話。當代理調用工具時，AgentCore Gateway通過Lambda攔截器路由請求。攔截器提取承載令牌，通過租户角色映射驗證工具訪問權限，並生成具有租户範圍聲明的令牌。AgentCore策略引擎在允許訪問之前根據定義的策略評估每個工具調用。然後，湖倉MCP服務器使用範圍憑證查詢數據。AWS Lake Formation根據用户表和索賠表實施行級和列級安全性，幫助每個用户只看到他們被授權訪問的數據。AgentCore可觀測性和會話日誌流式傳輸到Amazon CloudWatch以進行實時監控和合規審計。

請求流程

下圖顯示了通過解決方案的工具調用流程：

[圖片描述] 當湖倉代理通過AgentCore網關發起工具調用時，請求被請求攔截器Lambda函數攔截。請求攔截器通過用租户範圍憑證替換承載令牌並注入額外上下文來轉換請求。然後，策略引擎根據Cedar策略評估轉換後的請求。轉換後的請求用於使用湖倉MCP服務器調用工具。然後，響應攔截器Lambda函數評估響應，在將響應返回給用户之前過濾工具列表。

網關在Cedar策略之前評估請求攔截器。這種順序對於您將使用攔截器豐富請求上下文，然後使用策略評估該豐富上下文的設計模式至關重要。

AgentCore網關中的策略實施

Amazon Bedrock AgentCore中的策略使用Cedar策略語言在網關處實施確定性、可審計的訪問控制。Cedar策略表示為permit或forbid規則，這些規則根據主體、操作和資源進行評估，並基於操作上下文的條件。

當授權規則可以表示為身份屬性、操作標識符和請求上下文上的邏輯條件時，我們使用Cedar策略進行細粒度訪問控制。典型用例包括限制角色可以調用哪些工具，以及阻止某些用户組對敏感操作的訪問。Cedar還根據攔截器注入的上下文屬性強制執行數據駐留規則，並支持在請求到達下游服務之前在網關處進行範圍檢查或時間窗口執行。

設計1：僅策略

首先，讓我們看一個策略作為湖倉代理安全層的示例。考慮企業決定保單持有人不應能夠調用get_claims_summary的場景。保單持有人可以查看自己的個人索賠，但彙總摘要保留給調解員和管理員。為此，您可以將策略引擎附加到網關，並定義兩個協同工作的Cedar策略：基線許可規則和針對性禁止規則。

當策略引擎附加到網關時，它遵循默認拒絕語義。如果沒有策略明確允許請求，則拒絕請求。因此，您首先需要一個基線許可策略，允許代理調用網關上的工具：

permit(
principal,
action,
resource == AgentCore::Gateway::""
);

僅使用此策略，所有經過身份驗證的用户都可以調用任何工具。

接下來，添加一個禁止規則來為保單持有人劃定特定限制。由於在Cedar中禁止規則優先於許可規則，這個單一規則足以阻止目標工具調用，同時保持所有其他訪問不受影響。

forbid(
principal is AgentCore::OAuthUser,
action == AgentCore::Action::"lakehouse-mcp-target___get_claims_summary",
resource == AgentCore::Gateway::""
) when {
principal.hasTag("cognito:groups") &&
principal.getTag("cognito:groups") like "*policyholders*"
};

這兩個策略的組合允許代理調用任何工具，除非保單持有人嘗試訪問索賠摘要。

注意：最佳做法是從策略引擎上的策略實施模式設置為LOG_ONLY開始。所有策略決策都寫入CloudWatch，但不會阻止任何請求。這使您可以在切換到ENFORCE模式之前驗證每個策略規則的行為是否符合預期。

下圖顯示了遵循僅策略模式的工具調用流程：

[圖片描述] 當湖倉代理發送傳入請求時，AgentCore網關首先使用內置授權驗證JWT令牌。然後，策略引擎根據附加的Cedar策略組合評估請求。在此示例中，Cedar策略使用禁止-許可模式。它首先禁止OAuth用户訪問get_claims_summary工具，然後僅當主體具有匹配保單持有人的Cognito組標籤時才允許訪問。這種確定性策略評估確保只有屬於授權組的用户才能調用特定工具。根據策略評估結果，網關要麼允許調用湖倉MCP服務器並將原始響應返回給代理，要麼在請求到達工具之前拒絕請求。

設計1的策略評估結果

| 用户 | 工具 | 預期結果 | 決策所有者 | |------|------|----------|------------| | policyholder001 | query_claims | Allow | 策略：permit匹配 | | policyholder001 | get_claim_details | Allow | 策略：permit匹配 | | policyholder001 | get_claims_summary | DENY | 策略：forbid覆蓋 | | adjuster001 | get_claims_summary | Allow | 策略：無forbid匹配 |

基於策略的執法的好處

Cedar策略為保護AI代理提供了三個關鍵好處：

  • 確定性：相同的輸入總是產生相同的決策，與LLM行為無關。
  • 可審計性：一旦為網關啓用了CloudWatch日誌交付，每個允許或拒絕的決定都會記錄完整的上下文，提供完整的審計跟蹤。
  • 低延遲：Cedar評估為請求處理增加了最小的開銷。

用於動態控制的攔截器

攔截器是自定義Lambda函數，AgentCore網關在請求生命週期的兩個階段調用它們。REQUEST攔截器在請求到達下游工具之前運行，RESPONSE攔截器在響應返回給代理之前運行。網關向每個攔截器傳遞一個包含原始請求頭和主體的JSON事件（在mcp鍵下）。攔截器轉換請求內容並以相同結構返回。攔截器適用於所有網關目標類型，包括Lambda函數、OpenAPI端點和MCP服務器。有關完整的負載合同和詳細演練，請參閲此文章。

當代理代表用户調用工具時，一個關鍵的安全決策是身份如何在調用鏈中傳播。模擬方法是將原始用户JWT不變地傳遞給每個下游服務。這更簡單，但它也允許下游服務獲得超過所需的權限。一個受損的服務可以重用在其他地方具有過多權限的令牌（混淆代理問題）。另一種方法是“代理行為”方法，其中每個下游目標收到一個單獨的、專門為該服務限定的最小權限令牌。用户的身份上下文流過以進行審計。設計2實現了這種模式。REQUEST攔截器將用户的Cognito JWT通過sts:AssumeRole交換為短期、租户範圍的IAM憑證，而這些範圍憑證才是到達MCP服務器的內容。

設計2：僅攔截器——代理行為令牌交換和上下文傳播

REQUEST攔截器中發生了三個Cedar無法執行的操作：

  1. JWT到IAM令牌交換（代理行為）：從JWT讀取用户的Cognito組，在DynamoDB中查找相應的租户IAM角色，並調用sts:AssumeRole獲取短期範圍憑證。
  2. 上下文注入：將用户身份和臨時IAM憑證寫入MCP請求體的params.arguments.context中，以便MCP服務器可以使用它們構建範圍的Athena客户端。
  3. 工具授權：在轉發請求之前檢查DynamoDB allowed_tools，為未經授權的調用返回結構化的MCP錯誤。

REQUEST攔截器處理程序（簡化）：

[為了控制成本，代碼已截斷]