Bedrock AgentCore、マルチテナント向け代理トークン交換を実装

AWSは、Amazon Bedrock AgentCore GatewayとOktaを使い、利用者の権限を保ったまま下流ツール用のトークンへ交換する代理実行の実装例を公開しました。

要点

• 受信JWTを検証し、テナントと利用者の主張を下流向けトークンへ変換します。
• 各通信段階で対象サービスを束縛し、別サービスへのトークン流用を防ぎます。
• Gateway interceptorで細かな認可を行い、共通の強いサービス資格情報に置き換えない設計です。

今回のブログ記事で語られていること

複数顧客が一つのエージェント基盤を使う場合、エージェント自身の資格情報だけでツールを呼ぶと、誰の権限でデータへアクセスしたのかが曖昧になります。代理トークン交換は、利用者が認証された事実と所属テナント、許可範囲を、下流APIが検証できる別のトークンへ安全に写す仕組みです。記事はOktaをID基盤に使い、AgentCore Gatewayまでの各段階でJWTの主張がどう変わるかを示しています。

重要なのは、同じトークンをすべてのサービスで使い回さないことです。発行先を表す対象サービスを各段階へ限定すると、あるツール向けに盗まれたトークンを別のツールへ提示しても拒否できます。Interceptorでは、テナントID、利用者ID、権限範囲、呼び出すツールを照合し、要求ごとに許可を判断します。下流側も署名、発行者、対象サービス、有効期限を検証する必要があり、Gatewayだけを信頼して検証を省く構成にはしません。

実装時には、テナントIDを利用者入力から受け取らず、検証済みのID基盤の主張から導出します。トークン交換の失敗を安易にサービス全体の資格情報へ切り替えると、最小権限が崩れます。管理者権限、通常利用者、別テナント、期限切れ、誤った対象サービス、失効済みセッションを試し、拒否が監査ログへ残るか確認してください。ログには生のトークンを保存せず、追跡用IDと許可判断の理由を残します。

鍵更新やID基盤障害も試験対象です。新旧署名鍵が併存する期間、有効期限の境界、時刻ずれ、利用者の所属変更が、既存セッションへどう反映されるかを確認してください。

運用開始後は、許可・拒否件数とトークン交換の遅延をテナント別に監視し、急な変化を権限設定の変更履歴と照合します。

今回のブログ記事が関係する人

SaaS型AIエージェントの認証設計者、AgentCore Gateway運用者、Oktaと下流APIの権限を管理する担当に関係します。

結局、今回のブログ記事をどう読むべきか

エージェントへ強い共通権限を渡すのではなく、利用者の権限を検証可能な形で下流まで伝える実装ガイドです。テナント分離はプロンプトではなくIDとトークン検証で担保すべきです。