本番環境では、AI エージェントは外部サービスに安全にアクセスする必要があります。Amazon Bedrock AgentCore Identity はスタンドアロンサービスとして、Amazon ECS、Amazon EKS、AWS Lambda、またはオンプレミスで実行される AI エージェントの外部サービスへのアクセスを保護します。
この記事は、Amazon ECS 上での認可コードグラント（3本足OAuth）の実装に焦点を当て、セキュアなセッションバインディングとスコープ付きトークンを提供します。以前の記事では AgentCore Identity の認証情報管理について説明しましたが、この記事では ECS のようなコンピューティング環境でエージェントを実行する際の2つの重要な問題を解決します：アプリケーション所有のセッションバインディングエンドポイントを構築する方法と、ワークロードアクセストークンのライフサイクルを管理する方法です。
このソリューションは OAuth 2.0（RFC 6749）と OpenID Connect（OIDC）を使用します。OIDC はユーザーの本人確認（誰であるか）を行い、OAuth 2.0 はユーザーのアクションを認可（何ができるか）します。この記事では、ユーザー委任アクセスのための認可コードグラントを重点的に説明します。ユーザーは ID プロバイダーで認証し、同意を与えます。その後、アプリケーションは認可コードをスコープ付きアクセストークンと交換し、Amazon Bedrock AgentCore Identity がそれをトークン保管庫に安全に保存します。各トークンは特定のユーザー ID と明示的な同意にバインドされているため、このソリューションはユーザー認証からエージェントアクションまでの監査可能なチェーンを維持します。
認可コードグラントは、ユーザーに代わって行動するエージェントワークロードに適しています。これは、エージェントが行動する前にユーザーの同意を必要とし、認可リクエストを開始したユーザーと同意を与えたユーザーが同一であることを確認するセッションバインディングを提供し、エージェントの権限をユーザーが承認した範囲に制限するスコープ委任を実現します。
ソリューション概要
この記事のアーキテクチャ図は、AgentCore Identity が Amazon ECS 上のセルフホスト AI エージェントをどのように保護するかを示しています。このソリューションは、ECS 上に2つのサービスをデプロイします。エージェントワークロード（AI エージェントを実行しユーザーリクエストを処理）と、セッションバインディングサービス（OAuth コールバックを処理し、ユーザーセッションをサードパーティのアクセストークンにリンク）です。両方のサービスは、Amazon Bedrock AgentCore Identity を使用して、OIDC によるインバウンド認証と、ユーザーに代わってのアウトバウンドアクションの認可を行います。
インバウンド認証とトラフィックルーティングは、Amazon Application Load Balancer (ALB) を介して行われます。ALB はビルトインの OIDC 認証フローを使用し、ユーザーのクレームを JWT 形式で x-amzn-oidc-data ヘッダーに注入します。エージェントワークロードは FastAPI サーバーを公開し、Strands Agents で構築されたエージェントにリクエストを渡し、Amazon Bedrock 上の大規模言語モデル（LLM）を呼び出します。エージェントがユーザーに代わって GitHub などのサードパーティサービスでアクションを実行する必要がある場合、AgentCore Identity を介して OAuth アクセストークンを要求します。有効なトークンが存在しない場合、AgentCore Identity は認可コードグラントフローを開始し、ユーザーにアクセス許可を求めます。ユーザーが許可すると、セッションバインディングサービスが AgentCore Identity を介して OAuth フローを完了し、認可を正しいユーザーセッションにバインドします。
セッションバインディング
セッションバインディングは、クロスサイトリクエストフォージェリ（CSRF）とブラウザスワップ攻撃の2つのセキュリティ脅威から保護します。CSRF では、攻撃者が自身の OAuth トークンを被害者の ID にバインドしようとし、被害者のエージェントが知らずに攻撃者のリソースにアクセスする可能性があります。ブラウザスワップ攻撃では、攻撃者が被害者を騙して自分に代わって同意させ、被害者の OAuth トークンを攻撃者の ID にバインドし、攻撃者が被害者のリソースに直接アクセスできるようにします。セッションバインディングは、エージェントワークロードでのユーザー ID とセッションバインディングサービスでのユーザー ID が一致することを保証することで、両方の攻撃を防ぎます。両方の ID は認証チェーンを通じて暗号的に検証されます。
GetWorkloadAccessTokenForUserId を使用する理由
推奨されるワークロードアクセストークン取得 API は GetWorkloadAccessTokenForJWT ですが、AWS ALB と Microsoft Entra ID の互換性の問題から、この記事では GetWorkloadAccessTokenForUserId を使用します。ALB の OIDC ハンドシェイクでは、アクセストークンのスコープが Microsoft Graph である必要がありますが、GetWorkloadAccessTokenForJWT では JWT の aud クレームがアプリケーションと一致する必要があり、両方を同時に満たすことができません。そのため、このソリューションでは ALB 署名付き JWT の sub クレームからユーザー ID を抽出し、GetWorkloadAccessTokenForUserId を呼び出します。
実装のポイント
記事では、ワークロードアクセストークンの取得、OAuth アクセストークンの要求、OAuth セッションバインディングの完了の具体的な実装を含む完全なコード例を提供しています。主要な設計上の選択肢は次のとおりです：ツールの戻り値の型として Pydantic BaseModel を使用（Strands が自動的に説明を派生）、型一貫性のあるエラー処理（認可が必要な場合は AuthorizationRequiredError を発生）、ツールごとに必要な最小限の OAuth スコープを宣言（最小権限の原則に従う）。
結論
この記事では、Amazon Bedrock AgentCore Identity を使用して Amazon ECS 上の AI エージェントを保護する方法を学びました。インバウンド認証は OIDC を介してユーザー ID を検証し、アウトバウンド認証は OAuth 2.0 とセッションバインディングを実装し、セッションバインディングをエージェントワークロードから分離することで独立したスケーリングと攻撃への防御を可能にします。このパターンは ECS、EKS、Lambda、または AWS 外部の環境で動作し、GitHub、Jira、Salesforce、Google Calendar などの OAuth 2.0 対応サービスにも拡張できます。