連載後編はツールへの入口、トークン交換、ポリシーと監査を集約します。別のEKS上のエージェントも同じ仕組みで認可する例です。 エージェントごとの秘密情報を減らす一方、Gatewayと認証設定が重要になります。概念例をそのまま本番向け完成構成と扱わないことが焦点です。 小規模な代理実行を多数の道具へ広げる AWSは11月6日、Okta Cross App AccessとAmazon Bedrock AgentCoreを組み合わせる連載の後編を公開しました。前編の一つのエージェントと二つのMCPサーバーを、企業内の多くの道具へ広げる課題を扱います。各エージェントが接続先を個別に持ち、各サーバーに同じ認可処理を複製すると、変更や監査の負担が増えます。後編はAgentCore Gatewayを入口とし、代理権限の交換とCedarによるポリシーを集約する構成です。新しい認可製品を発表したものではなく、既存機能を組み合わせた実装上の解説です。 入口で判定し許可された呼び出しだけ進める GatewayはOktaが発行した代理実行の証明を受けます。Cedarのポリシーが道具の一覧と呼び出しを検査し、許可した場合だけ接続先向けのトークン交換を進めます。エージェント側のロールから交換権限や秘密情報へのアクセスを外す構成です。接続先のMCPサーバーも利用者の所属と範囲を確認します。別のエージェントをAmazon EKS上に置き、実行場所が異なっても同じ考え方を使えることを示しています。各段階のOpenTelemetry記録とOktaのログをCloudWatchへ集めます。影響を受けるのは、業務エージェントを複数の部署へ展開する基盤担当者と見られます。モデルの指示で権限を決めるのではなく、入口と接続先の検査を対応させることが中心です。 共有化しても設定の条件は省けない 原文は、説明中の設定や断片コードが完全な配備可能構成ではなく、本番向けではないサンプルだと明示しています。導入では、トークンの発行者、対象、利用範囲、エージェントとの結び付きをそろえることが論点です。ツール名を参照するポリシーには固定スキーマを使う説明があり、動的な一覧へ単純に置き換えることはできません。一覧のページ送りを処理しないと後続の道具が見えなくなる点も紹介しています。複数エージェントではGatewayと資格情報の対応を保つ必要があります。EKSやAgentCoreの利用料に加え、認証変更と監査の保守工数も評価対象と見られます。拒否した呼び出しと成功した呼び出しを一連の記録で追えるか、例外時の動作を含めて確認することが次の判断点です。 拒否の理由を横断して説明できるか 入口を集める効果は、設定の変更箇所を減らすことだけではありません。利用者の割り当て、代理権限、道具のポリシーのどこで拒否されたかを追えることも重要になると見られます。次の判断点は、許可と拒否の両方を監査記録で説明できるかです。接続先を追加する前に、期限切れや不足した属性を試し、意図せず許可されないことを確認する方法が考えられます。大規模化の前に共通の変更手順を整えることが焦点です。拒否の記録も設計の成果になります。