Amazon Bedrock AgentCore Gatewayを活用したマルチテナント向け「代理トークン交換」の実装ガイドが公開

要点

• AWSが、Amazon Bedrock AgentCore Gatewayを用いた「オンベハーフオブ（OBO）トークン交換」の具体的な実装ガイドを公開した。

• 生成AIエージェントが複数のテナント（顧客）に代わって下位APIを呼び出す際の、なりすましやセキュリティ上の脆弱性を防ぐための手法を解説している。

• 標準規格である「OAuth 2.0 Token Exchange（RFC 8693）」を利用し、エージェントの実装ロジックを増やすことなくセキュリティを担保できる。

• ガイドではOktaを用いた具体的な設定や、リファレンス実装「TravelBot」を通じた動作検証手順が紹介されている。

• アマゾン ウェブ サービス（AWS）は2026年7月13日、公式のAWS ML Blogにおいて、マルチテナント環境の生成AIエージェントに「オンベハーフオブ（OBO：代理）トークン交換」を導入するための実装ガイドを公開した。このガイドは、Amazon Bedrockのコンポーネントである「Amazon Bedrock AgentCore Gateway」を活用し、安全にユーザーのアイデンティティ（身元情報）を伝播させる手法を示している。エージェントが複数の組織や顧客に代わって処理を行う際に発生するセキュリティ課題を解決するアプローチとして注目される。

増加する生成AIエージェントのアイデンティティ管理課題

プロダクション環境において、生成AIエージェントを複数のテナント（顧客企業や組織）が共同で利用するマルチテナント構成でデプロイする場合、アイデンティティ管理に特有の課題が生じる。エージェントがユーザーの代わりに下位（ダウンストリーム）のAPIを呼び出す際、どのアイデンティティ情報を送信すべきかという問題である。

従来のアプローチには大きく分けて2つの選択肢があったが、いずれも課題を抱えていた。
1つ目は、エージェント自身のサービス用アイデンティティを用いてAPIを呼び出す方法である。この場合、下位システムはエージェントからのアクセスを無条件で信頼する必要があるため、誰が操作したかを示す監査証跡（システムの操作履歴）が失われてしまうという問題が生じる。
2つ目は、ユーザーの認証トークンをそのまま下位のシステムへ転送する方法である。しかし、この方法では、本来そのユーザーがアクセスすべきではない他のツールやシステムに対してトークンが悪用される「代理人攻撃（権限を持つプログラムを騙して不正な操作を行わせる問題）」のリスクが高まる。ユーザーがツール呼び出しの瞬間に立ち会っていないエージェント型のシステムにおいて、これらのアプローチはスケーラビリティやセキュリティの面で限界を迎えていた。

標準規格「OAuth 2.0 Token Exchange」による解決

この課題を解決するため、業界標準の仕様である「OAuth 2.0 Token Exchange（RFC 8693）」が用いられる。Amazon Bedrock AgentCore Identityは、このトークン交換仕様をネイティブな資格情報プロバイダーのグラントタイプ（認証情報の付与方式）としてサポートしている。

今回の実装ガイドでは、この「オンベハーフオブ（OBO）トークン交換」を具現化する手順が解説されている。AgentCore Gatewayが中継役となり、ユーザーから送られてきたオリジナルのトークンを、呼び出し先となる特定のツールやサービスに限定された新しいトークンへと自動的に交換する。

この仕組みを導入することで、開発者は以下のメリットを得られる。

• テナント境界を越えたアイデンティティの伝播: sub（サブジェクト）クレーム（ユーザーを一意に識別するトークン内の属性情報）を通じて、元のユーザーの身元がエンドツーエンドで保持される。
• 暗号化による最小権限の原則: トークン内の aud（オーディエンス）クレーム（トークンの送信先システムを示す情報）が呼び出し先のサービスごとに制限される。これにより、あるテナント向けに発行されたトークンが、他のテナントや異なるサービスで不正利用されるのを防ぐ。
• エージェント側の実装負荷の軽減: トークンの交換処理はすべてAgentCoreが肩代わりするため、AIエージェント自体のプログラムコード内にトークン交換のための複雑なロジックを実装する必要がなくなる。エージェントは単に受け取ったトークンを使用してツールを呼び出すだけでよい。
• 標準規格への準拠: RFC 8693に準拠しているため、同規格をサポートするOktaなどの主要なアイデンティティ管理サーバー（IDP）と連携して機能する。

実装ガイドとリファレンス「TravelBot」

本ガイドでは、Oktaをアイデンティティ管理のサーバーとして設定し、マルチテナント環境でOBOトークン交換を実行するプロセスをステップバイステップで説明している。
また、具体的な動作を示すリファレンス実装として「TravelBot」と呼ばれる予約アシスタントの構成が紹介されている。このアシスタントは、架空の2つのテナント（AcmeおよびGlobex）のユーザーからの要求を処理し、JWT（JSON Web Token：署名付きのデータ形式）に含まれる各種クレームが、処理のステップごとにどのように変換されるかを示す。

なお、このガイドで使用されるリファレンスコードは、記事の公開後にGitHubの「aws-samples/sample-obo-flow-poc」リポジトリにて公開される予定となっている。

AWSは、エージェントが複数の下位サービスやマルチテナント環境に対応する場合にこのOBOパターンが不可欠であるとし、システム構築におけるセキュリティと運用のベストプラティスとして活用を推奨している。