AI News HubLIVE
站内改写8 分で読了

Amazon Bedrock AgentCore ゲートウェイでポリシーと Lambda インターセプターを使用して AI エージェントを保護する

この記事では、Amazon Bedrock AgentCore ゲートウェイでポリシー（Cedar）を使用した確定的アクセス制御と、Lambda インターセプターを使用した動的検証によって AI エージェントを保護する方法を紹介します。レイクハウスデータエージェントの例を用いて、地理ベースのアクセス制御を含む階層的なセキュリティアーキテクチャを構築するために、両方のメカニズムを組み合わせる方法を示します。

ソースAWS Machine Learning Blog著者: Bharathi Srinivasan

AIエージェントのセキュリティは、エンタープライズがエージェントソリューションを構築する上で重要な課題です。企業がAIエージェントを迅速に採用してワークフローを自動化するにつれて、組織全体のツールへの安全なアクセスを管理するためのスケーリングの課題に直面しています。最新の統合エンタープライズAIプラットフォームには、組織内のユーザーにサービスを提供する数百のエージェントがあります。これらのエージェントは、さまざまなチーム、組織、ビジネスユニットにわたる数千のModel Context Protocol（MCP）ツールにアクセスする必要があります。このプラットフォームの規模は、根本的なガバナンスの問題を生み出します。従来のアプリケーションは固定ロジックを実行しますが、大規模言語モデル（LLM）によって駆動されるエージェントは、実行時にどのツールを呼び出すか、どの引数を使用するか、どの順序で呼び出すかを決定します。このワークフローの動的な性質により、コールグラフを事前に監査することが問題になります。LLMが意図したとおりに動作するようにメカニズムを構築する必要があります。

Amazon Bedrock AgentCore ゲートウェイを使用すると、2つの補完的なメカニズムを通じてエージェントとツールを保護できます。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を通じて照会されます。アプリケーションには3つのユーザーロールがあります。保険契約者（自分の請求のみ表示可能）、アジャスター（割り当てられた請求を管理）、管理者（監査ログを含む完全なデータアクセス権限を持つ）です。Streamlit UIは、Amazon Cognitoを通じてユーザーを認証し、JSON Webトークン（JWT）をエージェントに渡します。

MCPサーバーは、query_claims、get_claim_details、get_claims_summary、query_login_audit、text_to_sqlの5つのツールを公開します。ロールからツールへのアクセス、テナント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 Gatewayを介してツール呼び出しを開始すると、リクエストはリクエストインターセプターLambda関数によってインターセプトされます。リクエストインターセプターは、ベアラートークンをテナントスコープの資格情報に置き換え、追加のコンテキストを注入することにより、リクエストを変換します。次に、ポリシーエンジンは、Cedarポリシーに基づいて変換されたリクエストを評価します。変換されたリクエストは、レイクハウスMCPサーバーを使用してツールを呼び出すために使用されます。次に、レスポンスインターセプターLambda関数がレスポンスを評価し、ユーザーに返される前にツールリストをフィルタリングします。

ゲートウェイは、Cedarポリシーの前にリクエストインターセプターを評価します。この順序は、インターセプターを使用してリクエストコンテキストを強化し、その後ポリシーを使用してその強化されたコンテキストを評価する設計パターンにとって基本的です。

AgentCore Gatewayでのポリシー実施

Amazon Bedrock AgentCoreのポリシーは、Cedarポリシー言語を使用して、ゲートウェイで確定的で監査可能なアクセス制御を実施します。Cedarポリシーは、プリンシパル、アクション、リソースに対して評価される許可または禁止ルールとして表現され、アクションのコンテキストに基づく条件があります。

認可ルールがID属性、アクション識別子、リクエストコンテキストに対する論理条件として表現できる場合、Cedarポリシーをきめ細かなアクセス制御に使用します。典型的なユースケースには、ロールが呼び出せるツールの制限や、特定のユーザーグループに対する機密操作へのアクセスのブロックが含まれます。Cedarはまた、インターセプターによって注入されたコンテキスト属性に基づいてデータ所在地ルールを実施し、リクエストがダウンストリームサービスに到達する前にゲートウェイでのスコープチェックや時間枠の実施をサポートします。

設計1: ポリシーのみ

まず、レイクハウスエージェントのセキュリティレイヤーとして機能するポリシーの例を見てみましょう。保険契約者がget_claims_summaryを呼び出せないようにするというビジネス上の決定があったとします。保険契約者は自分の個々の請求を表示できますが、集計サマリーはアジャスターと管理者にのみ予約されています。これを行うには、ポリシーエンジンをゲートウェイに接続し、連携して動作する2つの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*"
};

これら2つのポリシーの組み合わせにより、保険契約者が請求サマリーにアクセスしようとする場合を除き、エージェントは任意のツールを呼び出すことができます。

注：ベストプラクティスは、ポリシーエンジンのポリシー実施モードをLOG_ONLYに設定することから始めることです。すべてのポリシー決定はCloudWatchに書き込まれますが、リクエストはブロックされません。これにより、ENFORCEモードに切り替える前に、各ポリシールールが期待どおりに動作することを検証できます。

次の図は、ポリシーのみのパターンに従ったツール呼び出しフローを示しています。

[画像説明] レイクハウスエージェントが着信リクエストを送信すると、AgentCore Gatewayは組み込みの認可を使用して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エージェントを保護するための3つの重要な利点を提供します。

  • 決定論的: 同じ入力は、LLMの動作に関係なく常に同じ決定を生成します。
  • 監査可能: ゲートウェイに対してCloudWatchログ配信が有効になると、すべての許可または拒否の決定が完全なコンテキストで記録され、完全な監査証跡を提供します。
  • 低レイテンシー: Cedar評価はリクエスト処理に最小限のオーバーヘッドを追加します。

動的制御のためのインターセプター

インターセプターは、AgentCore Gatewayがリクエストライフサイクルの2つの段階で呼び出すカスタムLambda関数です。REQUESTインターセプターはリクエストがダウンストリームツールに到達する前に実行され、RESPONSEインターセプターは応答がエージェントに返される前に実行されます。ゲートウェイは各インターセプターに、元のリクエストヘッダーとボディを含むJSONイベント（mcpキーの下）を渡します。インターセプターはリクエストコンテンツを変換し、同じ構造で返します。インターセプターは、Lambda関数、OpenAPIエンドポイント、MCPサーバーを含むすべてのゲートウェイターゲットタイプで機能します。完全なペイロード契約と詳細なウォークスルーについては、この記事を参照してください。

エージェントがユーザーに代わってツールを呼び出す場合、重要なセキュリティ上の決定は、コールチェーンを通じてIDがどのように伝播するかです。偽装アプローチは、元のユーザーJWTを変更せずに各ダウンストリームサービスに渡すことです。これはより簡単ですが、ダウンストリームサービスが必要以上に多くの権限を受け取ることも意味します。侵害されたサービスは、特権が過剰なトークンを他の場所で再利用する可能性があります（混乱した代理問題）。別のアプローチは「代理行動」であり、各ダウンストリームターゲットは、そのサービス専用にスコープ設定された、個別の最小権限トークンを受け取ります。ユーザーのIDコンテキストは監査のために流れます。設計2はこのパターンを実装しています。REQUESTインターセプターは、ユーザーのCognito JWTをsts:AssumeRoleを介して短期間のテナントスコープIAM資格情報と交換し、そのスコープ設定された資格情報がMCPサーバーに到達します。

設計2: インターセプターのみ — 代理行動トークン交換とコンテキスト伝播

REQUESTインターセプターでは、Cedarが実行できない3つの操作が発生します。

  1. JWTからIAMトークンへの交換（代理行動）: JWTからユーザーのCognitoグループを読み取り、DynamoDBで対応するテナントIAMロールを検索し、sts:AssumeRoleを呼び出して短期間のスコープ設定された資格情報を取得します。
  2. コンテキスト注入: ユーザーIDと一時的なIAM資格情報をMCPリクエストボディのparams.arguments.contextに書き込み、MCPサーバーがそれらを使用してスコープ設定されたAthenaクライアントを構築できるようにします。
  3. ツール認可: リクエストを転送する前にDynamoDBのallowed_toolsをチェックし、許可されていない呼び出しに対して構造化されたMCPエラーを返します。

REQUESTインターセプターハンドラー（簡略化）:

[コスト抑制のためコードは省略]