エージェント型エンタープライズ向け Trusted Agent Identity

企業がエージェント型パラダイムを採用すると、 **エンドユーザー ID が自律型 AI エージェントのネットワークをどのように通過するか? という新しいセキュリティ上の課題が生じます。**従来の API アーキテクチャでは、ユーザーは一度認証すると、アプリケーションがユーザーの代わりにバックエンドサービスをコールします。IDチェーンは短く、よく理解されており、通常は1つのTrustドメイン内で管理されます。ただし、エージェント型アーキテクチャでは、1つの要求がさまざまなエージェント、サービス、および Model Context Protocol（MCP；モデルコンテキストプロトコル）サーバーに分散し、それぞれがサービス境界、Trustドメイン、さらには組織の境界を超える可能性がある、より長いチェーンを備えています。ID伝達のための慎重な戦略がなければ、企業はセキュリティと機能性のどちらかを選ばざるを得ないという、アーキテクトが直面すべきではないジレンマに陥ります。

MuleSoftは、信頼済みエージェントID機能を使用してIDの伝達の複雑さに対処します。このソリューションは、ポリシーベースのゲートウェイ管理戦略を使用して、エージェント間 (A2A) プロトコル、MCP ツールコール、REST API 要求など、さまざまなインタラクション種別でエンドユーザー ID が維持されるようにします。送信認証ポリシーを使用して Flex Gateway レイヤーで ID 管理を一元化することで、企業はバックエンドサービスやエージェントを変更することなくエージェントネットワーク全体を保護できます。

このドキュメントでは、ID 伝搬の課題について、段階的に進める一連のシナリオを使用して説明します。各シナリオでは、さらに複雑さが増します。これらのシナリオを合わせて、信頼済みエージェント ID がエンタープライズ規模のエージェントリリースの基本的な要件である理由を説明します。

従来のアプリケーションでは、ID フロー (OAuth JWT フロー) は簡単です。ユーザーがログインしてトークンを受信し、アプリケーションがそのトークンを使用してバックエンドリソースにアクセスします。トークンはユーザーの ID (ユーザー本人やユーザーが許可されている内容など) と共に埋め込まれ、すべての要求で送信されます。コールチェーンは短く、通常は 1 ～ 2 ホップで、ID 伝播は解決されます。

ただし、エージェント型アーキテクチャでは、1 つのユーザー要求がさまざまなエージェント、バックエンドサービス、およびモデルコンテキストプロトコル (MCP) サーバーに分散される可能性がある、より長いコールチェーンが使用されます。各要求の宛先は個別のホップで構成されます。これらの課題(マルチホップID伝播、混合認証モデル、クロスドメインTrust境界など)はどの分散API設定にも共通していますが、異なる_のは_、現在のエコシステムのデフォルトの対応です。現在、エージェント間およびエージェントと API 間の通信では、クライアントログイン情報、API キー、または共有秘密を使用するのが主流です。つまり、次のようになります。

**デフォルトでは、ユーザー ID は失われます。**エージェントがクライアントログイン情報を使用して MCP サーバーまたはダウンストリーム API をコールする場合、要求はエンドユーザーのサービス ID ではなくエージェントのサービス ID を伝達します。下流サービスでは、アクションを開始した_ユーザー_を特定する方法がないため、ユーザーごとの承認と監査証跡が使用できなくなります。
**混在認証のニーズは無視されます。**すべてのダウンストリームサービスでユーザーコンテキストが必要なわけではありません。トランザクションやポートフォリオなどのユーザー固有の情報を管理するサービスもあれば、参照資料や市場トレンドなどの公開データやシステムレベルのデータを提供するサービスもあります。現在の標準はクライアントのログイン情報のみに基づいているため、これらのニーズを区別したり、必要な場合にのみユーザー ID を選択的に伝達したりすることはできません。
**クロスドメインの信頼境界は未対応です。**B2B および規制シナリオのエージェントは、完全に別個の ID プロバイダー (IdP) が管理するシステムを操作しなければならない場合があります。たとえば、外部の銀行システムは企業のシングルサインオン (SSO) トークンを解釈できませんが、本ユーザの同意とインテントは受け取る必要があります。クライアント認証情報フローには、これに対応する仕組みがありません。

その結果、ユーザーに紐づく最小権限アクセスという企業の要件と、ユーザーコンテキストのないサービスレベル認証に依存する現在のエコシステムとの間にギャップが生じます。このギャップを埋めるには、アイデンティティ伝播への意図的かつ階層的なアプローチが必要です。これらの概念を説明するために、次のシナリオでは架空のフィンテックアプリケーションであるFinportを使用して、これらのアーキテクチャパターンの実用的な例を紹介します。

Finport は、エージェントアーキテクチャに裏打ちされた架空の消費者向け Fintech ポートフォリオ管理 Web アプリケーションです。エージェントブローカー (MuleSoft エージェントブローカーを使用して作成) は、複数のダウンストリームエージェントと MCP サーバを調整してユーザーの要求に対応します。

Finport では、3 つのコア機能が公開されており、それぞれに個別の ID 要件があります。

“Show me my portfolio.” 本ユーザは、自身の保有資産と取引履歴を要求します。このデータは本ユーザ固有であるため、下流のポートフォリオサービスエージェントとポートフォリオ MCP Server は、_どの_ユーザのデータを返すべきかを把握し、該当ユーザがそのデータにアクセスする権限を持っているかを確認する必要があります。ユーザー ID はすべてのホップで伝播する必要があります。
“What are the current market trends?” (現在の市場トレンド): ユーザーは公開市場データと資産価格を要求します。“データは公開され、ユーザーによって変動しないため、下流のマーケットデータエージェントおよびアセットマーケット MCP Serverでは、ユーザースコープのトークンは必要なく、また期待されません。ブローカー自身のサービス資格情報で十分です。
“Transfer $5,000 to my external savings account.” (5,000 ドルを外部普通預金口座に振り込む): ユーザーは、別の IdP (Okta ではなく Auth0 など) を使用する銀行への資金移動を開始します。“ユーザーの Finport トークンは、銀行のシステムにとって無意味です。転送を続行するには、ユーザーが銀行に対して直接 (会話内でインライン) 認証する必要があります。

これらの各機能は、異なる ID 伝達パターンに対応付けられます。次のシナリオは、標準ベースライン (エージェントなし) から個別のパターンで段階的に構築され、エージェントやバックエンドサービスを変更することなく Flex Gateway の送信ポリシーで各要件に対処する方法を示しています。

エージェントを導入する前に、ベースライン (ユーザーがクライアントアプリケーションで認証し、バックエンドサービスにアクセスする) を確立することが重要です。

フロー:

ユーザーが Finport を開くと、IdP のログインページ (Okta など) にリダイレクトされます。
ユーザーが認証する (ユーザー名、パスワード、SSO、多要素認証 (MFA)、その他の要件)。
IdP が署名済み JWT アクセストークンを Finport アプリケーションに発行します。
Finport にユーザーの ID を表すユーザートークンが追加されました。ユーザートークンとは、ユーザー ID、付与された範囲、トークンの有効期限です。このトークンは、そのユーザーに代わって任意の下流サービスに提示されます。

設定内容: このプロセスは、標準の OAuth 2.0 アーキテクチャパターンに従います。信頼済み IdP によって検証される初期ユーザートークンは、その後のすべての操作に不可欠な基盤として機能します。以降のすべてのシナリオはこのトークンに基づいて構築されます。

質問: 認証されると、ユーザーは資金移動、市場分析、ポートフォリオレビューなどのアクションを開始します。これらのリクエストはエージェントブローカーを介して処理され、複数の下流エージェントまたは MCP サーバーが関与する可能性があります。ここで重要な疑問が生じます。これらの分散要求でユーザーの ID はどのように維持されるのでしょうか?ダウンストリームサービスでまったく異なる IdP を使用するとどうなるでしょうか。

ユーザーが Finport エージェントに_「Show me my portfolio._」 (ポートフォリオの表示) を要求このインタラクションにより、MuleSoft Agent Broker を使用して構築された Finport Agent Broker からバックエンドチェーンがトリガーされます。ブローカーはこのタスクを ポートフォリオサービスエージェント に渡し、そのサービスエージェントが ポートフォリオ MCP Server を照会します。ユーザーの最初の認証トークンは、要求されたポートフォリオレコードにアクセスするために複数のホップを経由するようになりました。

元のトークンを渡すと最小権限の原則に違反しますが、サービスアカウントを使用するとユーザーの ID が失われます。

Finport Agentはユーザーのトークンを受信しますが、その同じトークンをポートフォリオ・サービスエージェントに転送することはできません。最小権限の原則に違反し、ダウンストリーム・サービスの要求の範囲を適切に設定できないためです。逆に、サービスアカウントを使用すると、ユーザー ID が完全に失われます。ポートフォリオサービスエージェントとポートフォリオMCPサーバ_は、どの_ユーザーのポートフォリオを返すべきかを把握できず、監査履歴ではすべてのアクションがエンドユーザーではなくブローカーのサービスIDに帰因します。

Flex Gateway は、送信 OAuth 2.0 トークン交換ポリシーを使用して、これらの ID 伝達の複雑さを透過的に解決します。このソリューションは、コールチェーンの各ホップで送信要求を代行受信し、受信ユーザートークンを IdP と交換して、ダウンストリームサービス専用の新しいログイン情報を取得します。On-Behalf-Of (OBO) ポリシーでは、OAuth 2.0 Token Exchange (RFC 8693) プロトコルと Microsoft Entra ID On-Behalf-Of プロトコルの両方がサポートされます。

主なアーキテクチャ上の利点: このプロセス全体が Flex Gateway 送信ポリシーによって処理されます。ブローカーとエージェントには_ゼロの_認証ロジックが含まれます。代わりに、ゲートウェイレイヤーで ID の伝達が適用される間、ビジネスロジックのみに集中します。

フロー:

ユーザーは Okta で認証され、Finport アプリケーションは Flex Gateway を介して要求を送信します。
ブローカーは検証済みユーザートークンを受信し、ポートフォリオサービスエージェントが必要かどうかを判断します。
Flex Gateway の送信 OBO ポリシーは、ユーザートークンを IdP と交換して、ポートフォリオサービスエージェントにスコープが設定されたトークンと交換します。
ポートフォリオサービスエージェントは適切なスコープのトークンを受信し、ポートフォリオ MCP Server を呼び出します。
Flex Gateway はトークンを再度交換します。今回はポートフォリオ MCP Server にスコープされたトークンです。
Portfolio MCP Server は、ユーザーの特定のポートフォリオデータを返します。
完全な監査履歴が存在します。すべてのホップは元のエンドユーザーに起因します。

なぜ重要か: OBO トークンの交換を使用しない場合、企業は、最小限の権限に違反する元のトークンを転送するか、ユーザー ID を失うリスクがあるサービスアカウントを使用するかを選択する必要があります。OBO パターンでは、すべてのホップでユーザーの ID が保持され、各トークンが対象範囲に設定され、エージェント自身が ID の仕組みを完全に認識していないため、このトレードオフが解消されます。

すべてのダウンストリームサービスでユーザーコンテキストが必要なわけではありません。ユーザーは Finport エージェントに_「What are the current market trends? (_現在の市場トレンドは?)」と尋ねます。シナリオ 1 のポートフォリオ要求とは異なり、市場トレンドデータはユーザーによって変化しない場合に公開されます。ダウンストリームの Market Data Agent および Asset Market MCP Server では、ユーザー範囲のトークンは必要なく、予期されることもありません。

ユーザートークンが必要のない場所に伝搬すると、攻撃対象領域が広がります。

Finport Agent Brokerがシナリオ1のOBOパターンを使用してユーザーのトークンをMarket Data Agentに伝播する場合、成功しますが、不要になります。不要なユーザートークンを伝達すると、攻撃対象領域が拡大し、トークン交換の IdP に不要な連動関係が作成され、最小権限の原則に違反します。Market Data Agent は、要求が、どの_ユーザー_からではなく、承認されたサービスから行われていることを把握する必要があります。

Flex Gateway の Outbound OAuth 2.0 Client Credentials ポリシーがこれを透過的に処理します。ユーザーのトークンを交換する代わりに、ポリシーはクライアントログイン情報付与を介してブローカー自身のサービスログイン情報を送信要求に挿入します。ダウンストリームのマーケットデータエージェントは、適切に認証されたサービスレベルトークンを受信します。なお、ユーザーIDは必要ないため伝播されません。

主なアーキテクチャ上のメリット:ID伝達戦略は汎用的ではなく、データの性質と対象サービスの要件に基づいてダウンストリームルートごとに決定されます。Flex Gateway の送信ポリシーでは、ルートごとにこれを設定できます。同じ Finport Agent Broker がコードを変更することなく OBO フロー (シナリオ 1) と S2S フローの両方に参加できます。出力ゲートウェイのポリシー設定によって、どのパターンがどのダウンストリームコールに適用されるかが決まります。

フロー:

ユーザーは Finport エージェントに_「What are the current market trends? (_現在の市場トレンドは?)」と尋ねます。
ブローカーは、要求を履行するためにマーケットデータエージェントが必要であると判断します。
Flex Gateway の送信クライアントログイン情報ポリシーは、ブローカー自身のログイン情報を使用してサービスレベルトークンを取得します (ユーザートークンが交換または伝達されることはありません)。
マーケットデータエージェントは、適切に認証されたサービスリクエストを受信し、アセットマーケット MCP サーバーを呼び出します。
アセットマーケット MCP サーバーは公開マーケットデータを返します。
この種別のデータにユーザー ID は不要であるため、チェーンには意図的にユーザー ID が存在しません。

重要な理由:Flex Gatewayのポリシーベースのフレームワークにより、アーキテクトはすべてのインタラクションに最適なIDモデルを選択でき、オーバーヘッドとセキュリティリスクを高めるユニバーサルユーザートークンの伝達と、ユーザーコンテキストとコンプライアンスを犠牲にするグローバルサービスアカウントの使用量という難しい選択を解決できます。

最も複雑な ID シナリオは、エージェントが既存のユーザートークンを認識しないまったく別の IdP によって管理されるシステムを操作する必要がある場合に発生します。

シナリオ: Finport ユーザーが、Finport Agent に_「Transfer $5,000 to my external savings account.」(5,000 ドルを外部普通預金口座に振り込む) と要求します。_この要求には、2 つの異なるダウンストリームパスが含まれます。

ポートフォリオサービスエージェント（OBO）パスでユーザーの保有資産を検証
トランザクションエージェント → トランザクション MCP サーバ → ユーザーの銀行パスで実際の送金を実行します。

トランザクションエージェントは、独自の IdP を使用するユーザーの銀行とやりとりする必要があります。Finport からのユーザーの Okta トークンは、銀行が Finport の IdP との Trust 関係を持たないため、銀行のシステムにとって無意味です。OBO パターン(シナリオ 1)と S2S パターン(シナリオ 2)のどちらもこれを解決できません。OBO は同じ IdP 内でトークンを交換し、S2S はユーザーのIDを一切伝播しないサービスの認証情報を使用します。銀行は、ユーザーが MFA を含む自身の銀行ログイン情報で直接認証することを要求しています。

Flex Gateway の Outbound A2A In-Task Authorization Code ポリシーでは、エージェントの会話内でチャレンジ/レスポンスメカニズムが使用されます。銀行に連絡する際にセカンダリトークンがない場合、ポリシーは認証が必須のチャレンジを返します。このチャレンジには、クライアントが銀行のプロバイダーと OAuth 2.0 フローを開始するために必要なすべての詳細 (エンドポイント、範囲、PKCE パラメーターなど) が含まれます。

次に、Finport アプリケーションでは、直接ユーザー認証を行うために銀行のログインがインラインで表示されます。完了すると、クライアントは A2A 要求でトークンを返します。ポリシーは、銀行のシステムのこのトークンを抽出し、セキュリティを確保するためにメッセージ本文からトークンを抽出します。

主なアーキテクチャ上のメリット:ゲートウェイポリシーレイヤーによってクロスドメイン認証プロセス全体がオーケストレーションされるため、ブローカーやエージェントが未加工の認証情報を操作したり、銀行のIdPに関するKnowledgeを要求したりすることはありません。このチャレンジ・レスポンス・フレームワークを使用することで、ユーザーは外部システムで認証するための明示的な同意を提供し、生成されたトークンはポリシー・レイヤーを介して安全に転送されます。

フロー:

ユーザーが転送を開始するように Finport アプリに依頼します。リクエストはブローカーを介して流れます。
ブローカーは、ポートフォリオ (OBO) を使用して保有状況を確認し、トランザクション (In-Task) を使用して送金を実行します。
トランザクションパスは、Flex Gateway の In-Task ポリシーから認証必須のチャレンジをトリガーします。
チャレンジは Finport アプリケーションに伝播され、そこで銀行のログインフローがインラインでユーザーに提示されます。
ユーザーは、必要に応じて MFA を含め、銀行で認証します。
銀行トークンは後続の A2A 要求に含まれます。ポリシーによって抽出され、Authorization ヘッダーに設定されて、リクエストが転送されます。
Transaction MCP Server は銀行のトークンを使用してリクエストを受信し、転送を実行します。

理由: クロスドメインアイデンティティは、エージェントアーキテクチャの主要な課題です。タスク内認証を使用しない場合、企業はネットワーク内のすべての IdPin 間に複雑な Trust リレーションを事前に確立するか、銀行ログイン情報をエージェントに提供するようユーザーに要求する必要があります。In-Task パターンでは、外部プロバイダーとの直接ユーザー認証を許可することでこれを解決します。ポリシーでは、エージェントが外部 ID ドメインから切り離されたまま、トークンの仕組みを管理します。

3 つのすべてのシナリオで、1 つのアーキテクチャの原則が適用されます。つまり、ID 伝播はエージェントやサービス内ではなくゲートウェイ層で適用されます。エージェントと MCP サーバーには認証ロジックが 0 個含まれています。ロールは認証済み要求を処理して結果を返すことに制限され、Flex Gateway 送信ポリシーレイヤーは ID 関連のすべての操作を管理します。

これは、Flex Gateway の送信認証ポリシーが適切な時点 (エージェントがルーティングを決定した後、要求がダウンストリームサービスに到達する前) でトラフィックを代行受信するためです。ポリシーは、トークンを変換し（OBO エクスチェンジ、クライアント資格情報注入、または In-Task チャレンジ・レスポンス）、適切に認証された要求を転送します。下流サービスでは違いが認識されないため、エージェントはそのことを気にする必要がありません。認証ロジックは、サービスに分散されるのではなく、ゲートウェイで集中管理されます。バックエンドサービスではコードを変更する必要がなく、同じポリシー設定を複数のルートで再利用できます。

このアプローチはプロトコルに依存しません。ポリシーは HTTP レイヤーで動作するため、エージェントが REST、MCP、A2A、または Web フックを使用して通信する場合でも一貫して適用されます。「エージェントファブリックの詳細」に記載されているように、すべてのA2AおよびMCPトラフィックはFlex Gatewayを介してルーティングされ、すべてのエンドポイントにポリシーが適用されます。つまり、IDの伝達は、通信プロトコルに関係なく一様に適用されます。

次の 3 つの構成可能なパターンで、エージェントアーキテクチャの ID 要件の全範囲をカバーします。

パターン	ポリシー	ユーザー ID	ユーザーの操作	使用事例
代理 (OBO)	OAuth 2.0 OBO 資格情報注入ポリシー	保存	なし (透明)	同じTrustドメイン内のユーザー固有のデータ
サーバ間 (S2S)	送信 OAuth 2.0 クライアントログイン情報	Not propagated (伝播なし)	なし	公開データ、システムレベルの操作
In-Task 認証コード	アウトバウンド A2A の In-Task 認証コード	主 + 副	必須 (インライン認証	クロスドメイン、マルチ ID プロバイダー、高リスクの運用

これらのパターンは相互に排他的ではありません。Finportシナリオが示すように、1つのエージェントブローカーが1つのダウンストリームコールにOBO、別のコールにS2S、そして3つ目のコールにIn-Taskを使用できます。各アウトバウンドルートのポリシー設定によって、適用されるパターンが決まります。エージェントコードの変更やサービスの変更はなく、ポリシーのみが変更されます。

上記のゲートウェイ適用パターンでは個々のインタラクションが保護されますが、ID の伝達は孤立した懸念事項ではありません。これは、より広範な MuleSoft® エージェントファブリックガバナンスモデルの基礎レイヤーです。「エージェントファブリックの詳細」で説明されているように、エージェントファブリックは検出、オーケストレーション、ガバナンス、監視の4つの柱に基づいて構築されており、それぞれが効果的に機能するには信頼性の高いIDチェーンに依存します。

検出: エージェントレジストリでは、エージェントとその機能がカタログ化されます。認証要件を含むエージェントメタデータにより、ブローカーは各エージェントが期待するアイデンティティパターンを把握できます。
Orchestrate: エージェントブローカーがマルチエージェントワークフローを調整します。Flex Gateway は各ホップで ID 変換を透過的に処理するため、ブローカーはタスクの分解とルーティングに注力できます。
管理: すべてのA2AおよびMCPトラフィックは、ターゲットシステムが安全でない場合でもFlex Gatewayを介してルーティングされ、すべてのエンドポイントにポリシーが適用されます。送信認証ポリシーはガバナンスレイヤーの一部です。
Observe: エージェントビジュアライザーは、エージェント間のインタラクションを動的かつインタラクティブなマップでリアルタイムに監視する機能を提供します。すべてのホップでユーザー ID が保持されるため、トレースとログによってエージェントネットワーク全体でユーザー属性の監査履歴が提供されます。

信頼済み ID の伝達がないと、ガバナンスが不完全になります。エージェントのカタログ化とオーケストレーションはできますが、ユーザーの承認の範囲内でエージェントが行動することを保証することはできません。Trusted Agent Identity は、このギャップを埋め、セキュリティとユーザーコンテキストがエージェントのワークフローの中心であり続けるようにします。

これらのパターンを実装するには:

送信ポリシーディレクトリを理解する.Flex Gateway で使用可能な送信認証ポリシーの完全なセットを確認します。
OBO から開始.OAuth 2.0 トークン交換ポリシーは、最も一般的な ID 伝搬ニーズであるエージェントホップ間でのユーザーコンテキストの保持に対応します。
Add In-Task for Cross-Domain Scenarios：エージェントネットワークが Trust Boundary を超える場合、A2A In-Task Authorization Code ポリシーによって、ユーザからセカンダリクレデンシャルを取得するためのチャレンジ/レスポンスメカニズムが提供されます。
エージェントファブリックを活用.ルートごとの ID モデルを指定するポリシー設定を使用して、エージェントネットワーク YAML でエージェントネットワークを定義します。残りはプラットフォームが処理します。

実装ガイダンスの詳細については、コンパニオン実装ガイドを参照してください。

Nikhil Aggarwal は Salesforce の著名なエンジニアで、MuleSoft および Salesforce Automation Cloud のアーキテクチャを指導しています。Nikhil は、大規模な製品の提供に 18 年以上の経験を持ち、拡張性の高いアーキテクチャ、直感的な開発者エクスペリエンス、ハイパフォーマンスなチームの構築に情熱を注いでいます。Salesforce 以前は、Microsoft Power Platform、Dataverse、Office 365 で構想から立ち上げまで複数のイニシアチブを率いていました。彼の仕事は、AIファースト時代において、現代の企業がシステムを接続し、ワークフローを自動化し、ビジネス価値を引き出す方法を形成し続けています。

Akash Trivedi は Salesforce のエンジニアリング担当ディレクターで、拡張性と安全性を備えたハイパフォーマンスなエンタープライズシステムの構築に 18 年以上携わっています。AI、エンタープライズアーキテクチャ、プロセスインテリジェンスの接点で、クラウドネイティブプラットフォームと大規模に動作する信頼性の高いソリューションに重点を置いています。Salesforce 以前は、Microsoft でエンジニアリング職を務め、Copilot、Dataverse、Power Platform などの製品に貢献しました。