ツール出力を通じたプロンプトインジェクションのリスクと対策

ツール出力は、それを生成するシステムが自社のものであるという理由だけで信頼できるわけではありません。

OWASP のガイダンスにあるラベルは、ウェブページやメール本文など、外部の人間が記述したテキストに貼られるものです。チケットストア、CRM、リポジトリには貼られません。なぜなら、これらは自社のシステムだからです。攻撃者が気にするのは、どのシステムかではありません。重要なのは、自由なテキストを入力できるフィールドがどこにあるかです。チケット本文なのか、機会のメモなのか、PR の説明欄なのか。

つまり、信頼できるソースから結果が届き、入力スクリーニングでコンテンツとして通過し、それに続く呼び出しがアクションスクリーニングで承認された操作として通過します。それぞれのスクリーンは片方だけをチェックしています。しかし、攻撃は両方の抜け穴を突きます。

この記事では、2 回目のチェック（アクションスクリーニング）について、そしてそれをどう見抜くかについて解説します。

信頼するシステムが生成する「信頼できない」ツール出力

ツール出力とは、ツールの呼び出し後にエージェントのコンテキストに返されるあらゆるテキストを指します。これは OWASP の予防ガイダンス で挙げられている RAG ドキュメント、ウェブページ、メール本文と同じ「スクリーニングの桶」に分類されます。同ガイドでは、偽造されたツール出力もエージェント固有の攻撃パターンとして明記されています。

信頼できない理由は一つだけです。あなたの信頼境界の外にいる誰かが、そのフィールドに文字を仕込むことができるからです。それを配信したシステムが自社のものであるかどうかは、このリスクには影響しません。

ツールの出力が、ツールリストから予想される以上に頻繁にこのテストに失敗します。例えば、ツールは Jira で、対象フィールドは顧客が入力したチケット本文です。あるいは GitHub がツールで、対象は外部のコントリビューターが記述したプルリクエストの説明欄です。Salesforce をツールとし、インバウンドメールから貼り付けたアカウントメモを対象とするケースもあります。Postgres をツールとした場合、その行は Web フォームからの入力データです。

ツールの出力には、システムに割り当てられた信頼ラベルが付与されています。このラベルをそこに付与するのは合理的な判断です。なぜなら、システム自体が調達部門のレビューを経ており、プラットフォームチームによって統合されたものだからです。攻撃者はシステムそのものに直接触れることはありません。彼らが狙うのは、システム内部で自由テキストを受け入れる単一のフィールドです。そして、このフィールドから返されるデータには、システムの信頼性という評判が付帯した状態でエージェントに渡されます。

ツールの出力は、境界線を越えない唯一のインジェクションチャネルです。悪意のある Web ページが外部から到着すれば、それは外部コンテンツとして処理されます。一方、悪意のあるチケットは、エージェントがそれを要求する時点で既に内部に存在しています。OWASP の LLM01 エントリ は、間接インジェクションを「モデルが外部ソースからの入力を受け入れるケース」と定義していますが、チケットストアはネットワーク内にはあっても、モデルにとっては外部の存在です。

「直接注入」と「間接注入」のラベルは、どのパイプラインを検査すべきかを示すだけで、その後の処理内容については何も語りません。私たちは、汚染されたデータ摂取から漏洩に至るまでの完全なチェーンを追跡してきましたが、この記事ではラベルがその後のすべての工程を決定づける「1 つの段階」に焦点を当てます。

ツール一覧をフィールド単位で再分類する

まずはエージェントを 1 つ選んでください。同じツールでも、あるエージェントにとっては信頼できるとしても、別のエージェントにとっては信頼できないものになります。重要なのは、そのエージェントが実際に読み込む「どのフィールドか」だからです。

対象のエージェントについて、呼び出せるすべてのツールをリストアップします。次に、各ツールから返される「自由テキストを含むフィールド」だけを抽出してください。数値や列挙型（enum）、構造化された識別子は対象外です。それぞれの自由テキストフィールドに対して、「誰がそこに文字を入力できるか」を書き記します。これがラベルの正体です。

自社サービスだけが書き込むフィールドは信頼できます。一方、顧客、コントリビューター、ベンダー、あるいは Web フォームから入力される可能性があるフィールドは信頼できません。このエージェントにとって、そのツールが何と呼ばれていようとも、信頼できないデータを返すツールはすべて注入の経路となります。

典型的なサポートトリアージ用エージェントの場合、ツール一覧表は以下のようになります。

ラベルだけではリスクの順位付けはできません。信頼できないフィールドと、同じエージェント内で高権限を持つツールを組み合わせることで評価すべきです。

チケット本文を読み、返信を投稿するだけのサポートエージェントは情報漏洩のリスク要因となりますが、チケット本文を読みながら顧客テーブルへの照会や返金処理、内部リンクの開通が可能であるようなエージェントでは、強制的な呼び出しによって状態が変更される危険性があります。各エージェントのリスクは、「信頼できないフィールドの数」と「状態を変更するツールの数」を掛け合わせた値でソートし、その上位から順にベースラインを設定するのが適切です。

リモート開発環境におけるコーディングエージェントは、ほぼすべてのケースでこのリストの最上位に位置します。これらは外部コントリビューターが書き込み可能なリポジトリコンテンツを読み取り、同じランタイム内でリポジトリやクラウドの認証情報を保持しており、ツールリストにはシェル実行や外部ネットワークへの接続も含まれています。読み込む信頼できないフィールドは、保有するすべての権限付きツールと組み合わさるため、リスクが最大化されます。

OWASP の各スクリーンはループ内の一つの瞬間を捉える

OWASP の プロンプトインジェクション防止チートシート では、モデルの周囲に 3 つのスクリーンと 1 つのアーキテクチャを配置しています。それは「入力スクリーニング」「出力スクリーニング」「アクションスクリーニング」、そして「デュアル LLM パターン」です。これらはそれぞれ、エージェントループ内の特定の地点で情報を監視・評価する役割を果たします。

入力スクリーニングは、モデルが結果を確認する前にツールからの出力を検査します。チートシートでは、取得したコンテキストやツールの出力を分類器に通すよう指示されており、パターンフィルタでは信頼性の低いコンテンツにおける間接的なインジェクションを見逃すと明確に記されています。つまり、このスクリーニングは敵対的な文章を判断するモデルであり、その位置は固定されています。決定が行われる前に、結果のみを単独で確認するのです。

出力スクリーニングは、意思決定後のモデルの応答を検査します。システムプロンプトの漏洩、データ流出用のマークアップ、ポリシー違反のテキストが外部へ出る際につかまえる役割です。その位置は推論の後、ユーザーの前にあり、モデルが発した内容を確認しますが、モデルが行った行為自体はその対象外となります。

アクションスクリーニングは、提案されたツール呼び出しをユーザーの元の意図と比較して検証します。チートシートの設計では、このスクリーニングに対して中間コンテキストをあえて提供しないことで、注入された指示によって逸脱した行動であっても、意図のみに基づいて拒否できるようにしています。その位置は、それを引き起こした結果から切り離された「呼び出し」そのものです。

Simon Willison 氏が解説している「Dual-LLM パターン」は、隔離を構造的に実現するものです。隔離されたモデルが信頼できないコンテンツを読み込みますが、実際に行動を起こすことはありません。一方、権限を持つモデルはツールを保持しますが、信頼できないコンテンツを直接読み込むことは決してありません。隔離されたモデルが生み出すものはすべて、権限を持つモデルへ到達する前にフィルタリングされます。

コントローラーは汚染されたテキストを変数に保持し、参照を渡すだけで、固定セットからのラベルなど検証可能な値のみが移動できるようにします。このパターンは、未検証のデータが通過しない限り機能し続けます。その代償として、権限を持つモデルは自分が決して見ない詳細情報をすべて失います。

これらの対策のすべてが実務で効果を発揮しますが、静的な攻撃者に対する評価では、検出器モデル、区切り文字、サンドイッチ手法はいずれも同じ構造的欠陥により崩壊しました。これは 適応型攻撃者 に対して特に顕著です。

ツール出力の後に追加した サンドイッチ手法 は、レートリデューサーとして機能するため、引き続き維持すべきです。

つまり、4 つの制御は以下の 4 つの瞬間に対応しています。結果、レスポンス、呼び出し、そしてコントローラーが許可するもの。それぞれに 1 つずつの瞬間があります。

注入は「結果」と「次の呼び出し」の間に存在する

ツールの結果がコンテキストウィンドウに格納され、同じターン内でエージェントが次の呼び出しを発行します。これらは数百年ミリ秒の間隔で発生する 2 つのイベントですが、その隙間で注入が発生します。

エージェントが読み込んだ情報のうち、最も直近のものが結果として返されます。これが機能する理由は「直近性」にあります。説明は他のツールの説明と一対一の競争を繰り広げる一行に過ぎませんが、結果はエージェントが次の行動を決める瞬間におけるウィンドウ内の最後の情報であり、エージェントが要求したデータとしての権威を持っています。

この違いは測定可能です。悪意のあるツール tool descriptions をベンチマークした研究者たちは、InjecAgent から攻撃ペイロードを抽出しました。これは悪意のあるテキストがツールの実行結果として現れるベンチマークです。彼らはこれを静的なメタデータへ移動させました。その結果、攻撃の成功率はほぼゼロにまで低下しましたが、目的別に設計された説明用ペイロードは、同じモデルで 41.8% の成功を収めました。

その後エージェントが行う呼び出しは、ある一点を除けば何ら特筆すべき点はありません。それは登録済みのツールを使用し、スキーマが検証され、セッションも承認されています。異なるのは、目的地、パス、テーブル名、あるいはこのエージェントがこれまで一度も使用したことのない引数の値です。

3 ヶ月間にわたりチケットストアやナレッジベースを読み込んできたエージェントは顧客テーブルを照会します。常に社内宛てのメールを送信してきたエージェントは、外部宛てにメールを送ります。設定ファイルを読み込むエージェントは、キーパスを読み込みます。

すべてのチェックが通る理由は、そのチェック自体が本来いるべきではないアクターのために設計されているからです。このアクターは権限を与えられていました。これが強制（coercion）です。信頼された入力が、エージェントの許可された能力を別の誰かの目的へと誘導する現象です。すべてのステップは許可されています。攻撃の本質は、そのシーケンスにあります。

このシーケンスこそが、どの画面にも記録されていない唯一のオブジェクトです。入力スクリーニングでは結果があり呼び出しがありません。一方、アクションスクリーニングは設計上、呼び出しはあるものの結果がありません。出力スクリーニングは、すでに呼び出しが実行された後に訪れます。このペアは、1 つのターン内で数百年ミリ秒の間だけ存在し、両方の側面を認識できるのは、エージェントの実行を見守っていた監視者だけです。それが問題になるほど速く検知するには、エージェントの履歴とともにそこで捉える必要があります。なぜなら、その呼び出しの唯一の特徴は、このエージェントが過去にこれを行ったことがないという点だからです。

エージェント自身の履歴には、強制された呼び出しの先例はない

このペアを認識するためには、3 つのものが必要です。まず基準となるデータセット、次に逸脱を検知するルール、そして何かがブロックされる前に始まる執行経路です。

ベースラインとは、エージェントが強制されていない場合に実行する特定の動作の記録です。この攻撃においては、以下の4 つの項目を記録する必要があります。

1. エージェントが呼び出すツールの種類
2. それらに対して使用する引数の値
3. 呼び出しの順序
4. 各呼び出しによって生成されるファイル、プロセス、およびネットワークアクティビティ

このうち4 つ目の項目こそが、単なるツール呼び出しログと実行ベースラインを区別する決定的な要素です。なぜなら、攻撃の結果は実際にはその呼び出しの下位で発生するためです。

ARMO はこれを「Application Profile DNA (APD™)」として構築しています。これは、ワークロードの動作をカーネルレベルで観測することで、エージェントごとに行動ベースラインを構成したものです。つまり、この記録は実行に基づいて作成されたものです。

攻撃者が対象としているのは宣言されたツールリストですが、実際に観測されるリストは彼らが直接照会できないものです。

ツール結果の直後のターンで、そのベースラインに先例のない呼び出しが発生したとき、それが「逸脱」として検知されます。これは、エージェントがこれまで一度も使用したことのない新しいツールを呼び出した場合か、あるいは既知のツールであっても、引数が初めてのもの（例えば、送信ツールの宛先、クエリツールのテーブル名、読み取りツールのパスなど）である場合に該当します。

単に「このエージェントはメールを送信した」という事実のみを記録するベースラインでは、引数の変更を検知できません。一方、「どの宛先に送信したか」まで記録しているベースラインであれば、最初の呼び出し時点で逸脱としてフラグが立ちます。

逸脱が発生すると、その直前の結果イベントと、それに続く呼び出しが一つのタイムライン上に統合され、「攻撃ストーリー」として扱われます。これにより、対応担当者は片方の要素だけでなく、両方の要素を含む単一のインシデントとして状況を把握できます。なお、この検知シグナルは、注入攻撃を伴わないツール misuse（ツール誤用）にも適用されます。

強制実行のパスは、監査から強制へ の流れで動作します。監査モードでは、ベースラインとの乖離が記録されますが、呼び出し自体はブロックされません。これにより、ポリシーが生産環境のトラフィックに対して安全であることを実証し、何かを壊すリスクを回避できます。一方、強制モードでは、乖離した呼び出しが停止されます。クレデンシャルの分離機能は、もう一つの側面からこのループを完結させます。つまり、他のすべてのチェックを通過しても、強制的にクレデンシャルパスを読み込もうとした場合、攻撃者が利用可能な情報は一切返されません。リモート開発環境におけるコーディングエージェントにとって、これは「注入された指示」と「クラウドログイン情報の漏洩」の違いを意味します。AI ワークロード向けの ランタイム行動セキュリティ は、各フレームワークを個別に計測することなく、エージェントごとの可視性を可能にする技術です。

攻撃者がベースラインの存在を知っていれば、その範囲内で行動し、エージェントの挙動を徐々に拡大させることで、単一の呼び出しが閾値を超えることなく攻撃を成功させようとする可能性があります。この攻撃は実際に存在しており、本稿で扱うケースの中で最も困難なものです。ただし、攻撃者にとっての代償は、彼が行わなければならない作業にあります。ベースラインは特定のクラスター内の 1 つのエージェントの履歴から構築されるため、ダウンロードしてオフラインで分析したり、実行前に練習したりすることはできません。

プラットフォームチームにとっては、コード変更やサイドカー不要のセンサーで済みます。CISO（最高情報セキュリティ責任者）にとっての成果物は、インシデントごとに 1 つのタイムラインが生成され、結果と原因となった呼び出しを特定できる点にあります。

結果をスクリーンし、その後に続く呼び出しを計測する

画面は常時監視され、一時的なノイズを排除します。結果として、基盤が審査すべき対象が減り、処理負荷が軽減されます。

しかし、攻撃者が仕掛けた特定のペイロード（ターゲット型）は、このフィルタリングをすり抜ける可能性があります。なぜなら、そのペイロードは入力チェックでは「正当なコンテンツ」として通過し、さらにアクションチェックでも「許可された呼び出し」として認識されるからです。

攻撃者にとって避けられないのは、この「ペア」の存在です。最終的に注入された指示を実行させるには、実際のツールを動かす必要があり、その結果として生じる呼び出し履歴は、攻撃者が事前に把握していないものです。

対策としては、以下の3つの手順を順に実行してください。

1. ツール一覧を機能別に再分類する。
2. 信頼性の低いフィールドと状態変更機能を組み合わせるエージェントをランク付けする。
3. ランキング上位のエージェントをベースラインとして設定し、監査モードで動作させます。偏差率が安定したら、本番環境での強制適用を開始してください。

デモを見る では、エージェント自身の履歴に対して強制的に呼び出しが行われた様子を視覚的に確認できます。

よくある質問

エージェントのツール出力のうち、攻撃者が書き換え可能なものはどのように特定すればよいですか？

エージェントは一つずつ処理し、各ツールが呼び出せる際の返却スキーマを必ず確認してください。ツールの名前からフィールドの内容を推測することはできません。自由テキストとして型付けされたフィールドはすべて候補となり、その信頼性は「誰が記述できるか」によって決まります。顧客、外部の貢献者、受信メールパーサー、Web フォームなどを通じて入力されるデータは、いずれも不審な情報源とみなすべきです。チケット本文、PR（プルリクエスト）の説明、CRM のノート、カレンダーの説明、ログ行などは、外部からのテキストが生産環境のエージェントに流入する主要な経路となるフィールドです。

各フィールドのラベルを記録し、エージェントが参照する不審なフィールドの数と、状態を変更できるツールの保有数に基づいてランク付けを行います。

ツール出力を区切り文字で囲んだり、その後にユーザー指示を繰り返したりすれば、この問題は解決するのか？

これらは偶発的なペイロードの発生率を下げる効果があり、その理由から導入を続けるべきです。ただし、適応型テストでは、攻撃者が設計への対策を最適化すると、区切り文字の規約や指示のサンドイッチ手法は、もともと報告されていた攻撃成功率が 20 代前半～中盤だったものが、90 年代後半～高値にまで上昇しました。これはどちらも、注入された指示によって直接扱われるマーク付け規約をモデルが遵守することに依存しているためです。

これらは「量」に対するフィルタとして扱い、自社のスタック向けに作成されたペイロードはこれらのフィルタをすり抜ける可能性があると想定してください。モデルの協力を必要とせず、モデルが生成した呼び出しそのものを読み取る制御こそが、真の効果的な対策です。

ツールの結果は、取得したドキュメントと同じ分類器に通すべきか？

はい、OWASP の予防ガイダンスでは、ツール出力を RAG ドキュメントや Web ページと同様に、入力スクリーニングの対象となるコンテンツとして挙げています。ユーザープロンプトのみを読み取る分類器では、最も重要なチャネルが読み飛ばされてしまいます。両者の分類器の限界は同じで、決定が行われる前にテキストだけを見て、「悪意のないデータ」として見えるものはすべて通過させてしまいます。テキストが引き起こす呼び出しを分類器が見ることはできないため、結果のスクリーニングと呼び出しの計測は、異なる瞬間をカバーする 2 つの独立した制御手段となります。

ツール出力インジェクションと MCP ツールポイズニングの違いは何ですか？

エントリポイントとタイミングです。ツールポイズニング では、指示が登録時にツールの説明に含まれます。これはまだプロンプトが存在しない段階であり、他のすべてのツールのメタデータと競合し、発火させるためのトリガー条件が必要です。一方、ツール出力インジェクションでは、指示がツールの実行結果に含まれます。これはエージェントが次の行動を決定する際、コンテキストウィンドウ内で最も直近に存在するコンテンツです。

標準的なツール出力ペイロードを説明欄へ移行したベンチマークでは成功が崩壊しました。このため、両者には異なるペイロード構文が必要であり、ツール結果の方がより多くの量を扱うベクトルとなるのです。

結果と呼び出しのペアを確認するために必要なテレメトリは何ですか？

各ストリームは特定のエージェントに紐付けられています。ツール呼び出しの記録には引数の値が含まれており、最も効果的な強制攻撃が単なる引数の変更や呼び出し境界の変化に過ぎないため、その呼び出しと直前の結果を関連付けることができます。

また、カーネルレベルのファイル、プロセス、ネットワーク活動も追跡可能です。これは eBPF によってコード変更なしで収集され、呼び出しが実際に何を行ったかを内部から明らかにします。

さらに、アイデンティティの特定により、ワークロードを単一のエージェントに帰属させることができます。同じ名前空間内に複数のエージェントが存在する場合、それぞれが「正常」の定義を異なるものとして持つためです。