AWSが、複数の顧客組織を同時にさばくAIエージェントで、利用者本人の身元を保ったまま下流APIを呼ぶ「代理トークン交換（OBO）」の実装手順を公開した。Amazon Bedrock AgentCore GatewayとAgentCore IdentityがOAuth 2.0のトークン交換規格（RFC 8693）に沿ってトークンを差し替える。
AWSがAmazon Bedrock AgentCore Gatewayを使い、複数の顧客組織（テナント）を束ねるAIエージェントが利用者本人の身元を保ったまま下流APIを呼ぶ「代理トークン交換（OBO）」の実装手順を公開した。AgentCore IdentityがOAuth 2.0のトークン交換規格（RFC 8693）を認証情報の付与方式として標準対応する。
方式の核は2点。宛先（audience）を暗号的に縛ることで、あるテナント向けに発行したトークンを別テナントのサービスで使えないようにする。また元の利用者の身元（sub情報）を経路全体で保ち、実際に交換を行った代理者（actor情報）を別項目に記録するため、監査ログで「誰の権限で誰が代理したか」を分けて追える。エージェント側に交換処理を書かず、AWS機能側で完結するのが実務上の利点だ。
参照実装「TravelBot」はAcmeとGlobexの2テナントを扱う予約アシスタントで、認証基盤にOktaを用いる。実装コードはaws-samples/sample-obo-flow-pocリポジトリで公開予定。
この変化で何が要点か。図解と出典つきで一目で。
構造化された事実を最初に。誰が何をいつどこでなぜどのように。
生成AIエージェントを本番の多テナント環境に置くと、身元の問題が生じる。エージェントが利用者の代わりに下流APIを呼ぶとき、誰の身元が呼び出しに乗るのかが曖昧になる。エージェント自身の身元で呼ぶと監査ログが崩れ、逆に利用者のトークンをそのまま転送すると下流のツールが「混乱した代理人（confused deputy）」問題に陥る。1つのエージェントが多数のテナントを束ね、しかもツール呼び出し時点で利用者が不在という状況では、どちらの方式も破綻する。この課題を解くのがトークン交換規格（RFC 8693）である。
AIエージェントを企業の本番システムに載せる際、権限と監査の設計は避けて通れない論点になっている。この方式は、下流の呼び出しごとに宛先（対象サービス）を暗号的に縛り、他テナントへの流用を防ぎつつ、元の利用者の身元を最後まで保つ。認証基盤（Okta等）とAWSの機能で実現でき、エージェント開発者が独自に交換ロジックを書かずに済む点が実務的に効く。
AIエージェントを本番の多テナント環境に置くと、下流のAPIを呼ぶとき「誰の身元でその呼び出しをするのか」が曖昧になる。エージェント自身の身元で呼べば監査ログが崩れ、逆に利用者のトークンをそのまま下流に転送すると、下流ツールが「混乱した代理人（confused deputy＝本来の権限を越えて代理実行してしまう状態）」に陥る。1つのエージェントが多数の顧客組織（テナント）を束ね、ツール呼び出しの時点で利用者本人が不在という状況では、どちらの方式も破綻する。
AWSはこの課題への実装手順を公開した。Amazon Bedrock AgentCore GatewayとAgentCore Identityが、OAuth 2.0のトークン交換規格（RFC 8693）に沿ってトークンを差し替える。
This post is the implementation guide. It walks through a complete multi-tenant OBO setup against Okta, shows the JSON Web Token (JWT) claim transformations on each hop, and demonstrates how audience binding produces defense in depth that scales across tenants.
つまり、認証基盤にOktaを使った多テナントの代理トークン交換（OBO）の設定を丸ごと辿り、各ホップでのJSON Web Token（JWT＝身元情報を含む署名付きトークン）のクレーム変換と、宛先を縛ることで多テナント全体に効く多層防御を示している。
この方式の核は2つある。1つは宛先（audience）を暗号的に縛ること。あるテナント（例: Acme）向けに発行したトークンには、そのテナントのサービス以外では使えないよう宛先が刻まれる。別テナント（例: Globex）のサービスに同じトークンを差し出しても拒否される。これが「多層防御が多テナント全体に効く」の中身だ。
もう1つは身元の保持。元の利用者の身元（JWTのsub情報）は下流への経路全体を通じて保たれ、実際にトークン交換を行った代理者（actor情報）は別項目に記録される。監査ログを見れば「誰の権限で、誰が代理して呼んだか」を分けて追える。エージェント自身の身元で呼ぶ方式が抱えていた「監査ログが誰の操作か分からなくなる」弱点を、この分離が埋める。
重要なのは、これらの差し替えをエージェント側のコードに書かない点だ。AgentCore GatewayとIdentityが交換処理を担うため、開発者はRFC 8693の交換ロジックを自前で実装しなくてよい。
公開された参照実装は「TravelBot」という予約アシスタントだ。AcmeとGlobexという2つのテナントを扱い、認証基盤にOktaを用いる構成になっている。
— aws-samples/sample-obo-flow-poc
注入素材に基づく範囲で構成を示した。デモの詳細挙動はリポジトリ公開後の確認が必要になる。
立場別、明日から動ける一手。
AgentCore Identityが対応するRFC 8693のトークン交換で、JWTのsub（本人）とactor（代理者）が各ホップでどう保持されるかを公式実装ガイドで確認する。
多テナントで顧客データを分離する要件を、宛先を縛ったトークン（audience binding）でどこまで満たすかの合否条件を定義する。
aws-samples/sample-obo-flow-pocの参照実装TravelBotを、AcmeとGlobexの2テナント構成でOktaに繋いで動かし、トークンの他テナント流用が実際に拒否されるかを試す。
本トピックはAWS Machine Learning Blogの実装ガイドとして公開されたばかりで、SNS上での目立った議論は確認できていない。
公式発表と各所の反応から編集部が要約した主な論点です。個別のX投稿そのものは下部のセクションに表示されます。
「confused deputy（混乱した代理人）問題」
読者の関心の核は、多テナントでAIエージェントを本番運用する際の「confused deputy（混乱した代理人）問題」をどう解くかにある。エージェント自身の身元で下流を呼ぶと監査ログが崩れ、利用者トークンをそのまま転送すると権限越えが起きるという既知の課題に対し、RFC 8693準拠のトークン交換で本人の身元(sub)を保ちつつ宛先(audience)を縛る設計が示された点が実装者の論点になる。参照実装TravelBotがOktaを前提にしている点も、既存認証資産との接続を検討する層の関心を集める要素だ。
※トレンド検出時刻付近の人気投稿を表示
