Agent-to-Agent Connectionsによるマルチエージェントワークフローのセキュリティ確保

マルチエージェントワークフローにおけるアイデンティティの盲点

今この瞬間も、企業内で、あるAIエージェントが自律的に別のエージェントを呼び出している可能性があります。営業エージェントが財務エージェントから顧客の支払い履歴を取得する。監視エージェントが診断エージェントをトリガーして、障害が発生したサービスを調査させる。かつては人間が何十回もやり取りを重ねていた業務が、今やわずか数秒で完了するのです。

しかし、ここに問題があります。こうした連携はすべて、本来ガバナンスの統制下に置くべきアクセスイベントなのです。それにもかかわらず、大半のセキュリティチームはその可視性をまったく確保できていません。その一方で、こうしたマルチエージェントワークフローを構築するAIチームは、エージェントの組み合わせごとに認可をカスタムコーディングし、部分的なソリューションをつなぎ合わせています。そのため、何が起きているのかを一元的に把握・制御できる場所がどこにもないのが現状です。

人間主導、マシン主導、あるいは急速に一般化しつつあるエージェント自身による主導を問わず、マルチエージェントアーキテクチャは、すでに本番環境で稼働しています。しかし、その根底にあるべき「アイデンティティレイヤー」が欠落しているのです。エージェント間のやり取り専用に設計されたアイデンティティレイヤーがなければ、これらの接続は完全な盲点となり、ガバナンスが及ばず、実行主体の特定もできず、監査も不可能な状態に陥ってしまいます。

新機能：エージェント間のセキュアな接続

マルチエージェントのワークフローを保護し、ガバナンスを確保するために、Okta for AI Agentsは、自律型AIエージェントの検出、認可、ガバナンスのための戦略的フレームワークである、Oktaの「セキュアなエージェンティック企業のための設計指針」を活用しています。この設計指針の第2の柱が投げかけるのは、「エージェントは何に接続できるか」という問いです。エージェントとリソース間の接続のセキュリティを確保することに焦点を当て、エージェントが必要とする企業データやシステムに対して、スコープが限定され、かつ監査証跡が残るアクセス権を付与します。

今回、このセキュアな接続モデルをさらに拡張し、マルチエージェントワークフローにも対応できるようにしました。現在、人間やアプリケーションのセキュリティを担保している基本構成要素（エージェントのアイデンティティ、スコープが限定された資格情報、監査の帰属など）が、エージェント間の接続にも拡張されます。

その中核となるのが、Okta for AI Agentsの新機能である「Agent-to-Agent Connections」です。これにより、以下の定義が可能になります。

• エージェントごとの接続ポリシー
• エージェントに対して、どのアップストリームサービスやエージェントからの呼び出しを許可するか
• エージェントのスコープ（アクセス可能なリソース）
• セッション期間（アクセスの有効期限）

すべてのやり取りでアイデンティティが引き継がれるため、ワークフロー全体を通じてあらゆる接続の検証可能性が維持されます。

セキュリティチームにとっては、エージェント間のすべての呼び出しがガバナンスの統制下に置かれ、スコープが制限され、完全に監査可能になることを意味します。開発者にとっては、エージェントごとに認可をコーディングすることなく、マルチエージェントのワークフローを構築できることを意味します。Oktaで認可ポリシーとアクセスポリシーを一度定義するだけで、委任チェーン内のすべてのエージェントが、定義されたポリシーに従って自動的に動作します。

Agent-to-Agent Connectionsの仕組み

あるエージェントが別のエージェントを呼び出すたびに、Oktaは接続が認可されているかを検証し、タスクに必要なデータのみにアクセスを限定したうえで、誰が誰の代理で行動したかを記録します。これにより、マルチエージェントワークフロー全体にガバナンスが適用されます。

マルチエージェントフローのステップ解説

この仕組みを理解するために、マルチエージェントワークフローにおける1つのリクエストの流れを追ってみましょう。2つのエージェントが連携して処理する、定型的なレポート作成タスクを例に挙げます。

• ユーザーアシスタントエージェント：従業員に代わって動作する
• データアナリストエージェント：機密データベースからデータを取得する

フローは次のとおりです。

1. ユーザーがユーザーアシスタントエージェントに「第4四半期レポートを作成して」と依頼します。
2. ユーザーアシスタントエージェントはデータが必要なため、「[ユーザー]の代理」としてデータアナリストエージェントを呼び出します。
3. Oktaがポリシーをチェックし、「ユーザーアシスタントエージェントに、データアナリストエージェントを呼び出す権限があるか」また「データアナリストエージェントは、このデータをユーザーと共有できるか」を確認します。
4. 確認できた場合、Oktaは「データアナリストエージェントへ：このリクエストは[ユーザーアシスタントエージェント]経由で[ユーザー]から送信されたものです。X、Y、Zのデータを共有してください」という内容の一時的なトークンを発行します。
5. データアナリストエージェントはトークンを検証し、許可された情報のみを共有して、リクエストをログに記録します。
6. ユーザーアシスタントエージェントは、そのデータを使用してレポートを作成し、ユーザーに返します。
7. すべて監査可能です。ログには、「ユーザー → ユーザーアシスタントエージェント → データアナリストエージェント」と正確に記録されます。

これを可能にするのが、次の3つの原則です。

•  明示的な許可リスト：どのエージェントが他のどのエージェントを呼び出せるかを定義します。
•  スコープが限定された権限：各ダウンストリーム（呼び出される側）のエージェントに対し、タスクの実行に必要な権限のみを付与します。
•  検証可能な委任チェーン：すべてのトークンにこの情報が付随するため、誰が何を認可したかを監査ログで把握できます。

結果：セキュリティチームは、すべてのエージェントのアクションを完全に可視化できます。開発者はエージェント間の認可コードを個別に実装する手間から解放され、マルチエージェントワークフローをより迅速にリリースできるようになります。

マルチエージェントの委任チェーンの信頼性が維持される理由

委任チェーンの信頼性を維持する要素は2つあります。

1. すべてのエージェントが、クライアントとリソースの両方として動作できること。
2. すべてのトークンに、誰が何を認可したかの完全かつ検証可能な記録が保持されること。認可は実行時に行われ、その際のアクションはすべて監査ログに保存されます。

クライアントとリソースの両面を併せ持つエージェント

Okta環境下では、すべてのエージェントがクライアントであり、同時にリソースでもあります。これが重要である理由は、実際のマルチエージェントワークフローでは、エージェントは呼び出しの端点にただ存在するのではなく、その中間に位置するためです。すべてのエージェントが、他のエージェントやサービスへのリクエストを開始することも、それらからリクエストを受信することもできます。この二面性こそが、オーケストレーションを可能にしているのです。

• クライアントとして：他のエージェントやサービスを呼び出すことができる
• リソースとして：他のエージェントから呼び出されることができる（ポリシーで許可されている場合）

単一のエージェントが、信頼のチェーンを断ち切ることなく、専門的なタスクとオーケストレーションの両方を実行できます。

トークンベースの委任レコードによるコンテキストの維持

Oktaがエージェント間の呼び出しに対してトークンを発行する際、そこには経路全体の記録が含まれます。

• 「これはユーザーAのためのリクエストです」
• 「ユーザーAがアシスタントエージェントに委任しました」
• 「アシスタントエージェントはデータアナリストエージェントに委任しました」
• 「データアナリストエージェントにはX、Y、Zの実行が許可されています」

Oktaはトークンに完全な委任チェーンを含めるため、リクエスト受け取る側のエージェントはアクションを実行する前に認可を検証できます。Oktaの監査ログは、すべての呼び出しの委任チェーンをキャプチャし、トークン自体の有効期限が切れた後も長期にわたってその記録を保持します。

万が一、セキュリティインシデント、監査に関する問い合わせ、コンプライアンスレビューなどの問題が発生した場合でも、監査記録を呼び出すだけで、何が起きたか、誰がそれを認可したか、ポリシーに準拠していたかを正確に把握できます。手作業でログを掘り起こしたり、相関分析を行ったりする手間は一切不要です。

人間主導型とマシン主導型のフローパターンの分析

ワークフローの起点が人間かマシンかを問わず、単一のアイデンティティがチェーン全体の起点となります。すべてのダウンストリームエージェントはその権限下で動作し、すべてのステップがその権限に紐付けされます。Agent-to-Agent Connectionsは、現在この両方のパターンに対応しています。

パターン1：人間がチェーンを開始する場合

ユーザーがログインし、エージェントにアクションの実行を依頼します。そのエージェントはタスクを完了するために他のエージェントを呼び出すことがありますが、あくまで人間のアイデンティティが起点となります。

例：従業員が「第4四半期の指標のサマリーを教えて」と依頼する

1. サマリーエージェントが（従業員の代理として）ダッシュボードエージェントを呼び出す
2. ダッシュボードエージェントが（従業員の代理として）データベースエージェントを呼び出す

従業員のアイデンティティがチェーン全体に途切れることなく引き継がれるため、すべてのステップがその従業員の名義でログに記録されます。

Oktaが監査ログに記録する内容：「従業員がサマリーエージェントによるダッシュボードエージェントの呼び出しを認可しました。ダッシュボードエージェントは、従業員のアクセススコープ内でデータベースエージェントから指標を取得しました」

パターン2：サービスがチェーンを開始する場合

企業では長年にわたり、サービスアプリケーション、ETLパイプライン、定時実行ジョブ、マイクロサービスなどが、あらかじめ定義された確定的なワークロードを実行してきました。現在、こうしたシステムにもAIが組み込まれつつあります。

例：監視サービスがCPU使用率の急上昇を検知する

1. 監視サービスが診断エージェントを呼び出す
2. 診断エージェントがログ分析エージェントを呼び出す

このリクエストの起点となったユーザーは存在しません。監視サービスがクライアント、診断エージェントがそのリソースとなり、そのサービスの権限がチェーン全体に途切れることなく引き継がれます。

Oktaが監査ログに記録する内容：「監視サービスが、診断エージェントによるログ分析エージェントの呼び出しを認可しました。ログ分析エージェントは、監視サービスのために本番環境のログを分析できます」

2つのパターンの主な違い

結果：委任チェーンの起点にかかわらず、単一のガバナンスモデルが適用されます。セキュリティチームは、すべてのやり取りが記録されることで、人間主導かマシン主導かを問わず、ワークフロー全体の完全なトレーサビリティを確保できるようになります。AIチームは、起点にあるのがユーザーかサービスかにかかわらず、同じように機能する認可を取得できます。そのため、パターンごとに個別のロジックを構築、維持する必要がありません。

パターン3：自律型エージェントがチェーンを開始する場合（近日リリース予定）

まもなく3つ目のパターンとして、自己の代理が登場します。これは、自律型エージェントが他のエンティティからの委任を一切受けることなく、管理者が事前承認したポリシーに基づき、完全に独自の権限で動作するモデルです。このパターンを活用することで、あらかじめ定義されたポリシーの範囲内で、完全に監査・統制された状態で自律型エージェントを運用できるようになります。

マルチエージェントワークフローを一元的なガバナンスの統制下に置く

すでに社内環境ではエージェント同士の呼び出しが行われていますが、そこにガバナンスは一切及んでいません。重要なのは、エージェント同士が呼び出し合うかどうかではなく、それが起きたときに「何が行われたか」を確実に説明できるかどうかです。

それを可能にするのが、Okta for AI Agentsです。従業員、アプリ、エージェントのセキュリティを担保するのと同じアイデンティティの基本構成要素をエージェント間の接続にも拡張することで、マルチエージェントワークフローを可視化し、ガバナンスの統制下に置くことができます。Agent-to-Agent Connectionsが提供する許可リスト、スコープ限定の権限、そして検証可能なチェーンにより、自律型ワークフローを安全にスケールさせることが可能になります。

マルチエージェントアーキテクチャが複雑化するなか、これから勝ち残る企業は単に開発スピードが速いだけではありません。「誰が、誰の代わりに、どのポリシーに基づいて何を実行したか」を、いつでも明確に証明できる企業です。

マルチエージェントワークフローのガバナンスを整える準備はできましたか？

Oktaをご利用のお客様向けに、Agent-to-Agent Connectionsの早期アクセス版の提供を開始しました。プログラムへのご登録については、Oktaの担当アカウントチームまでお気軽にお問い合わせください。

また、これらのAIエージェント制御機能がどのように動作するのか、実際にご覧いただくこともできます。Oktaのストリームキャストでは、アイデンティティを制御ポイントとしたエージェントガバナンスのあり方を詳しく解説しています。ぜひご参加ください。

本資料は、一般的な情報提供のみを目的としており、法律、プライバシー、セキュリティ、コンプライアンス、またはビジネスに関する助言を意図したものではありません。セキュリティ、プライバシー、コンプライアンス、またはビジネスに関するアドバイスについては、お客様ご自身の専門アドバイザーにご相談ください。本ブログで言及されている将来の製品、機能、仕様、認定に関する記述は、情報提供のみを目的としています。これらは提供を確約するものではなく、購買の意思決定を行う際に依拠すべきものではありません。© Okta, Inc. and its affiliates.2026