誰が承認したのか？マルチエージェントAIにおける委任問題

あなたのAIエージェントが会議を予約し、財務レポートを要約し、要点を3人の利害関係者にメールで送信しました。そのために、カレンダーエージェント、文書分析エージェント、メールエージェントを呼び出しました。各エージェントは内部システムにアクセスし、含める内容を決定し、あなたの代わりに行動しました。

あなたのセキュリティチームが答えられない質問は次のとおりです：誰がメールエージェントにその財務レポートを読むことを承認したのか？現在のほとんどのアーキテクチャでは、正直な答えは誰も明示的に承認していないということです。ログには、あるサービスが別のサービスを呼び出したことが示されているかもしれません。しかし、委任自体が承認されていたことを示すことはできません。承認は大きな失敗としてではなく、チェーンを通じて静かに漏れ出しました。

これがマルチエージェントAIにおける委任問題です。企業がMCPやA2Aなどのプロトコルを通じてエージェントを接続するにつれて、接続性の問題を権限の問題よりも速く解決しています。その結果、ほとんどのエンタープライズアーキテクチャがまだモデル化していない新しいセキュリティ境界が生まれています。なぜなら、ほとんどの組織は依然としてそれをオーケストレーションとして扱い、承認として扱っていないからです。

エージェントの接続は承認の適応よりも速い

過去2年間でエージェントエコシステムは急速に進歩しました。AnthropicのMCPは、モデル駆動型アプリケーションがツール、データソース、サービスに接続するための標準的な方法を提供しました。GoogleのA2Aプロトコルは、エージェントがシステム間で通信し調整するための標準的な方法を提供しました。LangChain、CrewAI、GoogleのADKなどのフレームワークとSDKは、1つのエージェントが他の複数のエージェントをオーケストレーションするマルチエージェントワークフローの構築を容易にしました。

これらのプロトコルがまだ提供していないもの（少なくとも成熟した共通レイヤーとして）は、委任を認識する承認モデルです。

MCPは、保護されたサーバーをOAuth 2.0リソースサーバーとして記述し、MCPクライアントはリソース所有者に代わってリクエストを行うOAuthクライアントとして機能します。これはなじみ深く理解しやすいパターンですが、人間が「許可」をクリックし、単一のクライアントがスコープ付きトークンを取得する世界向けに設計されています。エージェントAがそのトークンを受け取り、サブタスクをエージェントBに委任し、エージェントBがその一部を処理するためにエージェントCを生成するときに何が起こるかには対応していません。チェーンの各ホップは、元のトークンを再利用するか（過剰権限）、まったくトークンを持たない（追跡不能）かのいずれかです。

A2Aは相互運用性のために構築されました。独立した、潜在的に不透明なエージェントシステムがエンタープライズプラットフォーム間で通信しアクションを調整することです。それは正しい問題です。しかし、通信と委任のガバナンスは異なるレイヤーです。A2Aはエージェントが互いに発見、記述、通信するのを支援します。これは必要なインフラストラクチャですが、委任された権限と同じではありません。特定のダウンストリームアクションがアップストリーム命令から正当に派生したかどうかを示すものではありません。

静的なAPIキーはこの問題に対してさらに弱いです。キーはサービスへのアクセスを許可します。誰がそれを使用しているか、何に使用しているか、提示しているエンティティが発行されたものと同じかどうかについては何も述べていません。サービスアカウントはワークロードを識別しますが、意図は識別しません。3つのエージェントがサービスアカウントを共有する場合、すべてのアクションはログで同じように見えます。

これらのツールは壊れていません。それぞれ異なる問題を解決します。ギャップは構造的です。認証はどのエージェントが呼び出しているかを答えます。承認はそのエージェントが何にアクセスできるかを定義します。より難しい質問（ほとんどのエンタープライズアーキテクチャがまだ答えるように設計されていないもの）は、特定のダウンストリームアクションが、狭められた制約の下で、人間の決定にまでさかのぼる検証可能なチェーンを持ち、アップストリーム命令から正当に派生したかどうかです。それが委任の問題であり、今日のスタックにはまだないレイヤーにあります。

この状況のクリーンなバージョンでは、権限は外部世界に触れるエージェントだけが持つべきです。支払者（A）が簿記エージェント（B）に支払いを依頼し、簿記エージェントが銀行エージェント（C）に送金の実行を依頼する場合、銀行エージェントだけが銀行の権限を必要とします。簿記エージェントは資金を動かす必要はありません。リクエストが承認された支払者からのものであることを知るだけで十分です。銀行エージェントはリクエストが承認された簿記エージェントからのものであることを知るだけで十分です。これは最小権限の原則（セキュリティコミュニティが何十年も実践してきた概念）を委任チェーンに適用したものです。難しいのは、今日のエージェントスタックがそれを強制するのを難しくしていることです。

チェーンで何が壊れるか

規制対象銀行におけるトレジャリーレポートワークフローを考えてみましょう。計画エージェントは流動性予測を読み取り、上級財務ユーザー向けの日次サマリーを生成することを許可されています。タスクを完了するために、チャート生成を可視化エージェントに委任し、ナラティブレビューをコミュニケーションエージェントに委任します。可視化エージェントは生のアカウントレベルのデータにアクセスする必要はありません。コミュニケーションエージェントは基礎となる流動性モデルにアクセスする必要はありません。しかし、委任レイヤーが権限を減衰させない限り、両方ともタスクに必要なよりも多くのコンテキストを受け取る可能性があります。結果は劇的な侵害ではなく、アクセス制御モデルが明示的に承認しなかった静かなアクセス拡大です。

リスクはインターネットに面したエージェントに限定されません。多くの委任の失敗は完全に企業境界内で発生します。内部エージェントが別の内部エージェントを呼び出し、それが内部ツールを呼び出し、そのツールが承認されたSaaSサービスにデータを送信する場合があります。個々のステップはすべて許容できるように見えるかもしれません。リスクは構成に現れます：最終的なデータ移動またはアクションが元の承認の意図を超える可能性があります。

このパターンは、企業が規制当局、監査人、または顧客に説明しなければならない可能性のある3つのカテゴリーの障害を生み出します。

ゴースト権限。財務アナリストアシスタントが四半期報告をサポートするために顧客トランザクションデータベースへのアクセスを許可されています。それは要約エージェントを呼び出します：「これらのアカウントの最近のトランザクションを要約して」。要約エージェントは、ポリシーエンジンがそのアクセスを許可していないにもかかわらず、顧客レコードに対して動作するようになります。アナリストアシスタントの権限は事実上リクエストとともに移動しました。権限はゴーストです。実際には存在しますが、どの承認システムにも存在しません。

スコープドリフト。エージェントが狭い権限で開始しても、委任は範囲を狭めるのではなく広げる傾向があります。第1四半期の収益データを読むことを許可されたエージェントがチャート作成エージェントに委任し、それが外部レンダリングAPIを呼び出し、そのAPIが収益数値を持つようになります。データは3ホップの暗黙の信頼を通じて組織を離れました。各エージェントは自分が理解しているスコープ内で行動しました。集計結果は、人間が承認するであろうものを超えました。

壊れた監査証跡。規制対象業界では、重要なアクションについて「誰が何をなぜ行ったか」に答える能力が必要です。シングルエージェントシステムではこれは管理可能です。マルチエージェントチェーンでは、監査証跡はエージェント、プロトコル、サービス間で断片化します。コンプライアンスチームが特定の顧客コミュニケーションがなぜ送信されたかを尋ねると、答えには2つのプロトコルにわたる4つのエージェントが関与する可能性があり、そのどれも委任チェーンを記録していません。アクションはシステムにトレース可能ですが、決定にはトレース可能ではありません。

これらはエッジケースではありません。委任が明示的にモデル化されていない場合の一般的な結果です。委任問題は特定のフレームワークのバグではありません。それはそれらの間のレイヤーのギャップです。

委任認識モデルに必要なもの

委任認識承認モデルは4つのことを同時に解決する必要があります。これが既存のレイヤーがきれいにカバーできない理由の一部です。

最初はアイデンティティです。ダウンストリームエージェントは、受信システムが独立して検証できる暗号化資格情報を必要とします。ホスト名やAPIキーではありません。ホスト名は嘘をつく可能性があります。APIキーは移動します。本当のアイデンティティは、呼び出しシステムが偽造できないものです。

2番目は減衰です。エージェントがタスクを委任するとき、サブエージェントは親よりも厳密に少ない権限を受け取るべきであり、決して同じセットであってはならず、もちろんそれ以上であってはなりません。これは委任チェーンに適用された最小権限の原則であり、現在のツールのほとんどはデフォルトでこれを強制しません。

3番目は目的です。「CFOのために流動性エクスポージャーを要約するためにこのレポートを読む」は、「このレポートを読み、選択した数値を外部チャートサービスに送信する」とは異なる承認です。同じデータと同じエージェントかもしれませんが、リスクプロファイルはまったく異なります。目的のバインディングがなければ、承認レイヤーはそれらを区別する方法がありません。

4番目は監査です。組織は事後的に、誰が何をどの制約の下で委任し、各エージェントが完了時にどのような証拠を生成したかを再構築できるべきです。呼び出されたシステムだけでなく、どのような決定が誰の権限で行われたかもです。

エージェントは、説明責任のある権限を持たなくても認証に成功する可能性があります。自分が誰であるかを証明することはできても、人間が決して承認しなかったアクションを実行することができます。

新興のアプローチ

いくつかの取り組みがこの問題の一部に対処しています：ワークロードアイデンティティ標準、トークン内のエージェントメタデータ、OAuthベースのMCP承認、A2A認証パターン、エージェントアイデンティティフレームワーク。これらは有用なビルディングブロックですが、アイデンティティは委任された権限と同じではありません。署名されたエージェントカードは、エージェントの宣言されたアイデンティティと機能を確立するのに役立ちます。OAuthトークンはクライアントが何にアクセスできるかを伝えます。しかし、それ自体では、特定のダウンストリームアクションが特定のアップストリーム決定によって狭められた制約の下で承認されたことを証明しません。

1つの新興パターンは、委任バインド能力トークンです。短期間の資格情報で、呼び出しをエージェントアイデンティティ、制約された権限セット、および来歴記録にバインドします。1つの例はAgent Identity Protocol（AIP）で、私はインターネットドラフトおよびオープンソース実装として取り組んでいます。AIPはまだ初期段階ですが、可能な答えの形を示しています：呼び出しバインドトークンで、アイデンティティ、減衰された権限、および委任チェーンを通じた来歴を運びます。トークンチェーン自体が監査証拠の一部となり、断片化されたログから事後的に再構築されるものではありません。

補完的なアプローチも出現しています。行動資格情報（エージェントは初期権限だけでなくランタイム行動に基づいて継続的に再承認されるべきというアイデア）は、関連するが異なる問題に対処します。委任トークンは誰が何を承認したかを伝えます。行動監視はエージェントがまだ承認されたプロファイル内で行動しているかどうかを伝えます。完全なソリューションはおそらく両方を必要とするでしょう。

これらのアプローチはまだ主流の採用には至っていません。しかし、それらが同時に業界の異なる隅から出現しているという事実は、委任ギャップが現実であり認識されていることを示しています。

エンタープライズチームが今すぐ行うべきこと

標準が成熟するのを待ってから委任問題に対処する必要はありません。セキュリティ、プラットフォーム、およびアーキテクチャチームが今日実行できる具体的な手順があります。

委任チェーンをマッピングする。マルチエージェントワークフローを展開しているほとんどのチームは、どのエージェントがどの他のエージェントを、どの権限で、どのプロトコルを通じて呼び出しているかを文書化していません。そこから始めてください。グラフを描けなければ、保護することはできません。

暗黙の権限を監査する。エージェント間の各インタラクションについて、次の質問をしてください：このアクセスは明示的に許可されたものですか、それともダウンストリームエージェントが近接性によって権限を継承していますか？答えが継承であれば、ポリシー決定を必要とするゴースト権限があります。

スコープ減衰を要求する。アーキテクチャルールを確立します：エージェントがタスクを委任するとき、サブエージェントは親よりも少ない権限を受け取る必要があり、決して多くはありません。現在のツールはこれを自動的に強制しませんが、オーケストレーションレイヤーで強制できます。

監査人が尋ねる前に監査証跡を構築する。あなたの組織が規制対象業界にある場合、「誰がこのエージェントアクションを承認したのか？」という質問は最終的に尋ねられます。その質問が到着する前に委任ログを計装する時期であり、後ではありません。完全なチェーンをログに記録します：どのエージェントがタスクを開始したか、各ステップでの権限は何か、人間が最終的にどのように責任を負うか。