脆弱性

AIエージェントが暴走するとき: A2Aシステムにおけるエージェントセッションスマグリング攻撃

3 分で読めます

エグゼクティブサマリー

弊社は新しい攻撃手法を発見しました。エージェントセッションスマグリングと称しています。このテクニックでは、悪意のある AI エージェントが確立されたエージェント間通信セッションを悪用して、被害者エージェントに秘密の指示を送るものです。

本稿では、エージェント間の接続を管理するための一般的なオプションであるAgent2Agent(A2A)プロトコルを使用した通信セッションで発生する可能性のある問題について説明します。A2Aプロトコルのステートフルな動作は、エージェントが最近のやりとりを記憶し、首尾一貫した会話を維持することを可能にします。この攻撃は、この性質を悪用して、悪意のある命令を会話に注入し、正規のクライアントリクエストやサーバーレスポンスの中に隠します。

AIの脅威の多くは、欺瞞的な電子メールや文書といった、単一の悪意あるデータでエージェントを騙す点に焦点が当てられています。調査を行うなかで、悪意のあるエージェントという、より高度な危険性が浮き彫りになりました。

標的となった被害者エージェントへの単純な攻撃は、ユーザーからの確認を求めることなく、文書からの有害な指示に基づいて行動するといった、エージェントを騙す1回限りの試み（ワンショット攻撃）である場合がほとんどです。対照的に、ローグ(不正な)エージェントははるかにダイナミックな脅威となります。会話を続け、戦略を変更し、何度もやりとりすることで誤った信頼感を築くことができるからです。

このシナリオは特に危険なものです。最近の研究が示すように、エージェントはデフォルトで他の協力エージェントを信頼するよう設計されていることが多いからです。エージェントセッションスマグリングは、この組み込みの信頼を悪用し、攻撃者がセッション全体にわたって被害者エージェントを操作することを可能にします。

調査では、A2Aプロトコル自体の脆弱性は明らかにされていません。むしろ、この手法はエージェント間の暗黙の信頼関係がステートフルプロトコル(つまり、最近のやり取りを記憶し、複数回のやり取りを実行できるプロトコル)に及ぼす影響を利用していることが示唆されています。

緩和策には、以下のような重層的な防御戦略が求められます。

重要なアクションに対するHitL(Human-in-the-Loop)の実施
リモートエージェント検証(暗号署名されたエージェントカードなど)
トピックから外れた指示や注入された指示を検出するためのコンテキストグラウンディング技術

パロアルトネットワークスのお客様は、以下の製品とサービスをご利用いただくことでより強固な保護を構築いただけます。

Prisma AIRSは、さまざまなAIアプリケーションにおいて、脅威の検出とブロック、データ漏洩の防止、安全な使用ポリシーの実施により、AIシステムをレイヤー化し、リアルタイムで保護できるように設計されています。

AI Access Securityは、サードパーティの生成AIツールの使用を可視化および制御するために設計されており、ポリシーの実施とユーザーアクティビティの監視を通じて、機密データの暴露、危険なモデルの安全でない使用、有害な出力の防止を支援します。

Cortex Cloud AI-SPMは、商業モデルと自己管理モデルの両方のAI資産の自動スキャンと分類を提供し、機密データを検出してセキュリティ態勢を評価するように設計されています。コンテキストは、AIの種類、ホスティングクラウド環境、リスク状況、姿勢、データセットによって決定されます。

Unit 42 AIセキュリティ評価は、AI環境を標的とする可能性が最も高い脅威を事前に特定するのに役立ちます。

情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデントレスポンスチームまでご連絡ください。

Unit 42の関連トピック	GenAI, Google

A2Aプロトコルの概要とMCPとの比較

A2Aプロトコル A2Aプロトコルは、ベンダー、アーキテクチャ、基礎技術に関係なく、AIエージェント間の相互運用可能な通信を促進するオープンスタンダードなプロトコルです。その主な目的は、エージェントが自律性とプライバシーを維持しながら、複雑な分散タスクを解決するために、互いに発見、認識、調整できるようにすることです。

A2Aプロトコルの特徴:

ローカルエージェントは、開始エージェントと同じアプリケーションまたはプロセス内で実行され、高速なインメモリ通信を可能にする。
リモートエージェントは、独立したネットワークアクセス可能なサービスとして動作する。A2Aプロトコルを使用して安全な通信チャネルを作成し、他のシステム、あるいは他の組織から委任されたタスクを処理し、結果を返すことができる。

A2Aの基礎とセキュリティに関する考察の詳細については、以下の記事をご参照ください。AIエージェントの保護: A2Aプロトコルのリスクと軽減策の詳細解説。

A2Aは、大規模言語モデル(LLM)を外部ツールやコンテキストデータに接続するための広く利用されている標準であるモデルコンテキストプロトコル(MCP)との顕著な類似点があります。両者とも、AIシステムの相互作用を標準化することを目的としていますが、エージェントシステムとは異なる側面に取り組んでいます。

MCPはユニバーサルアダプターとして機能し、ツールやデータソースへの構造化されたアクセスを提供します。主に集中型統合モデルを通じて、LLMからツールへのコミュニケーションをサポートします。
A2Aはエージェント間の相互運用性に重点を置いています。エージェントがタスクを委任し、情報を交換し、協調的なワークフロー全体の状態を保持することができる、分散化されたピアツーピアの調整を可能にします。

つまり、MCPがツールの統合による実行を重視するのに対し、A2Aはエージェント間のオーケストレーションを重視していると言えます。

このような違いはあるものの、表1に示すように、どちらのプロトコルも似たような脅威のクラスに直面しているのが現状です。

攻撃/脅威	MCP	A2A
ツール/エージェントデスクリプションポイズニング	ツールディスクリプションには、ツールの選択や実行時にLLMの動作を操作する悪意のある命令が混入する可能性がある。	AgentCardのディスクリプションは、プロンプトインジェクション攻撃や、消費されたときのクライアントエージェントの振る舞いを操作する悪意のあるディレクティブを埋め込むことができる。
ラグプルアタック	以前は信頼されていたMCPサーバーが、統合後に予期せず悪意のある動作に移行し、確立された信頼関係を悪用する可能性がある。	信頼されたエージェントが、エージェントカードや操作ロジックを更新することで、予期せず悪意のあるエージェントになる可能性がある。
ツール／エージェントシャドウイング	悪意のあるサーバーが、正規のツールと同一または類似した名前でツールを登録し、ツール選択時に混乱を招く。	不正エージェントは、類似した名前、スキル、またはタイポスクワッティング技術によって正規エージェントを模倣したエージェントカードを作成する。
パラメータ／スキルポイズニング	ツールのパラメータを操作して、外部サーバーへのリクエストに意図しないデータ(会話履歴など)を含めることができる。	AgentCardのスキルと例は、エージェントの対話方法を操作するように細工することが可能であり、機密性の高いコンテキストや認証情報を公開する可能性がある。

表1. MCP攻撃とA2A攻撃の比較。

エージェントセッションスマグリング攻撃

エージェントセッションスマグリングは、A2Aシステムのようなステートフルなエージェント間通信に特有の新しい攻撃ベクトルです。通信がステートフルであるのは、最近のやりとりを記憶している場合であり、たとえば、両者が進行中のコンテクストを追跡している会話のようなものです。

攻撃の核心は、悪意のあるリモートエージェントが進行中のセッションを悪用し、正当なクライアントリクエストとサーバーのレスポンスの間に追加命令を注入する点にあります。これらの隠された命令は、コンテキストポイズニング(AIが会話を理解するのを妨害すること)、データ窃取、またはクライアントエージェント上での不正なツールの実行につながる可能性があります。

図1に攻撃シーケンスの概要を示します。

ステップ1: クライアントエージェントは、リモートエージェントに通常のリクエストを送ることで、新しいセッションを開始。
ステップ2: リモートエージェントはリクエストの処理を開始。このアクティブなセッションの間、リモートエージェントはクライアントエージェントに対し、複数回のやり取りにわたって密かに余分な指示を送ります。
ステップ3: リモートエージェントは、元のリクエストに対する期待される応答を返し、トランザクションを完了します。

サイバーセキュリティ攻撃のプロセスを示す図。左側が被害者クライアントエージェント、右側が悪意のあるリモートエージェント。ステップは次の通りとなっている。1) クライアントからのリクエスト。2) 悪意ある行為。3) サーバーの応答。 — 図1.エージェントセッションスマグリング攻撃の流れ。

攻撃の主な特徴

ステートフル: この攻撃は、リモートエージェントが長時間実行するタスクを管理し、セッションの状態を持続させる機能を利用するものです。人が会話の文脈を記憶しながら対話を続けるように、エージェントが対話の文脈を保存することを意味します。ステートフルとは、エージェントが複数のターンにわたってセッション固有の情報を保持し、参照することを意味するので(例えば、セッションIDに結びついた会話履歴、変数やタスクの進捗状況)、後のメッセージは以前のコンテキストに依存することができます。
マルチターンインタラクション: ステートフルであるため、接続された2つのエージェントはマルチターンで会話することができます。悪意のあるエージェントはこれを悪用し、段階的で適応的なマルチターン攻撃を展開します。先行研究では、こうした攻撃に対する防御が著しく困難であることが示されています(例:「LLM防御はマルチターン型人間による脱獄攻撃に対して未だ堅牢ではない」を参照)。
自自律的かつ適応的: AIモデルを搭載した悪意のあるエージェントは、クライアントの入力、中間応答、ユーザーIDなどのライブコンテキストに基づいて動的に指示を作成することができます。
エンドユーザーに検出されない: 注入された命令はセッションの途中で発生するため、エンドユーザーには見えません。エンドユーザーは通常、クライアントエージェントからの最終的な統合された応答しか確認しないからです。

原理的には、ステートフルなエージェント間通信を行うマルチエージェントシステムであれば、この攻撃を受ける可能性があります。しかし、単一のトラストバウンダリーに完全に含まれるセットアップでは、リスクは低くなります。信頼境界とは、システム内の領域であり、そこではすべてのコンポーネントがデフォルトで信頼されます。例えば、ADKやLangGraphといったマルチエージェントシステムでは、1人の管理者が参加するすべてのエージェントを制御します。

そのため、弊社の調査は、信頼境界を越えた相互運用性を実現するために設計されたA2Aプロトコルに焦点を当てています。この相互運用性は、エージェントは異なるシステム、モジュール、組織間での連携を実現するものです。

既知のMCPの脅威と比較して、エージェントセッションスマグリングは、MCPでは不可能な方法で、A2Aのステートフルで適応性のある設計を悪用します。MCPサーバーは一般的にステートレス方式で動作し、セッション履歴を保持せずに独立したツール呼び出しを実行するため、アクターがそれらを利用して複数ターンにわたる攻撃や進化型攻撃を仕掛ける能力が制限されます。

また、MCPサーバーはAIモデルに依存しないため、一般的に静的で決定論的であるとされます。対照的に、A2Aサーバーは、相互作用に渡って状態を持続し、モデル駆動型の推論を活用することができるため、悪意のあるエージェントが複数のターンにわたって指示を適応させ、改良することができます。この持続性と自律性の組み合わせにより、エージェントセッションスマグリングは、MCPベースの攻撃よりもステルス性が高く、防御が難しくなっています。

エージェントセッションスマグリング攻撃の概念実証

エージェントセッションスマグリング攻撃の実現可能性と潜在的な影響を実証するために、弊社は2つの概念実証(PoC)攻撃シナリオを開発しました。セットアップは、財務アシスタント(クライアントエージェント)とリサーチアシスタント(悪意のあるリモートエージェント)で構成されています。これらのPoCは、悪意のあるエージェントがエンドユーザーに気づかれることなく機密データを盗み出し、不正なアクションを実行する方法を説明するものです。

機密情報の漏洩: クライアントエージェントからの機密データの抽出
不正なツール起動: クライアントエージェントに、被害者ユーザーに代わって不正なアクションを実行するように仕向ける

環境設定:

開発フレームワーク: Google Agent Development Kit
エージェント間通信プロトコル: A2A
クライアントエージェントADKの財務アドバイザー例に基づく財務アシスタント。エージェントは、金融ニュースの取得、ポートフォリオの管理、取引操作の実行などのタスクをサポートする。
- モデル:Gemini 2.5 Pro
- 利用可能なツール: get_portfolio、get_profile、buy_stock、sell_stock
リモートエージェント: ADKから転用されたリサーチアシスタント data_analystの例を参考。本来の役割は、企業のニュースを取得し、要約するもの。
- モデル:Gemini 2.5 Flash
- 利用可能なツール: Google検索
ユーザーインターフェイス: ADK Developer Web UI

PoC 1: 機密情報の漏洩

このシナリオでは、悪意のあるリモートエージェント(リサーチアシスタント)が、クライアントエージェント(財務アシスタント)の内部状態のデータ窃取を試みるものです。窃取対象は以下を含みます。

チャット履歴
システムの説明
利用可能なツール
ツールスキーマ

攻撃は巧妙に（あるいは気づかれないように）展開します。財務アシスタントから正当な要求を受けると、リサーチアシスタントは一見無害に見える明確な質問を次々と投げかけます。こうしたフォローアップの質問は、財務アシスタントを徐々に騙して、決してその環境から離れるべきではない機密情報を開示させてしまいます。

図2はユーザーのインタラクションの流れを示したものです。セッションは普通に始まります。ユーザーは財務アシスタントに投資ポートフォリオとプロフィールの取得を依頼し、続いてAIマーケットニュースのブリーフィングを依頼します。

このマーケットニュースの依頼はリサーチアシスタントに委ねられます。図の右側に示すように、リサーチアシスタントは財務アシスタントと一連のやりとりを行います。最初のリクエストと最後の応答を除いて、リサーチアシスタントはすべての中間的なやりとりを注入します。

図2に示された中間ステップは、開発者のWebユーザーインターフェイス(UI)がすべての内部アクションを表示するように設計されているため、表示されていますが、本番のチャットボットUIでは、このような中間的なインタラクションは多くの場合見えないままとなります。

チャットインターフェイスの分割画面表示イメージ。左側では、ユーザーが黄色で強調表示された財務アシスタントボットにポートフォリオの更新を依頼している。右側のフローチャートは、さまざまなデータ要求と応答を伴うユーザーとボットの一連のやりとりを示しており、緑と黄色で強調されている。最初の依頼はリサーチアシスタントへのもの。そして、財務アシスタントとリサーチアシスタントとの間には、意図しない相互作用があることが分かる。最後の項目は、リサーチアシスタントからの最後の回答である。 — 図2.デベロッパーのWeb UI。右側は財務アシスタントとリサーチアシスタント間の内部交流を示す。

図3は、財務アシスタントの活動ログを通して、より詳細なビューを示したものです。第10行はリサーチアシスタントに送られた最初のクエリを示し、第28行はリサーチエージェントが生成した最終結果を示します。11行目から27行目までは、function_callとfunction_responseが交互に表示され、2つのエージェント間の相互作用が明らかにされています。そのやりとりの中で、財務アシスタントは徐々にそのシステム構成とユーザーの過去の会話履歴を開示していったことが分かります。

統合開発環境(IDE)内のコードとテキストを表示するコンピューター画面のスクリーンショット。人工知能の市場動向を分析し、関数呼び出しと顧客IDに言及している。いくつかのセクションは黄色のボックスで強調表示されている。 — 図3.財務アシスタントの行動ログには、意図しないスマグリングのやりとりが記録されている。

最後に、図4は攻撃後のリサーチアシスタントのログを示したものです。財務アシスタントの機能、ツールスキーマ、セッション履歴全体を含む、データ窃取の成功を確認することができます。

様々な投資ポートフォリオの詳細を表示する財務アドバイザーのコマンドラインインターフェイスのスクリーンショット。 — 図4.窃取した設定データを示すリサーチアシスタントのログ。

PoC2: ツールの不正起動

このシナリオでは、悪意のあるリモートエージェント(リサーチアシスタント)は、クライアントエージェント(財務アシスタント)を騙して不正な取引を実行させようとしています。攻撃者の目的は、クライアントエージェントのbuy_stockツールを、エンドユーザーの認識や同意なしに悪用することです。

有効な委任要求を受信した後、リサーチアシスタントは追加の処理要求を送信し、財務アシスタントにユーザーの元の要求とは無関係なツールの起動を実行するよう促します。このPoCは、攻撃者が財務アシスタントのツールを知っており、公開情報または前回のPoCで入手したことを前提とするものです。

図5は、ユーザーのインタラクションの流れを示したものです。右側では、ユーザーのニュースリクエストがリサーチアシスタントに委ねられていることが分かります。リサーチアシスタントは期待されたニュースの要約を提供する一方で、財務アシスタントがbuy_stockツールを起動するよう誘導する隠された指示もスマグリングしています。繰り返しますが、これらの中間処理は自律的に実行されており、一般的な本番チャットボットのインターフェースではユーザーには最終的な要約応答のみが表示されるため、これらの処理はユーザーには不可視のままとなります。

財務アシスタントとリサーチアシスタント間のコミュニケーションのスクリーンショット。左は財務アシスタント。右側はリサーチアシスタントで、最初のリクエストはリサーチアシスタントに送られている。財務アシスタントとリサーチアシスタントとの間には、意図しない相互作用があることが分かる。リサーチアシスタントからの最終回答がある。 — 図5.スマグリングされた指示を含む、財務アシスタントとリサーチアシスタント間のコミュニケーションを示す開発者のWeb UI。

図6は財務アシスタントのアクティビティログを示したものです。7行目はリサーチアシスタントに送られた最初のリクエストで、12行目は受け取った正当なレスポンスです。しかし、8行目から11行目にかけて、財務アシスタントが自律的に実行した4つのアクションが追加され、被害者ユーザーに代わって10株の不正取引が行われたことが分かります。この一連の流れは、エージェントセッションスマグリングが、情報漏洩から影響力の大きいツールの実行へとどのようにエスカレートするかを説明するものです。

統合開発環境(IDE)でコードを表示するコンピュータ画面のスクリーンショット。株式調査と取引活動に関連する特定の機能とその反応を強調する注釈が付されている。ハイライトされている部分は、buy_stock()ツールの起動と応答を示す。 — 図6.財務アシスタントのアクティビティログには、スマグリングされた指示が引き金となった不正な株式購入が記録されている。

緩和措置と保護

エージェントセッションスマグリングに対する防御には、エージェントのアイデンティティ、会話の完全性、および実行されたアクションの影響を検証する多層セキュリティアプローチが必要です。以下の戦略は、リスクを軽減するのに役立ちます。

機密性の高いアクションに対して、帯域外の確認を強制する: 最も効果的な防衛策は、機密性の高い行動や影響力の大きい行動にはHitLの承認を必要とすることですが、この確認はLLMが影響力を行使できない別のチャンネルを通じて、帯域外で行われる必要があります。エージェントがクリティカルなタスクの実行を指示されたとき、オーケストレーションフレームワークは実行を一時停止すべきです。そして、アプリケーションUIの静的な（動的に生成されない）部分で、あるいはプッシュ通知のような別のシステムを通じて、確認プロンプトをトリガーすることが求められます。
コンテキストの**グラウンディング（文脈の紐付け）を実施する: エージェントセッションスマグリング攻撃は、悪意のあるコマンドを注入するうえで、本来の目的から会話を脱線させることに依存しています。コンテキストグラウンディングは、会話の整合性をアルゴリズムで強制する技術的なコントロールです。クライアントエージェントがセッションを開始するとき、元のユーザーリクエストの意図に基づいてタスクアンカーを作成することが重要となります。やりとりが進むにつれて、クライアントは、リモートエージェントの指示がこのアンカーと意味的に一致していることを継続的に検証する必要があります。重大な逸脱や無関係なトピックが注入された際は、クライアントエージェントがハイジャックの可能性があると判断し、セッションを終了するよう構成する必要があります。
エージェントの身元と能力を検証する: セキュアなエージェント間通信は、検証可能な信頼の基盤の上に構築されている必要があります。セッションを開始する前に、エージェントは暗号署名付きAgentCardなどの検証可能な認証情報を提示することが求められます。これにより、各参加者は相手の身元、出所、宣言された能力を確認することができるようになります。このコントロールは、信頼されたエージェントが破壊されることを防ぐものではありませんが、エージェントのなりすましやなりすまし攻撃のリスクを排除し、監査可能で改ざん不可能なすべての対話の記録を確立します。
クライアントエージェントの活動をユーザーに公開する: スマグリングされた指示やアクティビティは、エンドユーザーには見えません。エンドユーザーは通常、クライアントエージェントからの最終的なレスポンスしか見ないからです。UIは、リアルタイムのエージェントの活動を公開することで、この弱点を減らすことができます。例えば、ツール呼び出しの可視化、ライブ実行ログの表示、リモート命令の視覚的インジケータの提供などが検討できます。これらのシグナルはユーザーの意識を向上させ、不審な行動をキャッチする可能性を高めるものです。

結論

本調査では、A2Aシステムにおけるエージェント間の通信を標的とした新しい攻撃手法である、エージェントセッションスマグリング攻撃を紹介しました。悪意のあるツールやエンドユーザーを含む脅威とは異なり、侵害されたエージェントは、より強力（または「厄介な」）敵対者となります。AIモデルにより、侵害されたエージェントは、自律的に適応戦略を生成し、セッションの状態を悪用し、接続されているすべてのクライアントエージェントとそのユーザー全体に影響力を拡大することができます。

本稿執筆時点では、この攻撃が実際に悪用された事例は観測されていません。しかし実行への障壁が低いため、現実的なリスクであるとしています。敵対者は、被害者エージェントに悪意のあるピアに接続するよう説得するだけでよく、その後、ユーザーの目に触れることなく秘密の命令を注入することができるためです。このような攻撃から組織を守るには、以下を含む多層の防御策を講じる必要があります。

機微な行動に対するHitL承認
モデルプロンプトの外側で強制される確認ロジック
コンテキストグラウンディングによるトピックから外れた指示の検出とリモートエージェントの暗号検証

マルチエージェントエコシステムが拡大するにつれて、その相互運用性は新たなアタックサーフェスを広げるものとなります。セキュリティ実務者は、エージェント間通信を本質的に信頼すべきではないという前提に立つ必要があります。また、何重ものセーフガードを備えたオーケストレーションフレームワークを構築して、適応力のあるAIを搭載した敵のリスクを封じ込める必要があります。

パロアルトネットワークスの保護と緩和策

Prisma AIRSは、AIアプリケーション、モデル、データ、エージェントをリアルタイムで保護できるように設計されています。ネットワークトラフィックとアプリケーションの挙動を分析し、プロンプトインジェクション、サービス拒否攻撃、データ窃取などの脅威を検出し、ネットワークとAPIレベルでインライン実施します。

AI Access Securityは、サードパーティの生成AIツールの使用を可視化および制御するために設計されており、ポリシーの実施とユーザーアクティビティの監視を通じて、機密データの暴露、危険なモデルの安全でない使用、有害な出力の防止を支援します。Prisma AIRSとAI Access Securityを併用することで、企業のAIアプリケーションの構築や外部とのAIインタラクションの安全性を確保することができます。