AWS Bedrock AgentCore と Okta を活用した AI エージェントガバナンスのスケーリング

Amazon Web Services は、安全な AI エージェント運用のスケーリング方法について詳述した技術ガイドの第2部を公開しました。2026年11月6日に公開されたこの記事では、エージェントとツール間の直接接続に代わる、集中化されたゲートウェイアーキテクチャへの移行方法を解説しています。このアプローチでは、Amazon Bedrock AgentCore、Okta Cross App Access、および Cedar ポリシーエンジンを使用して、数百のエージェントとツールにわたる権限を管理します。

何が起きたか

本シリーズの第1部では、エンジニアはサインインしたユーザーに代わって動作する単一タスクエージェントを構築しました。その初期設定では、小規模なトポロジーに依存しており、エージェントが Model Context Protocol (MCP) サーバーのランタイムアドレスを保持し、トークン交換を直接実行していました。概念実証（PoC）シナリオでは機能しましたが、システムが成長するにつれて、この方法は複雑な配列マトリクスを生み出します。新しいツールごとに、アクセスが必要なすべてのエージェントを更新する必要があり、各エージェントは到達可能なすべてのリソースに対する認証情報を保持しなければなりません。

新しいガイドでは、Amazon Bedrock AgentCore Gateway を「単一の入口」として導入することで、これらのスケーリング上の制限に対処しています。エージェントがツールを直接呼び出す代わりに、リクエストを Gateway 経由でルーティングします。このコンポーネントは、ツールが呼び出される前にアイデンティティの引き換え処理を行い、アクセスポリシーを適用します。また、Amazon Elastic Kubernetes Service (Amazon EKS) 上で稼働する第2のエージェントも導入され、ガバナンスモデルがエージェントのホスト場所に関係なく機能することを示しています。この変更により、セキュリティロジックが個々のサーバーから集中化されたポリシーエンジンへ移動し、コードの重複と監査の複雑さが軽減されます。

仕組み

このアーキテクチャの中心には AgentCore Gateway があり、エージェントから Identity Assertion JWT Authorization Grant (ID-JAG) を受け取ります。このトークンは、ユーザーがエージェントに行動を承認したことを証明します。Gateway のインバウンドオーソライザーは、そのトークンが Okta によって特定のエージェント向けに発行されたものであることを検証します。検証後、Gateway は Cedar によって駆動されるポリシーエンジンを参照します。これらのポリシーは、エージェントのアイデンティティとユーザーが付与したスコープに基づいて、どのツールを使用できるかを正確に定義します。ポリシーがアクションを許可する場合、Gateway は AgentCore Identity を使用して、Okta からスコープ付きアクセストークンへ ID-JAG を交換します。

このプロセスにより、エージェントが秘密の認証情報を扱ったり、自らトークン交換を実行したりすることがなくなります。エージェントの実行ロールには、トークン交換やシークレット読み取りの権限は不要になります。代わりに、Gateway がこれらの特権を保持します。MCP サーバーは最終的なユーザーグループチェックを引き続き実行しますが、主要な認可判断は Gateway で行われます。この分離により、組織は数千のサーバーにわたってコードを変更するのではなく、一箇所でアクセスルールを更新できます。すべての決定は OpenTelemetry スパンとして記録され、完全な監査証跡を提供します。

主な詳細

• 集中化された Gateway: エージェントは複数の MCP サーバーへの直接接続を管理する代わりに、単一の Gateway エンドポイントに接続するため、ネットワークトポロジーが簡素化されます。
• Cedar ポリシーエンジン: アクセス制御は、特定のツールをエージェントとスコープに紐付ける Cedar ポリシーを使用して定義され、デフォルト拒否の姿勢を強制します。
• トークン交換のオフロード: Gateway が Okta グラントをアクセストークンに引き換えるため、エージェントが認証情報の権限やシークレットを保持する必要がなくなります。
• マルチ環境サポート: このソリューションは、Bedrock AgentCore ランタイムと Amazon EKS の両方で稼働するエージェントをサポートし、一貫したアイデンティティ検証方法を使用します。
• 統一された可観測性: AgentCore Observability は、Gateway、Policy、Identity コンポーネントからのトレースを収集し、Amazon CloudWatch で Okta システムログと結合できます。
• 静的ツールスキーマ: ポリシー参照の安定性を確保するため、ターゲットは静的ツールスキーマを使用する必要があります。動的リストはポリシー適用を複雑にする可能性があります。

なぜ重要なのか

エンタープライズ AI アプリケーションを開発するソフトウェアチームにとって、セキュリティのスケーラビリティは大きなボトルネックです。数十のエージェントと数百のツールの権限管理は、各エージェントが独自の接続ロジックを維持する場合、すぐに管理不能になります。認可を集中化することで、組織は構成ドリフトのリスクを低減できます。セキュリティチームは一箇所でポリシーを監査・更新でき、変更がすべてのエージェントに一貫して適用されることを保証します。このモデルは、エージェントが機密性の高い認証情報を保存したり、トークン交換のための広範な権限を持ったりしなくなるため、攻撃面も最小限に抑えます。

可観測性ツールとの統合は、エージェントの挙動に関する重要な視覚化を提供します。規制産業では、誰がいつアクションを承認したかを証明することが不可欠です。CloudWatch で Okta グラントイベントと詳細な実行トレースを結合できることで、エンジニアは任意のエージェントアクションの完全なコンテキストを再構築できます。このレベルの透明性は、チームがカスタムのログ基盤を一から構築することなく、権限の問題をデバッグし、コンプライアンス要件を満たすのに役立ちます。

実施できること

• サンプルコードの確認: GitHub の AWS サンプル 08-okta-xaa-delegation-chain を調査し、Gateway コンポーネントを追加する前にベースラインアーキテクチャを理解してください。
• Gateway の実装: Okta 認可サーバーからの ID-JAG を検証するインバウンドオーソライザーを設定した AgentCore Gateway を構成してください。
• Cedar ポリシーの定義: デフォルト拒否の姿勢を確保するために、エージェントクライアント ID とスコープを特定のツールアクションにマッピングする許可専用ポリシーを作成してください。
• 可観測性の設定: CloudWatch Transaction Search を有効にし、Okta Log Streaming を EventBridge に設定して、統一された監査ビューを作成してください。
• マルチ環境エージェントのテスト: Bedrock ランタイム外からのアイデンティティを Gateway が正しく処理することを確認するために、Amazon EKS にセカンダリエージェントを展開してください。
• トークンスコープの検証: トークン交換の失敗を防ぐために、Gateway が要求するスコープが ID-JAG のスコープと一致していることを確認してください。