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攔截器處理程序（簡化）：

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