Okta XAAとAgentCore Gatewayで実現する、エージェント認可の集中管理と監査
個別接続からGateway集約へ：エージェント数の増加に備える構成
Part 1では、Amazon Bedrock AgentCore Runtime上のエージェントが、Okta Cross App Access（XAA）による委任認可を使ってMCPサーバーへ接続する構成を実証した。しかし、エージェントが各MCPサーバーのARNを保持して直接呼び出す方式では、エージェント数をN、ツール数をMとすると接続関係がN×Mの配線に近づく。新しいツールを追加するたびに、利用する各エージェントの設定変更が必要になる。
Part 2では、Amazon Bedrock AgentCore Gatewayを単一の入口として導入し、ツールターゲットの登録と認可を集約する。エージェントはGatewayのエンドポイントだけを知り、Gatewayが対象ツールを選択して呼び出す。さらに、トークン交換をエージェントではなくGateway側に移すことで、エージェントの実行ロールからトークン交換権限とプロバイダーのシークレット参照権限を取り除く。これは単なる接続簡略化ではなく、委任資格情報へのアクセス範囲を縮小する設計上の変更である。
Gatewayのインバウンド認可では、Okta組織認可サーバーを発行者として検証し、対象のカスタム認可サーバーをaudienceに指定する。allowedClientsで許可するエージェントのクライアントIDを固定し、allowedScopesにはxaa:readとxaa:writeを設定する。各MCPサーバーはGatewayのターゲットとなり、Part 1で作成した認証情報プロバイダーを使ってTOKEN_EXCHANGEを実行する。ターゲット側のscopeはID-JAGのscopeと一致させる必要がある。
この構成では、エージェントごとに専用のGatewayと認証情報プロバイダーを用意する。プロバイダーがOkta上の単一エージェントとして認証するため、Gatewayを共有するとエージェント間のアイデンティティ境界が曖昧になるからだ。GatewayはID-JAGを対象ごとに交換するが、AgentCore Identityが交換後のトークンを保持するため、ツール呼び出しごとに単回使用のID-JAGを再発行する必要はない。記事の検証では、1つのID-JAGでセッション中の複数のツール呼び出しが可能で、5分の有効期間内に2つ目のセッションも開始できた。
Cedarによるツール単位の認可と、エージェント実行環境からの分離
GatewayにはAgentCore PolicyエンジンをENFORCEモードで接続し、許可専用ポリシーによるデフォルト拒否を適用する。Cedarポリシーは、JWTクレームとして公開されるタグを参照し、エージェントのclient_id、要求されたツール、委任されたscopeを組み合わせて判定する。たとえば書き込みツールを許可するには、対象Gatewayとツールアクションを指定したうえで、client_idが所定のエージェントと一致し、scopeにxaa:writeが含まれることを確認する。
scopeは空白区切りの文字列として扱われるため、xaa:writeを部分文字列検索するのではなく、単独、先頭、末尾、中間の各位置を考慮して完全なscope要素として照合する。これにより、xaa:write-adminのような似た文字列が誤って許可されるのを防げる。また、Cedarでは存在しないタグへの参照を含むポリシーはエラーとなってスキップされる場合がある。hasTagで各タグの存在を確認するのは、欠損クレームを許可条件の意図しない成立につなげないためである。ポリシー作成後は、Gatewayへアタッチする前にすべてのポリシーがACTIVEであることを確認する。ポリシーエンジンのポリシー作成に失敗した状態では、Gatewayがすべての呼び出しを拒否し得る。
この集中ポリシーは、MCPサーバー側の認可を置き換えるものではない。Cedarは「このエージェントがこのツールを、この委任scopeで呼び出してよいか」をGatewayで判定する。一方、MCPサーバーは従来どおりユーザーのグループ情報に基づき、個々のユーザーが操作できるかを決める。エージェント、委任scope、ユーザー権限という異なる認可軸を、入口とリソースの両方で検証する多層構成である。
Part 1のエージェントは、受信したID-JAGをBearer tokenとしてGatewayに転送する。実行ロールからはAgentCore Identity関連の権限を削除し、Runtime側のallowedClientsは維持する。EKS上の第2のエージェントも同じGateway経由のパターンを使い、読み取りscopeのみを持つ独自のOkta登録、Gateway、認証情報プロバイダーを利用する。EKS Pod IdentityのIAMロールには、モデル呼び出しと自身のログ・トレース書き込みだけを与える。AgentCore Runtimeの外側にはRuntime authorizerがないため、EKSのエージェントはモデル呼び出し前にID-JAGの署名、発行者、audience、oauth-id-jag+jwt型、期限、自身のclient_idを検証する必要がある。
トレースとOkta監査ログを結ぶ認可の検証可能性
AgentCore Runtime、Gateway、Identity、Policyは、各処理段階のOpenTelemetry spanを出力する。MCPサーバーやBFFなど独自サービスのトレースにはAWS Distro for OpenTelemetry（ADOT）を利用し、CloudWatch Transaction Searchへ集約する。OktaのSystem LogはAmazon EventBridge経由でCloudWatch Logsへ取り込む。これらをCloudWatch Omniで照会することで、Oktaが発行したID-JAGのイベントと、その後にMCPサーバーが記録した許可・拒否判断を関連付けられる。
1回のツール呼び出しには、GatewayのInboundAuth、PolicyのAuthorizeAction、Identityのワークロードアクセストークン取得とリソースOAuthトークン交換、Gatewayのツール呼び出し、MCPサーバーのauthz.checkなどのspanが対応する。authz.checkにはユーザー、エージェント、判断、理由を記録する。記事の例では、OktaのID-JAG付与イベントと、Aliceに対するcreate_taskの拒否およびlist_tasksの許可が、同じクエリで追跡された。
24時間分のGateway Aの計測では、インバウンド認証の中央値／p90は34／69ミリ秒、Identityのリソーストークン交換は70／439ミリ秒、Cedarのツール呼び出し認可は47／56ミリ秒だった。ツール一覧の部分認可は65／75ミリ秒、GatewayからAgentCore Runtime上のMCPサーバーへのターゲット呼び出しは5,565／6,273ミリ秒である。IdentityとPolicyに関する処理は中央値で合計約0.2秒、MCPサーバー内のauthz.checkは1ミリ秒未満だった。つまり、計測例では認可制御の遅延よりもツール自体の呼び出しが大きな時間を占める。ただし、トークン交換はp90で439ミリ秒に達しており、尾部遅延を含めた評価が必要である。Gateway Bでも、リソーストークン交換の中央値は408ミリ秒だった。
検証では、agent AのGatewayはAliceとCarolの書き込みをMCPサーバーで拒否し、Bobのタスク作成を許可した。読み取り専用のagent Bでは、Cedarが書き込みツールを一覧から隠し、仮に要求された場合もデフォルト拒否となった。また、別エージェント向けID-JAGやID-JAG以外のOktaアクセストークンはGatewayで拒否され、トークンなしの要求は401となった。EKS上のagent Bにagent AのID-JAGを送る試験では、モデル呼び出し前の98ミリ秒で「別のエージェント向け」と判定された。
XAAとユーザーごとのOAuth同意は、対象アプリケーションの認可サーバーがID-JAGを受け入れるかどうかで使い分ける。XAAではOkta管理者がエージェントとユーザーの利用関係を制御し、ユーザーに同意画面を提示せず、トークン要求ごとにOktaがポリシーを評価する。記事の測定では、XAAの停止後は新しいID-JAGの発行が止まり、発行済みトークンも約5分で期限切れとなる。一方、独自認可サーバーを持つGitHubの例では、ユーザー同意による保存済みgrantがOktaでのユーザー停止後も残り、同意ポータルから切断するまで利用可能だった。後者のトークンは1時間有効で、停止前に発行されたものは再利用できた。したがって、失効モデルは企業全体で一律に決めず、対象アプリケーションごとに選択する必要がある。
開発者・エンジニア視点での考察
-
ツール一覧も認可対象として設計する。 Gatewayはターゲット単位で
tools/listをページングするため、クライアントはページングカーソルを最後まで追跡しなければ、後続ターゲットのツールを取りこぼす。また、Cedarポリシーが参照するツール名を固定するには、ターゲットに静的なツールスキーマを設定する。記事の検証では、動的に一覧化されるターゲットにツール名を指定したポリシーを適用できなかった。認可ポリシー、ツールスキーマ、クライアントのページング実装を一体でテストするのが重要である。 -
EKS移行では、認証の信頼境界をRuntime外に補う。 AgentCore Runtimeにはauthorizerがあるが、EKS Podの前には同等の入口がない。ID-JAGの署名・発行者・audience・型・期限・
client_idをモデル呼び出し前に検証しないと、誤ったエージェント向けの委任トークンが推論処理へ到達し得る。さらに、記事の実装上の注意として、EKS Auto Modeの汎用ノードプールはamd64のみのためマルチアーキテクチャイメージが必要であり、AgentCore Python SDKはDOCKER_CONTAINER=trueを設定しないとlocalhostへbindする。認可設計とコンテナ実行条件を同じデプロイ検証に含めるべきである。 -
相関可能な監査データを、実装初期からスキーマ化する。 Oktaイベントとアプリケーション側の判断を後から結合するには、少なくともユーザー識別子、エージェントID、判断時刻、判断結果、理由を安定したフィールドとして記録する必要がある。ADOTのエクスポートには
botocoreが必要なサービスがあり、欠落するとMCPサーバーのspanが出力されない場合がある。また、ADOTのagent modeはrequestsやurllib3などHTTPクライアントの計装を既定で無効にするため、BFFからエージェントへのtrace context伝搬が途切れないよう設定を確認する。可視化の完成後ではなく、トレース伝搬とログ相関を認可テストの受け入れ条件にするのが有効である。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
