Amazon Web Services ブログ

Amazon Bedrock AgentCore ゲートウェイインターセプター: きめ細かなアクセス制御の実現

本記事は 2025 年 11 月 26 日に公開された AWS Blog “Apply fine-grained access control with Bedrock AgentCore Gateway interceptors” を翻訳したものです。

企業は AI エージェントを急速に採用してワークフローを自動化し生産性を向上させる中で、重大な課題に直面しています。それは、組織全体で数千のツールへの安全なアクセスを管理することです。現代の AI アプリケーションは、もはや少数のエージェントが数個の API を呼び出すだけのものではありません。企業は統合 AI プラットフォームを構築しており、そこでは数百のエージェント、コンシューマー AI アプリケーション、自動化されたワークフローが、異なるチーム、組織、事業部門にまたがる数千の Model Context Protocol (MCP) ツールにアクセスする必要があります。

この規模の拡大により、セキュリティとガバナンスに関する根本的な問題が発生します。AI エージェント、ユーザー、アプリケーションなど、各呼び出し元が許可されたツールのみにアクセスできるようにするにはどうすればよいでしょうか？ユーザー ID、エージェントのコンテキスト、アクセスされたチャネル、常に変化しうる権限に基づいて、ツールへのアクセスを動的にフィルタリングするにはどうすればよいでしょうか？エージェントからツール、下流の API へと続くマルチホップのワークフローを通じて、機密データを保護するにはどうすればよいでしょうか？そして、パフォーマンスを犠牲にしたり、運用上のボトルネックを作ったり、テナントやユースケースごとに個別の MCP サーバーインスタンスを強制したりすることなく、これらすべてを実現するにはどうすればよいでしょうか？

これらの課題に対応するため、Amazon Bedrock AgentCore Gateway はゲートウェイインターセプターという新機能の提供を開始しました。この強力な新機能により、きめ細かなセキュリティ、動的なアクセス制御、柔軟なスキーマ管理が可能になります。

きめ細かなツールアクセス制御

エンタープライズのお客様は、統一された AgentCore Gateway を通じて数千もの MCP ツールをデプロイしています。この単一のゲートウェイを使い、異なるチーム、組織、コンシューマー AI アプリケーション、AI エージェントがツールにアクセスします。各ツールには、呼び出し元のプリンシパルに応じたアクセス権限が割り当てられています。ここでの課題は、プリンシパルの権限に基づいて MCP ツールへのアクセスを保護し、AgentCore Gateway への ListTools、InvokeTool、Search API の呼び出しに対して、コンテキストに応じたレスポンスを返すことです。

ツールのフィルタリングは、エージェント ID、ユーザー ID、実行コンテキストなど、複数の動的な要因に基づいて行う必要があります。権限は、ユーザーコンテキスト、ユーザーがエージェントにアクセスするチャネル、ワークスペースのアクセスレベル、その他のコンテキスト属性に基づいて動的に変化する可能性があります。そのため、古い権限状態をキャッシュすることなく、権限の変更が即座にツールの利用可否に反映されるセキュリティを考慮したフィルタリングが求められます。

以下の図は、ユーザーに基づくツールフィルタリングの例です。ゲートウェイがユーザー情報とコンテキストを評価し、許可されたツールを返すまでの流れを示しています。

MCP と下流の API 間でのデータ保護とスキーマ変換

AI エージェントと下流の API 間の連携を管理しながら、セキュリティと柔軟性を維持することは複雑な課題です。組織は、MCP リクエストスキーマを下流の API スキーマに動的にマッピングする必要があります。この動的マッピングにより、ユーザーがプロンプトで送信する可能性のある個人識別情報 (PII) や機密個人情報 (SPI) を削除・除外するなど、重要なデータ保護機能を実現できます。これにより、API 呼び出しで不要な機密情報が下流の API に漏洩するのを防げます。

さらに、お客様はスキーマ変換機能を必要としています。これにより、API の仕様変更に対応しながら MCP スキーマを維持し、下流の実装から独立させることが可能になります。このような疎結合の構成であれば、AI エージェントとツール間の連携を壊すことなく、API の改良とバージョン管理を円滑に進めることができます。そのため、バックエンドチームは、エージェント層への変更を強制したり、特定のツールスキーマを学習した AI モデルの再学習を依頼したりする必要はありません。API 実装の修正、フィールド名の変更、ペイロード構造の再構成、認証要件の更新といった変更を自由に実施できます。

マルチテナント SaaS におけるテナント分離

エージェントやツールをサービスとして提供する組織には、複雑なマルチテナンシー要件があります。お客様は、適切なテナント分離を維持しながら、すべてのユーザーに対して MCP サーバーを提供する必要があります。これには、テナント ID とユーザー ID の両方の検証が必要です。マルチテナント MCP サーバーアーキテクチャでは、異なるユーザーとワークスペースが完全に隔離された状態を保つ必要があり、ツールアクセスはテナント境界に基づいて厳密に制御する必要があります。この課題には、テナントごとに個別のゲートウェイが必要なのか、適切な分離保証があれば単一のゲートウェイでマルチテナントシナリオを安全に処理できるのかを判断することも含まれます。

ツールの動的なフィルタリング

お客様は、権限やユーザーコンテキストの変更に応じた、リアルタイムのツールのフィルタリングも必要としています。組織には、ツールを 2 段階でフィルタリングできる統合 MCP サーバーが必要です。まずエージェントの権限とワークスペースのコンテキストでフィルタリングし、次にセマンティック検索でフィルタリングします。権限はいつでも変更される可能性があるため、フィルタリング結果をキャッシュせず、都度動的に判定することが重要です。

カスタムヘッダーの伝播とアイデンティティコンテキストの管理

AI エージェントは、自律的で非決定論的である点において、従来のマイクロサービスとは根本的に異なります。サービス間の信頼と認可技術に依存する従来のマイクロサービス間認可アプローチとは異なり、AI エージェントはエンドユーザーに代わってワークフローを実行し、ユーザーのコンテキストに基づいて、下流のツール、API、リソースにアクセスする必要があります。しかし、認可トークンをそのまま下流のサービスに送信すると、認証情報の盗難、権限昇格、より権限の高いサービスが権限の低い攻撃者に代わって操作を実行するよう騙される「混乱した代理問題」(Confused deputy problem) など、重大なセキュリティ脆弱性が生じます。

権限伝播方式の比較: なりすまし / 代理実行

マルチホップのワークフロー (エージェントからエージェント、ツール、API へと続く流れ）を通じて、アイデンティティのコンテキスト (権限) をどのように伝播させるかは、重要なセキュリティ上の決定事項です。伝播方法には、なりすまし (Impersonation) 方式と、代理実行 (Act-on-Behalf) 方式があります。

なりすまし方式では、元のユーザーの JWT トークンが多段実行の各ホップを通じて変更されずに渡されます。実装は簡単ですが、以下のような重大なセキュリティリスクが伴うため、推奨されません。

  • 下流のサービスが必要以上の権限を持つトークンを受け取る
  • コンポーネントが侵害された場合、権限昇格のリスクが高まる
  • トークンのスコープを特定の下流のターゲットに制限できない
  • なりすまし攻撃 (侵害されたサービスが過剰な権限を持つトークンを悪用) に対して脆弱

代理実行方式では、ワークフローの各ホップが、下流のターゲット専用に発行された個別のスコープ付きトークンを受け取ります。実行コンテキストの伝播には JWT が使用されます。この方式は、以下のメリットがあるため推奨されます。

  • 最小権限の原則 – 各サービスは、特定の下流の API にアクセスするために必要な権限のみを受け取る
  • 影響範囲の制限 – 漏洩したトークンのスコープは制限され、他の場所で再利用することはできない
  • 監査性の向上 – AgentCore Observability を使用して、どのサービスがユーザーに代わって行動したかを示す明確な責任の追跡が表示される
  • トークンスコープの制限 – 各下流のターゲットは、その API に特化したスコープのトークンまたは認証情報を受け取る
  • セキュリティ境界 – コールチェーン内の異なるサービス間で適切な分離が強制される
  • 混乱した代理 (Confused Deputy) の防止 – スコープが制限されたトークンと認証情報により、サービスが不正な操作を実行するよう騙されることを防げる

代理実行方式では、ゲートウェイは受信リクエストから実行コンテキストを抽出し、各下流のターゲットに対して新しいスコープ付き認可トークンを生成します。モニタリングと認可の判断のために、ユーザーの ID コンテキストを維持しながら適切なヘッダーを挿入します。これは、必要以上の権限を持つ認証情報を下流のサービスに公開せずに実現されます。このセキュアなアプローチにより、AI エージェントはユーザーに代わってワークフローを実行でき、多段実行の各ホップで厳格なセキュリティ境界を維持できます。

次の図は、なりすまし方式と代理実行方式のワークフローを比較しています。

なりすまし方式 (図上部) では、エージェントがユーザー A の完全な ID トークン ("order: read, promotions:write" スコープすべて) を変更せずに両方のツールに渡します。このため、各ツールは必要以上の権限を受け取ります。一方、代理実行方式 (図下部) では、エージェントが各ツール用に個別のスコープ付きトークンを作成します。Order ツールは "order: read" スコープのみを受け取り、Promotions ツールは "promotions:write" スコープのみを受け取ります。各トークンには "Act: Agent" フィールドが含間れており、エージェントがユーザー A の代理として行動していることを明示し、責任の追跡を明確にします。このように、最小権限の原則に基づいて各下流のサービスに必要な権限のみを付与することで、セキュリティリスクを軽減し、トークンの誤用を防止できます。

AgentCore Gateway: AI エージェントのための MCP のセキュアな統合

AgentCore Gateway は、既存の API や AWS Lambda 関数をエージェント互換の MCP ツールに変換します。また、ゲートウェイを既存の MCP サーバーに接続することも、サードパーティのビジネスツールやサービス (Jira、Asana、Zendesk など) とシームレスに統合することもできます。この統一されたアクセスポイントにより、エンタープライズシステム全体で安全に MCP を統合できます。さらに、AgentCore Identity を使用することで、エージェントは OAuth 標準を使用した適切な認証と認可により、これらのツールに安全にアクセスできます。

AgentCore Gateway のゲートウェイインターセプターの導入により、2 つのカスタム Lambda 関数を通じて、きめ細かなアクセス制御と認証情報管理を実装できるようになりました。

  • ゲートウェイリクエストインターセプター – ターゲットツールに到達する前に受信リクエストを処理します。
    ユーザー認証情報、セッションコンテキスト、組織のポリシーに基づくアクセス制御、監査証跡の作成、スキーマ変換などが可能です。
  • ゲートウェイレスポンスインターセプター – 呼び出し元のエージェントに返される前に送信レスポンスを処理します。
    監査証跡の作成、ツールのフィルタリング、スキーマ変換、検索およびリストツールのアクセス制御が可能です。

次の図は、ゲートウェイインターセプターを介したリクエスト・レスポンスのフローを示しています。

リクエスト・レスポンスサイクルの各段階でカスタムインターセプターが受信・送信するペイロードの構造を詳しく見ていきましょう。ゲートウェイリクエストインターセプターは、以下の構造のイベントを受け取ります。

{
  "interceptorInputVersion": "1.0",
  "mcp": {
    "gatewayRequest": {
        "headers": { "Authorization": "Bearer eyJhbG...", ... },
        "body": { "jsonrpc": "2.0", "method": "tools/list", ... }
    },
    "requestContext": { ... }
  }
}

ゲートウェイリクエストインターセプター Lambda 関数は、transformedGatewayRequest フィールドを含むレスポンスを返す必要があります。

{
  "interceptorOutputVersion": "1.0",
  "mcp": {
    "transformedGatewayRequest": {  // <-- インターセプターのコード内で、このフィールドを追加する必要があります 
        "headers": { ... },
        "body": { ... }
    }
  }
}

ターゲットサービスが応答すると、ゲートウェイレスポンスインターセプターが呼び出されます。
入力には、元のリクエストとターゲットからのレスポンスを含むイベントが渡されます。

{
  "interceptorInputVersion": "1.0",
  "mcp": {
    "gatewayRequest": { ... },
    "requestContext": { ... },
    "gatewayResponse": {  // <-- このフィールドに、ターゲットのレスポンスが含まれます 
        "statusCode": 200,
        "headers": { ... },
        "body": { 
            "jsonrpc": "2.0",
            "result": { "tools": [ ... ] }
        }
    }
  }
}

ゲートウェイレスポンスインターセプター Lambda 関数は、transformedGatewayResponse フィールドを含むレスポンスを返す必要があります。

{
  "interceptorOutputVersion": "1.0",
  "mcp": {
    "transformedGatewayResponse": {  // <-- インターセプターのコード内で、このフィールドを追加する必要があります 
        "statusCode": 200,
        "headers": { ... },
        "body": { ... }
    }
  }
}

このリクエスト・レスポンス構造の理解は、後半で説明するカスタムインターセプターのロジック実装に不可欠です。ゲートウェイインターセプターは、エージェント型 AI ワークフローのセキュリティと管理に重要な機能を提供します。

  • ヘッダー管理 – カスタムヘッダーを通じて認証トークン、相関 ID、メタデータを渡す
  • リクエスト変換 – ターゲットサービスに到達する前にリクエストペイロードの変更、コンテキストの追加、データの強化を行う
  • セキュリティ強化 – カスタム認証、認可、データのサニタイズロジック (機密データ編集など) を実装
  • きめ細かなアクセス制御 – 呼び出し元のアクセス権限に基づいて MCP ツールへのアクセスを保護し、AgentCore Gateway への
    ListTools、InvokeTool、Search 呼び出しに対してコンテキストに応じて応答
  • マルチテナント MCP ツールのテナント分離 – マルチテナント環境において、呼び出しユーザー、エージェント、テナント ID に基づいてテナント分離とアクセス制御を実装
  • オブザーバビリティ – エージェントワークフローを監視するためのロギング、メトリクス、トレース情報を追加

ゲートウェイインターセプターは、Lambda 関数、OpenAPI エンドポイント、MCP サーバーなどの AgentCore Gateway ターゲットタイプと連携します。

ゲートウェイインターセプターのユースケース

ゲートウェイインターセプターを使用することで、エージェント型 AI システムに柔軟なセキュリティとアクセス制御パターンを実装できます。本記事では、3 つのアプローチを紹介します。ツール呼び出しのきめ細かなアクセス制御、ユーザー権限に基づく動的なツールフィルタリング、分散システム間でのアイデンティティ伝播です。

ツール呼び出しのきめ細かなアクセス制御

AgentCore Gateway は、統一された MCP エンドポイントを通じて複数のバックエンドツールを公開します。異なるロールを持つユーザーには、異なるツールのアクセス許可が必要です。JWT スコープとゲートウェイインターセプターを組み合わせることで、ユーザーが認可されたツールのみを呼び出し、ロールやワークスペースに属するツールを検出できるようにします。きめ細かなアクセス制御では、Amazon Cognito または他の OAuth 2 プロバイダーが発行する JWT スコープ値を使用します。YAML ファイルや権限マッピングテーブルを持つデータベースでの実装も可能です。今回はシンプルな命名規則に従い、ユーザーは MCP ターゲットへのフルアクセス (例: mcp-target-123) またはツールレベルのアクセス (例: mcp-target-123:getOrder) を受け取ります。これらのスコープは OAuth トークン内のスコープクレームとして表現され、ツール権限に直接対応するため、認可モデルが予測可能で監査も容易です。

次の図は、このワークフローを示しています。

リクエストインターセプターは、以下のステップを通じて実行時にアクセス許可を適用します。

  1. JWT を抽出してデコードし、スコープクレームを取得します。
  2. tools/call を使用して、呼び出されているツールを特定します。
  3. 設定ファイルまたはアクセスポリシーデータストアを参照し、ユーザーにフルターゲットアクセスまたはツール固有の権限がない場合はリクエストをブロックします。
  4. 認可されていない呼び出しに対しては、構造化された MCP エラーを返し、バックエンドツールハンドラーの実行を防ぎます。

今回のサンプルでは、例えば以下の通り、認可機能の中核部分は意図的に最小限にしています。

def check_tool_authorization(scopes, tool, target):
    if target in scopes:
        return True 
    return f"{target}:{tool}" in scopes

このパターンにより、呼び出しと検出パスの両方で予測可能な認可の適用が可能になります (詳細は次のセクションで説明します)。マルチテナントアーキテクチャでは、追加のクレーム (例: tenantId、workspaceId) でモデルを拡張できます。

運用セキュリティのため、インターセプターは決定論的な動作を保ち、複雑な分岐ロジックを避け、LLM の指示ではなくトークンクレームのみに依存するようにしてください。インターセプターを用いて、LLM がツールを参照または実行する前にゲートウェイ境界で認可を実施することで、ツール実装や MCP ターゲットを変更することなく、ロール、テナント、ドメイン間の強力な分離を実現できます。

ツール検出の動的なフィルタリング

エージェントは、2 つの主要な方法で利用可能なツールを検出します。1 つは自然言語クエリ (「注文管理に関連するツールを探す」など) を可能にするセマンティック検索機能、もう 1 つは利用可能なツールの完全なインベントリを提供する標準的な (tools/list) 操作です。この検出メカニズムはエージェントの機能の基本ですが、重要なセキュリティ上の考慮が必要です。適切なフィルタリング制御がない場合、MCP サーバーはリクエストしているエージェントやユーザーの認可レベルに関係なく、利用可能なすべてのツールリストを返してしまいます。この制限のないツール検出により、未認可のユーザーやエージェントに機密性の高い機能を公開し、潜在的なセキュリティ脆弱性を生み出します。

ターゲットがセマンティック検索や MCP tools/list リクエストに応答してツールの一覧を返す際、ゲートウェイレスポンスインターセプターを使用してきめ細かなアクセス制御を実施できます。インターセプターはリクエストしているエージェントにレスポンスが到達する前に処理するため、ユーザーは許可されたツールのみを検出できます。このワークフローは以下のステップで構成されています。

  1. ターゲットは、受信した JWT トークンを検証し、きめ細かなアクセス制御とは無関係に、全ツール一覧またはセマンティック検索でフィルタリングされたサブセットを返します。
  2. 設定されたレスポンスインターセプターが AgentCore Gateway によって呼び出されます。レスポンスインターセプターはペイロードから JWT を抽出デコードし、ユーザーの権限を定義するスコープクレームを取得します。
  3. インターセプターは、リスト内の各ツールについて、JWT スコープに基づいてユーザーの認可を評価します。
  4. ユーザーがアクセスを許可されていないツールはリストから削除されます。
  5. レスポンスインターセプターは、認可されたツールのみを含む変換されたレスポンスを返します。

以下の図は、MCP tools/list と AgentCore Gateway tools/call (セマンティック検索) の両方についてこのワークフローを示しています。

以下は、レスポンスインターセプター Lambda ハンドラーのコードスニペットです。このハンドラーは、JWT トークンの抽出、ツール一覧の取得、権限に基づくフィルタリングを実行し、認可されたツールのみを含む変換されたレスポンスを返します。

def lambda_handler(event, context):
    # ゲートウェイのレスポンスと認証ヘッダーを抽出
    gateway_response = event['mcp']['gatewayResponse'] 
    auth_header = gateway_response['headers'].get('Authorization', '')
    token = auth_header.replace('Bearer ', '')

    # JWT からスコープを抽出
    claims = decode_jwt_payload(token)
    scopes = claims.get('scope', '').split()
    
    # ゲートウェイのレスポンスからツール一覧を取得 (MCP tools/list リクエストの場合)
    tools = gateway_response['body']['result'].get('tools', [])
    # structuredContent フィールドから取得 (AgentCore Gateway のセマンティック検索を利用する場合)
    if not tools:
        tools = gateway_response['body']['result'].get('structuredContent', {}).get('tools', [])
    
    # スコープに基づきツールをフィルタリング
    filtered_tools = filter_tools_by_scope(tools, scopes)
    
    # 認可されたツールのみを含む変換されたレスポンスを返す
    return {
        "interceptorOutputVersion": "1.0",
        "mcp": {
            "transformedGatewayResponse": {
                "statusCode": 200,
                "headers": {"Authorization": auth_header},
                "body": {
                    "result": {"tools": filtered_tools}
                }
            }
        }
    }

filter_tools_by_scope 関数は、ユーザーに許可されたスコープに対して各ツールの認可チェックを実装します。

def filter_tools_by_scope(tools, allowed_scopes):
    """ユーザーが許可されたスコープに基づいてツールをフィルタリング"""
    filtered_tools = [] 
    for tool in tools:
        target, action = tool['name'].split('___')
        # ユーザーがターゲットへのフルアクセス、あるいは当該ツールへのアクセスを持つか確認
        if target in allowed_scopes or f"{target}:{action}" in allowed_scopes:
            filtered_tools.append(tool)
            
     return filtered_tools

完全な実装は GitHub リポジトリでご確認ください。

カスタムヘッダーの伝播

AI エージェントが複数の下流のサービスと連携する際、サービス境界を越えてユーザー ID (ユーザー識別子やユーザー情報) を維持することがセキュリティ、コンプライアンス、監査証跡にとって重要です。エージェントが AgentCore Gateway を通じてツールを呼び出す場合、元のユーザーの ID はエージェントからゲートウェイへ、そしてゲートウェイからターゲットサービスへと伝播する必要があります。適切な ID 伝播がなければ、下流のサービスはユーザー固有の認可ポリシーを適用したり、正確な監査ログを維持したり、テナント分離を実装したりすることができません。この課題は、異なるユーザーが同じエージェントインフラストラクチャを共有しながらも、厳格なデータ分離を必要とするマルチテナント環境でより深刻です。

ゲートウェイリクエストインターセプターは、以下のステップに従って、受信リクエストヘッダーとコンテキストから ID 情報を抽出し、下流のサービスが期待する形式に変換し、ターゲットサービスに到達する前にリクエストを拡張します。

  1. ゲートウェイリクエストインターセプターは、受信リクエストから認証ヘッダーを抽出し、下流のサービス向けに変換します。
  2. AgentCore Gateway はリクエストフローを調整し、インターセプターの実行を管理します。
  3. ターゲット呼び出しは、適切にフォーマットされた ID 情報を含む拡張されたリクエストを受け取ります。

ゲートウェイリクエストインターセプターは、ユーザーのアクションをエンドツーエンドで可視化し、サービス境界を越えて一貫した認可ポリシーを適用し、データ主権要件へのコンプライアンスを維持するのに役立ちます。

カスタムヘッダー伝播のワークフロー全体は以下のステップで構成されています。

  1. MCP クライアントが AgentCore Gateway を呼び出します。
  2. AgentCore Gateway がインバウンドリクエストを認証します。
  3. AgentCore Gateway がカスタムインターセプターを呼び出します。
  4. ゲートウェイリクエストインターセプターは、受信リクエストのペイロードを変換します。具体的には、下流の Lambda ターゲットに送信するパラメータとして認証トークンを追加します。受信した JWT をそのまま下流の API に送信すると、特権昇格や認証情報の盗難のリスクがあるため推奨されません (エージェントが下流の API のアクセストークンを使用して MCP サーバーを呼び出す必要がある例外的なケースを除く) 。リクエストからインバウンド JWT を削除し、下流の API を呼び出すための最小権限のスコープダウントークンを持つ新しい JWT を追加することもできます。
  5. AgentCore Gateway は変換されたリクエストでターゲットを呼び出します。ターゲットにはインターセプター Lambda 関数によって渡された認証トークンが含まれています。
  6. AgentCore Gateway がターゲットからのレスポンスを返します。

次の図は、このワークフローを示しています。

以下は、カスタムヘッダーの伝播を実行するインターセプター Lambda ハンドラーのコードスニペットです。

import json 
import uuid 

 def lambda_handler(event, context):
    # ゲートウェイへのリクエストを抽出
    mcp_data = event.get('mcp', {})
    gateway_request = mcp_data.get('gatewayRequest', {})
    headers = gateway_request.get('headers', {})
    body = gateway_request.get('body', {})
    extended_body = body 
    
    # 認証ヘッダーをパススルー
    auth_header = headers.get('authorization', '') or headers.get('Authorization', '')
    if "arguments" in extended_body["params"]:
        extended_body["params"]["arguments"]["authorization"] = auth_header 
    # 認証ヘッダーが保持された状態の、変換されたリクエストを返す
    response = {
        "interceptorOutputVersion": "1.0",
        "mcp": {
            "transformedGatewayRequest": {
                "headers": {
                    "Accept": "application/json",
                    "Authorization": auth_header,
                    "Content-Type": "application/json"
                },
                "body": extended_body 
            }
        }
    }
    return response

認証なしと OAuth ベースの認可

多くの企業では、ツールの検出可能性とセキュリティのバランスを取る柔軟な認可モデルが必要です。AI エージェントやアプリケーションが、認可なしで利用可能な MCP ツールを検出および検索できるようにし、ツールカタログ全体でシームレスなツールの探索とセマンティック検索を可能にするシナリオを想定してみましょう。一方で、これらのツールを実際に呼び出す際には、認可されたエージェントとユーザーのみがツールを実行できるように、OAuth ベースの厳格な認可が必要です。さらに、一部のツールは認証が必要で、他のツールはパブリックにアクセス可能、あるいは呼び出し元のプリンシパルの ID やコンテキストに基づいて異なる権限レベルが必要など、ツールごとの認可ポリシーが必要になる場合もあります。

AgentCore Gateway は、すべてのインバウンド呼び出しに対してゲートウェイレベルで「認証なし」の認可タイプを導入することで、この柔軟性をサポートするようになりました。「認証なし」を設定すると、検出目的ですべてのターゲットとツールに認証なしでアクセスできるようになります。メソッドレベル (ListTools と CallTools) での OAuth 認可を強制したり、ツールごとの認可ポリシーを実装したりするには、ゲートウェイインターセプターを使用します。ゲートウェイインターセプターを利用することで、インバウンドの JWT を検査し、認可サーバーのディスカバリ URL を使用して RFC 6749 の要件に対して検証し、特定のメソッドやツール呼び出しへのアクセスをプログラムで許可または拒否することができます。このアプローチにより、きめ細かな制御が可能になります。ListTools や SearchTools リクエストのディスカバリを開放しながら、CallTools リクエストには厳格な OAuth 検証を強制したり、ツール、ユーザーロール、実行コンテキスト、その他組織が必要とするビジネスロジックに応じてカスタム認可ロジックを実装したりすることができます。これらすべてを、MCP 呼び出しのセキュリティが確保され、セキュリティポリシーに準拠した状態で実現できます。

次の図は、このワークフローを示しています。

このプロセスは、すべてのインバウンドコールに対してデフォルトで no-auth が設定された AgentCore Gateway への認証なしの ListTools 呼び出しから始まります。この設定により、ユーザーは認証なしで利用可能なツールを確認できます。ただし、ユーザーが特定のツールを呼び出すために CallTool リクエストを行う場合は、認証が必要です。AgentCore Gateway はカスタムリクエストインターセプター Lambda 関数を呼び出し、認証ヘッダーから JWT トークンを検証し、呼び出されている特定のツールに対するユーザーのスコープと権限をチェックします。認証が成功すると、インターセプターは必要な認証コンテキストでリクエストを変換および拡張し、AgentCore Gateway は変換されたリクエストをターゲットサービスに転送します。ターゲットはリクエストを処理してレスポンスを返し、AgentCore Gateway はそのレスポンスをクライアントに返します。このプロセスにより、ツール一覧の確認はオープンに保ちながら、実際のツール実行には厳密な OAuth ベースの認証を適用します。

インバウンドコールに対して認証なしで設定されたゲートウェイを作成するには、次の CreateGateway API に示すように、authorizerType を NONE に設定します。

{
  "name": "no-auth-gateway",
  "protocolType": "MCP",
  "protocolConfiguration": {
    "mcp": {
      "supportedVersions": ["2025-03-26"] 
    }
  },
  "authorizerType": "NONE",
  "roleArn": 
}

オブザーバビリティ

AgentCore Observability が提供する包括的なオブザーバビリティは、AgentCore Gateway を通じて複数のツールやサービスと連携する AI エージェントワークフローの監視、デバッグ、監査に不可欠です。ゲートウェイインターセプターは、下流のサービスが実行される前に認可を強制し、リクエストを変換し、データをフィルタリングするため、オブザーバビリティのレイヤーは重要なセキュリティ境界となります。これにより、以下の主要なメリットが得られます。

  • セキュリティ判断の可視化 – インターセプターは、許可/拒否の判断や評価された JWT スコープを含む、認可結果の信頼できるログを生成します。これにより、拒否されたリクエストの確認、ポリシーの動作の検証、ツール呼び出し全体での認可ルールの適用状況の分析に使用できる明確な監査証跡が提供されます。
  • リクエストとレスポンスのトレーサビリティ – インターセプターは、ヘッダーの拡充、スキーマ変換、機密データの編集など、MCP リクエストとレスポンスがどのように変更されたかを記録します。これにより、ペイロードの変更を完全にトレースでき、エージェントのワークフロー全体で安全かつコンプライアンスに準拠したデータ処理をサポートします。
  • 下流ツールの可観測性 – インターセプターは、ステータスコード、レイテンシー、エラーレスポンスなど、下流ツールの動作をログに記録します。これにより、ターゲット全体で一貫した可視性が確保され、チームは障害のトラブルシューティング、信頼性の問題の特定、エンドツーエンドの実行特性の理解が容易になります。

これらのログはアイデンティティとコンテキストの属性も取得するため、複数のユーザーグループやテナントが同じゲートウェイを共有する環境で、認可の動作を検証し、問題を特定するのに役立ちます。ゲートウェイインターセプターは AgentCore Observability と自動的に統合され、以下の機能を提供します。

  • 認可の判断のリアルタイムモニタリング
  • 所要時間と呼び出し指標によるパフォーマンスのボトルネック特定
  • マルチホップのエージェントワークフローにおけるエンドツーエンドのトレーサビリティ
  • マルチテナント環境での認可動作を検証するためのID とコンテキスト属性

次のスクリーンショットは、ゲートウェイインターセプターの Amazon CloudWatch ロググループからのサンプルメトリクスを示しています。

メトリクスによると、ゲートウェイインターセプターは 100% の成功率、最小限のレイテンシー (平均 4.47 ミリ秒)、スロットリングの問題がないなど、健全なパフォーマンスを示しています。これは、システムが最適なパラメータ内で動作しているということです。

次のスクリーンショットは、ゲートウェイインターセプターの CloudWatch からのサンプルログを示しています。

AgentCore Observabilityとの統合により、認可の判断をリアルタイムでモニタリングし、パフォーマンスのボトルネックを特定し、マルチホップのエージェントワークフローにおけるエンドツーエンドのトレーサビリティを維持できます。

まとめ

エージェント型 AI システムを大規模に展開する際、組織はセキュリティとアクセス制御という根本的な課題に直面します。AgentCore Gateway のゲートウェイインターセプターは、この課題を解決します。本稿で紹介した 3 つのパターン (ツール呼び出しに対するきめ細かなアクセス制御、ツールの動的なフィルタリング、アイデンティティ伝播) は、安全なエージェント型アーキテクチャを構築するための基盤となる構成要素 (ビルディングブロック) です。これらのパターンにより、認証のギャップを埋め、認証情報を適切に分離し、独自のセキュリティポリシーを適用できます。ゲートウェイインターセプターは、リクエストとレスポンスの両方にプログラム可能な介入ポイントを提供します。これにより、既存のツール実装や MCP サーバーアーキテクチャに手を加えることなく、きめ細かなアクセス制御を実装できます。組織が数百のエージェントと数千のツールに拡大すると、複雑なエージェント型 AI 環境全体でセキュリティ、コンプライアンス、運用の可視性を確保することが不可欠です。ゲートウェイインターセプターは、そのために必要な柔軟性と制御機能を提供し、エンタープライズ統合パターンやセキュリティのベストプラクティスにも準拠しています。ゲートウェイインターセプターを備えた AgentCore Gateway は、エージェント型 AI アーキテクチャにエンタープライズグレードのセキュリティ制御を実装するための柔軟な基盤となります。一般的なエンタープライズの課題に対してゲートウェイインターセプターをどのように活用できるかについて、詳しくは以下のコードサンプルをご参照ください。

ゲートウェイインターセプターの設定とデプロイメントに関する完全なドキュメントについては、Amazon Bedrock AgentCore Gateway のきめ細かなアクセスコントロールを参照してください。

著者について

Dhawal Patel は AWS のプリンシパル Generative AI テックリードです。大企業から中規模のスタートアップまで、さまざまな組織と共に、エージェント AI、ディープラーニング、分散コンピューティングに関する課題に取り組んできました。
Ganesh Thiyagarajan は、ソフトウェアアーキテクチャ、IT コンサルティング、ソリューション提供において 20 年以上の経験を持つ AWS のシニアソリューションアーキテクトです。ISV が AWS 上でアプリケーションを変革し、モダナイズするためのサポートを行っています。また、AI/ML テクニカルフィールドコミュニティのメンバーとして、お客様の生成 AI ソリューションの構築とスケーリングを支援しています。
Avinash Kolluri は AWS のシニアソリューションアーキテクトです。Amazon とその子会社と協力して、イノベーションと運用の優位性を加速するクラウドソリューションの設計と実装を行っています。AI/ML インフラストラクチャと分散システムに関する深い専門知識を持ち、基盤モデルの構築、ワークフロー自動化、生成 AI ソリューションのために AWS サービスを活用するお客様を支援することを専門としています。
Bhuvan Annamreddi は AWS のソリューションアーキテクトです。ISV のお客様と協力して高度なクラウドアーキテクチャの設計と実装を行い、AWS サービスを活用して製品の強化を支援しています。生成 AI とサーバーレスアーキテクチャに強い関心を持ち、意味のあるビジネス価値を提供するためのイネーブラーとして、お客様のスケーラブルで安全な革新的なシステムの構築を支援することに情熱を注いでいます。
Mohammad Tahsin は AWS の Generative AI スペシャリストソリューションアーキテクトとして、最新の AI/ML ソリューションの設計、最適化、デプロイについてお客様をサポートしています。この分野における新しい機能の最前線に立ち続けることと継続的な学習に情熱を注いでいます。趣味は、ゲーム、デジタルアート、料理です。
Ozan Deniz は AWS のソフトウェア開発エンジニアとして働いています。彼とチームは生成 AI によって販売者の機能を強化することに注力しています。仕事以外の時間はアウトドア活動を楽しんでいます。
Kevin Tsao は AgentCore Gateway チームのソフトウェア開発エンジニアです。Amazon に在籍して 6 年になり、その間、Bedrock Agents や Amazon Lex などのサービスに貢献し、会話型 AIとエージェント型 AI の分野で働いています。

本記事の翻訳は Solutions Architect の安藤慎太郎が担当しました。原文はこちらです。