マイクロソフトが間接プロンプト インジェクション攻撃を防ぐ方法

本ブログは How Microsoft defends against indirect prompt injection attacks の抄訳版です。 最新の情報は原文を参照してください。  

エンタープライズワークフローにおける大規模言語モデル (LLM) の採用の増加により、間接プロンプト インジェクションという新しいクラスの敵対的手法が導入されました。間接プロンプト インジェクションは、大規模言語モデル (LLM) を利用して信頼できないデータを処理するシステムに対して使用できます。基本的に、リスクは、攻撃者が LLM が命令と誤解する特別に細工されたデータを提供する可能性があることです。考えられるセキュリティへの影響は、ユーザーのデータの流出から、ユーザーの資格情報を使用した意図しないアクションの実行まで多岐にわたります。 

マイクロソフトの多層防御には、以下が含まれます。 

• 強化されたシステムプロンプトやスポットライトなどの予防技術により、信頼できない入力を分離します。
• Microsoft Prompt Shields などの検出ツールは、企業全体の可視性のために Defender for Cloud と統合されています。
• データガバナンス、ユーザー同意ワークフロー、既知のデータ流出方法の決定論的ブロックを通じて、影響を軽減します。
• 新しい設計パターンと緩和技術に関する高度な研究。

このブログでは、マイクロソフトが確率論的軽減策と決定論的軽減策の両方にまたがる多層防御アプローチを使用して、間接的なプロンプト インジェクションから防御する方法について説明します。 

過去 3 年間で、大規模言語モデル (LLM) の出現により自然言語処理 (NLP) の分野に革命が起こり、Microsoft Copilot のような革新的な新しいアプリケーションが可能になりました。最新の LLM は、大量のテキストの要約、新しいコンテンツの創造的な生成、高度な推論の実行、複雑なタスクを達成するための実行計画の動的生成など、さまざまなタスクを実行できます。これを可能にした重要なイノベーションの 1 つは、最新の LLM は通常、トレーニング中に命令調整されていることです。これにより、ユーザーは、自然言語の指示とタスクの例を提供することで、推論時に LLM が実行するタスクを指定できます。 

ただし、推論時間命令を使用して LLM の出力を制御するこの機能により、LLM とそれが使用されるシステムを攻撃するために使用できる新しいクラスの技術が生まれました。特に、間接プロンプト インジェクションは、軽減が困難であり、さまざまな種類のセキュリティへの影響につながる可能性のある敵対的な手法として浮上しています。現在のシステムで最も広く実証されているセキュリティへの影響の 1 つは、攻撃者がシステムのユーザーの機密データを盗み出す可能性があることです。 

マイクロソフトに報告された AI セキュリティの脆弱性 において、間接プロンプト インジェクションは最も広く使用されている手法の 1 つです。また、LLM アプリケーションと生成 AI の OWASP トップ 10 のトップ エントリーでもあります。 

この記事では、間接プロンプト インジェクションのセキュリティへの影響について説明し、この手法を防御するためのマイクロソフトの多層防御戦略について説明します。 

間接プロンプト インジェクション ¹ は、攻撃者が LLM が正当な命令と誤解したテキストを挿入することで、命令調整された LLM の出力を制御または影響を与える手法です。攻撃者が LLM のユーザーである直接プロンプト インジェクションとは異なり、間接プロンプト インジェクションでは、攻撃者が被害者ユーザーと LLM の間の対話に命令を挿入します。 

次の図に示すように、一般的なシナリオでは、被害者のユーザーは Microsoft Copilot などの LLM ベースのサービスを操作しており、Web ページのコンテンツを要約するなど、外部ソースからのテキストを処理するように LLM に要求します。外部テキスト (Web ページのコンテンツなど) はユーザーの指示 (つまり、ユーザーの「プロンプト」) に連結され、結合されたテキストは LLM への入力として提供されます。この外部ソースのテキストが攻撃者によって制御されている場合、LLM が指示と誤解するテキストが含まれている可能性があります。これらの命令は、たとえば、白い背景に白いテキストを使用したり、印刷されない Unicode 文字を使用したりするなど、ユーザーに隠されている可能性があります。プロンプト インジェクションは、LLM が攻撃者の指示に「従った」場合に成功すると言われます。これによる影響の可能性については、次のセクションで説明します。 

上記の例は、攻撃者が制御するテキストを Web ページから送信することを示していますが、実際には、このテキストは、攻撃者がテキストを制御または影響を与えることができる任意のソースから送信される可能性があります。たとえば、LLM を使用して電子メールを処理したり、共有ドキュメントを分析したりする場合、プロンプト インジェクションは、攻撃者が被害者に送信した電子メールや、攻撃者と被害者の間で共有されるドキュメントに含まれる可能性があります。LLM がツールを呼び出す機能を持っている場合、プロンプト インジェクションはツールによって返されるデータに含まれる可能性があります。この手法には特定のファイル形式やエンコーディングが必要ないことを強調することも重要です。プレーンな ASCII でエンコードされた .txt ファイルでも、間接プロンプト インジェクションを含めることができます。 

さらに、モデルが画像、オーディオ、ビデオなどの他の形式をサポートし始めると、プロンプト インジェクションは形式のいずれかの入力から発生する可能性があります。基本的に、攻撃者が命令調整モデルへの入力の一部を制御できるときはいつでも、間接的なプロンプト インジェクションのリスクがあります。 

攻撃に成功した場合、間接プロンプト インジェクションを使用して LLM の出力をさまざまな方法で操作でき、その一部は特定のセキュリティへの影響につながる可能性があります。 

最も広く報告されている影響の 1 つは、攻撃者にユーザーのデータが流出することです。下図に示すように、プロンプト インジェクションにより、LLM はまずユーザーのデータの一部 (ユーザーの会話履歴やユーザーがアクセスできるドキュメントなど) を検索および/または要約し、データ流出技術を使用して攻撃者に返信します。 

多くの LLM ベースのシステムにおいて、以下の例のようなデータ流出手法が実証されています。 

• HTML 画像によるデータ流出: Web ブラウザー経由でアクセスされるLLM ベースアプリケーションの場合、考えられる手法の 1 つは、ソース URL が攻撃者のサーバーであるマークダウンで LLM に HTML 画像タグまたは同等のものを出力させることです。URL には、流出するデータが含まれている可能性があります (たとえば、base64 でエンコードされ、サブドメインとして、または URL パスやパラメーターの一部として追加されます) 。 画像をレンダリングするために、ユーザーのブラウザは攻撃者のサーバーにリクエストを行います。これにより、ユーザーの操作なしに意図せずにデータを盗み出します。 

• クリック可能なリンクを介したデータ流出: プロンプト インジェクションにより、LLM が攻撃者のサーバーへのクリック可能なリンクを出力し、ユーザーのデータが再び URL にエンコードされる可能性があります。これにはユーザーによる操作が必要ですが、ユーザーがリンクをクリックすることでデータが流出します。 

• ツール呼び出しによるデータ流出: LLM ベースのアプリケーションがツールを使用する場合、プロンプト インジェクションが成功すると、ツールを使用してデータを直接流出する可能性があります。たとえば、パブリック GitHub リポジトリにデータを書き込むことができるアプリケーションを使用して、機密データが漏洩する可能性があります。 

• 秘密チャネルを介したデータ流出: 同様に、LLM ベースのアプリケーションがツールを使用する場合、ツールによって有効になる秘密チャネルを使用して、間接的にデータを流出できる可能性があります。たとえば、ツールを呼び出すアクションが攻撃者によって観察できる何らかの影響がある場合、プロンプト インジェクションは、ツールを呼び出すかどうかによって、1 ビットの情報が流出する可能性があります。 

間接プロンプト インジェクションのもう 1 つの潜在的な影響は、LLM ベースのアプリケーションが、被害者のユーザーに代り、ユーザーが意図していないアクションを実行することです。広く適用可能なデータ流出とは異なり、意図しないアクションの可能性は、特定の LLM ベースのアプリケーションの機能によって異なります。これは、以下のような例があげられます。 

• 信頼できるソースからのフィッシング リンク: ユーザーに代わって電子メール (またはその他の種類のメッセージ) を送信する LLM ベースのアプリケーションは、だまされてユーザーの同僚にフィッシング リンクを送信する可能性があります。メッセージは信頼できる送信元から送信されたように見え、意図的ではないものの、正当なユーザーに代わって送信されたため、標準の電子メールなりすましチェックを通過します。 

• リモート コマンドの実行: ユーザーに代り、コードやコマンドを実行する LLM ベースのアプリケーションは、だまされて攻撃者が指定したコマンドを実行する可能性があります。これらは、ユーザーと同じレベルのアクセス許可と特権で実行される場合があります。 

ただし、すべての間接プロンプト インジェクションがセキュリティに影響を与えるわけではありません。基本的に、LLM の入力にテキストを含める理由は、LLM の出力に影響を与える可能性があるためです。多くの場合、この影響はユーザーにセキュリティ上の影響を与えませんが、セキュリティへの影響(データの流出や意図しないアクションなど)がある場合は、AIバグバーで定義しているように、脆弱性と判断します。 

間接プロンプト インジェクションは、最新のLLM ² の確率的言語モデリング、確率的生成、言語の柔軟性から生じる固有のリスクです。そのため、マイクロソフトは、予防、検出、影響の軽減にまたがる多層防御アプローチを採用しています。これらの各カテゴリ内で、防御は確率論的または決定論的のいずれかです。 

• 確率的防御: システムのランダム性 (LLM のデコード ステップなど) により、確率的防御は攻撃の可能性を減らすことができますが、攻撃のすべてのインスタンスを防止または検出できるわけではありません。 

• 決定論的防御: 特定の設計上の選択を行うことで、決定論的防御は、基盤となるシステムに確率的コンポーネント (LLM など) が含まれている場合でも、特定の攻撃が成功しないことを保証できます。 

セキュリティの観点から、決定論的防御は「ハード保証」のおかげで望ましいですが、本質的に確率論的なシステム(LLMなど)を扱う場合、すべてのケースで決定論的防御を使用できるとは限りません(たとえば、間接的なプロンプト インジェクションを決定論的に検出することは、まだ未解決の研究課題です)。このような場合、確率的防御を使用して多層防御を提供し、攻撃の実行の難易度を高めることができます。 

以下のセクションでは、社内で使用しているいくつかの手法について説明し、お客様やパートナーが LLM ベースのアプリケーションでも使用できます。 

最初のカテゴリの手法は、LLM ベースのアプリケーションが設計および実装されるときに適用されます。目的は、迅速なインジェクションの可能性に対してアプリケーションを強化することです。 

ベストプラクティスとして、インジェクションの可能性を制限するように設計された システムプロンプト (メタプロンプトまたはシステムメッセージと呼ばれることもあります)を使用します。システム プロンプトの具体的な設計はアプリケーションによって異なりますが、マイクロソフトは、ガイドライン と テンプレート安全なシステム プロンプトを作成するためのガイドラインとテンプレートを提供しています。システムプロンプトは確率的な緩和策ですが、間接的なプロンプト インジェクションの可能性を減らすことが示されています ³。 

マイクロソフトは、標準的なシステム プロンプトを超えて、LLM がユーザー提供の指示と信頼できない可能性のある外部テキストを区別するのに役立つ確率的手法である スポットライト ⁴ を開発しました。スポットライトには、システム プロンプトに対する特定の変更と、対応する外部テキストの変換が含まれます。以下の例に示すように、区切り、データマーキング、エンコードの 3 つの操作モードがあります。区切りモードでは、信頼できない入力の前後に特定のランダム化されたテキスト区切り文字が追加されます。データマーキングモードでは、信頼できないテキスト全体に特別なトークンが追加されます。最後に、エンコード モードでは、信頼できないテキストは、LLM で理解できる base64 や ROT13 などのよく知られたエンコード アルゴリズムを使用して変換されますが、異なるソースからの入力を明確に区別します。これらの各モードでは、以下の例に示すように、信頼できないコンテンツに含まれる指示に従わないように LLM に指示するようにシステム プロンプトが更新されます。 

スポットライトのさまざまなモードには、実装の容易さ、迅速なインジェクションを防ぐ効果、下流の NLP タスクへの影響などのトレードオフがあります。詳細な評価と推奨事項は、スポットライト研究論文に記載されています。 

この手法は、生成された LLM 出力に影響を与える前に、今後発生する可能性のある間接的なプロンプト インジェクションを検出するために推論時に使用されます。 

Microsoft Prompt Shields は、外部コンテンツからのいくつかの種類のプロンプト インジェクション攻撃やその他の種類の望ましくない LLM 入力を検出するための確率的分類子ベースのアプローチです。この分類器は、複数の言語で既知のプロンプト インジェクション手法についてトレーニングされており、新しい手法を考慮して継続的に更新されています。Prompt Shields は、Azure AI Content Safety の統合 API として使用できます。 

Prompt Shields が悪意のあるプロンプトを検出した場合、LLM ベースのアプリケーションはプロンプトを完全にブロックするか、他の種類の防御アクションを実行する必要があります。さらに、Prompt Shields は、AI ワークロードの脅威保護の一部として Microsoft Defender for Cloud と統合されているため、Prompt Shields からのアラートを Defender XDR ポータルに表示できます。セキュリティチームは、Defender XDR ポータルを使用して AI ワークロード アラートとインシデントを関連付け、攻撃の全範囲を把握できます。 

上記の最先端のメカニズムを使用しても、一部のインジェクションが防御を回避する可能性があります。したがって、マイクロソフトのアプローチは、すべてのプロンプト インジェクションをブロックすることではありません。代わりに、一部の迅速なインジェクションが成功したとしても、お客様のセキュリティへの影響につながらないシステムを設計しています。これは、stack canaries、ASLR、CFG、DEP などのエクスプロイト軽減技術を導入して、メモリ セーフティのバグがエクスプロイトされるのを防ぐソフトウェア セキュリティのアプローチと類似しています。 

まず、LLMベースのアプリケーションは、データガバナンスを念頭に置き設計されています。間接プロンプト インジェクション攻撃は、ユーザーと同レベルのアクセス権限で動作するLLMベースのアプリケーションに依存しています。これは、きめ細かなアクセス許可とアクセス制御を使用して決定論的に軽減できます。たとえば、Microsoft 365 Copilot には、Microsoft 365 テナント内に格納されているデータにアクセスする機能がありますが、秘密度ラベルと Microsoft Purview を使用して、Microsoft 365 Copilot が使用するデータをきめ細かく制御できます。また、Copilot が Microsoft Purview データ損失保護ポリシー によって識別されるラベル付きファイルを要約できないようにすることもできます。 

次に、間接的なプロンプト インジェクションから生じる潜在的なセキュリティへの影響を決定論的にブロックするための措置を講じます。たとえば、外部のセキュリティ研究者である Johann Rehberger によって発見され、MSRC に報告されたマークダウン画像インジェクションによるデータ流出の脆弱性に対応して、セキュリティへの影響を決定論的にブロックする措置を講じました (つまり、データ流出技術)。さらに、MSRCに報告されたすべての問題と同じアプローチを適用し、報告された特定の問題に対処するだけでなく、変異株を含む一般的なクラスの問題から保護するために、より広範囲に目を向けています。たとえば、特定の信頼できないリンクの生成など、他のデータ流出手法をブロックするために同様の手順を実行しました。 

最後に、十分に検出または軽減できない潜在的なセキュリティへの影響が依然として存在する場合、特定のアクションを実行するにはユーザーの明示的な同意を求めます。このタイプの ヒューマン・イン・ザ・ループ (human-in-the-loop / HitL) パターンは、アプリケーションに応じてさまざまな方法で実現できます。たとえば、Outlook の Copilot はユーザーに代わってテキストを生成する 「Copilot を使用した下書き」 を利用できます。ユーザーは生成されたテキストを明示的に承認し、自分で電子メールを送信する必要があります。当然のことながら、この設計パターンはユーザー エクスペリエンスの点でトレードオフを伴いますが、それでも、データの流出や意図しないアクションに対する非常に効果的な緩和策になる可能性があります。 

上記のカテゴリの手法に加えて、マイクロソフトは間接プロンプト インジェクションの原因を理解し、新しい軽減手法を開発するための高度な研究を継続しています。最新の例では、以下のようなものがあります。 

• TaskTracker: TaskTracker ⁵間接プロンプト インジェクションを検出するための新しい技術である TaskTracker を開発しました。LLM のテキスト入力と出力を調べる以前のアプローチとは対照的に、TaskTracker は推論中に LLM の内部状態 (アクティベーション) を分析することで機能します。 

• アダプティブ プロンプト インジェクション チャレンジ: LLMail-Inject と呼ばれる最初の公開されたAdaptive Prompt Injection Challenge を実施しました。これは、800 人以上の参加者がプロンプト インジェクション防御をストレス テストするために競い合うキャプチャー ザ フラッグ スタイルのチャレンジです。この重要な分野でのさらなる研究をサポートするため、私たちは370,000 を超えるプロンプトで構成されるデータセット ⁶ 全体をオープンソース化しました。 

• LLM エージェントを保護するための設計パターン: 主要な AI 企業と研究機関のコンソーシアムの一員として、特定のシナリオで間接的なプロンプト インジェクション攻撃を決定論的に軽減するために使用できる一連の 設計パターン⁷ を開発しました。 

• 情報フロー制御によるAIエージェントの保護: 情報フロー制御の分野で確立された技術を使用して、エージェントシステムへの間接的なプロンプト インジェクションを決定論的に防止するアプローチであるFIDES⁸ を開発しました。 

これらの研究活動は、マイクロソフトで開発している間接プロンプト インジェクションに対する次世代の防御の基盤を形成します。 

間接プロンプト インジェクションは、推論時の指示を理解して従う最新の LLM の能力から生じる新しい敵対的手法です。プロンプト インジェクション自体は必ずしも脆弱性ではありませんが、いくつかの異なるタイプのセキュリティへの影響を達成するために使用される可能性があります。この記事では、間接的なプロンプト インジェクションからシステムを保護するためのマイクロソフトの多層防御アプローチについて説明しました。これらの手法と設計パターンは、お客様やパートナーが独自の LLM ベースのアプリケーションを保護するために使用することもできます。 

今後を見据え、私たちは防御をさらに強化する可能性のある決定論的なアーキテクチャの変更、つまりこのブログで概説した基盤に直接構築される作業への投資を継続します。 

このブログへの貢献をしてくれた Angela Argentati、Neil Coles、Matthew Dressman、Tom Gallagher、Aanchal Gupta、Hidetake Jo、Rebecca Pattee、Yonatan Zunger と、このブログで紹介した多くのマイクロソフトのチームに感謝します。 

1. Greshake et al., “Not what you’ve signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection” AISec 2023. 
2. Russinovich et al., “The Price of Intelligence – Three risks inherent in LLMs” ACM Queue, Volume 22, issue 6, January 2025. 
3. Zverev et al., “Can LLMs separate instructions from data? And what do we even mean by that?” ICLR 2025. 
4. Hines et al., “Defending Against Indirect Prompt Injection Attacks With Spotlighting” arXiv:2403.14720. 
5. Abdelnabi et al., “Get my drift? Catching LLM Task Drift with Activation Deltas” IEEE SaTML 2025. 
6. Abdelnabi et al. “LLMail-Inject: A Dataset from a Realistic Adaptive Prompt Injection Challenge” arXiv:2506.09956. 
7. Beurer-Kellner et al., “Design Patterns for Securing LLM Agents against Prompt Injections” arXiv:2506.08837. 
8. Costa et al., “Securing AI Agents with Information-Flow Control” arXiv:2505.23643.