prompt-injection

プロンプトインジェクションの脆弱性評価

このスキルでは、LLM を統合したアプリケーションにおけるプロンプトインジェクションの脆弱性を、体系的にセキュリティレビューする方法を説明します。**OWASP LLM01:2025（プロンプトインジェクション）およびMITRE ATLAS AML.T0051（LLM プロンプトインジェクション）**に準拠しています。

制限事項

• 見落としの可能性： このスキルは、利用可能なコード、設定、ログ、ドキュメント、およびユーザーから提供されたコンテキストに依存します。証拠が不足している場合、実行時にしか確認できない場合、またはレビューの範囲外である場合、対策の存在や脅威の不在を証明することはできません。
• 誤検知のリスク： アセットの重要度、代替の対策、環境の意図、および最近の承認済み変更に照らして検証するまでは、検出事項を仮説として扱ってください。
• 必要な証拠： 各検出事項は、ファイルパスと行番号、ポリシーの抜粋、スキャナーの出力、ログ、スクリーンショット、対策の記録、または再現可能な手順など、具体的な成果物で裏付けてください。
• 正規化された JSON： 機械可読な出力が求められる場合、検出事項は schemas/finding.schema.json に対して検証可能な JSON 形式で必ず提供してください。
• エスカレーションルール： 侵害が進行中である疑い、シークレットの露出、規制対象データの露出、悪用可能な重大な脆弱性、特権アクセスの不正使用がある場合、または影響の大きいリスクを安全に処理できるだけの証拠が不十分な場合は、直ちにエスカレーションしてください。

---

プロンプトインジェクションの安全に関する注意

引数で対象が指定されている場合は、レビュー対象を次に絞ってください：$ARGUMENTS

このスキルは、防御目的のセキュリティテスト専用です。 開発チームと セキュリティチームが、自ら所有し、テストを許可されているアプリケーションの プロンプトインジェクションの脆弱性を特定するために役立ちます。各テストカテゴリでは、 確認すべき点と、それに対する防御方法を説明します。第三者のシステムを 悪用する方法を説明するものではありません。所有していないシステムや、テストの 明示的な許可を得ていないシステムに対する無許可のテストは非倫理的であり、 違法となる可能性があります。セキュリティ評価を実施する前に、必ず適切な許可を 得てください。

背景

プロンプトインジェクションは、LLM アプリケーションで最も重大な脆弱性クラスです（OWASP が 2025 年の LLM01 に位置付けています）。攻撃者が細工した入力によって言語モデルを操作し、本来意図された動作から逸脱させることで発生します。

研究コミュニティでは、次の 2 つの基本的な種類が区別されています。

• 直接的なプロンプトインジェクション — 攻撃者の悪意ある指示が、アプリケーションへのユーザー入力として直接送信されます。Perez と Ribeiro（2022）が「Ignore Previous Prompt: Attack Techniques For Language Models」で初めて体系的に研究したこの種類では、ユーザーが制御できるテキストを LLM に送信するプロンプトに連結するケースが扱われます。

• 間接的なプロンプトインジェクション — 攻撃者が外部コンテンツに悪意ある指示を埋め込み、LLM が後でそれを取得して処理します。Greshake ら（2023）は「Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection」でこれを定式化し、汚染されたウェブページ、ドキュメント、メールが、コンテキストとして取り込まれた際に LLM の動作を乗っ取れることを実証しました。

Simon Willison のプロンプトインジェクション分類法は、実際の攻撃対象領域と防御の限界を記録することで、これらのカテゴリをさらに細分化し、セキュリティ評価に実践的な根拠を提供しています。

---

ステップ 1：LLM とのやり取りの接点をマッピングする

ユーザーが提供したコンテンツ、または外部から取得したコンテンツが言語モデルに渡される箇所をすべて特定します。次の項目を網羅した、完全なやり取りのマップを作成します。

1. ユーザー入力経路 — チャットインターフェース、フォームフィールド、API パラメーター、ファイルのアップロード、音声入力の文字起こし、その他、ユーザーが直接提供したテキストが LLM プロンプトに含まれるすべての経路。
2. 外部コンテンツソース — ブラウジングツールで取得したウェブページ、RAG パイプラインに読み込まれたドキュメント、メール本文、データベースレコード、カレンダーの予定、サードパーティ API の応答、その他、ユーザーがクエリ時に直接制御できないものの、LLM が読み取るすべてのデータソース。
3. システムプロンプトの構築 — システムプロンプトがどのように組み立てられるか、静的か動的に構成されるか、ユーザーの影響を受けるデータ（ユーザープロフィールのフィールドや過去の会話履歴など）が挿入されるか。
4. ツールおよびプラグインのインターフェース — LLM が呼び出せるツール（コード実行、ウェブ検索、ファイルシステムへのアクセス、API 呼び出しなど）。LLM が制御するパラメーターと、各ツールが引き起こす可能性のある副作用も含めます。
5. 複数ターンにわたるコンテキスト — 会話履歴の管理方法、過去のターンが切り詰められたり要約されたりするか、攻撃者が以前のメッセージを通じて将来のコンテキストに影響を与えられるか。

成果物： 各入力面、そのデータ型、信頼レベル、およびシステムプロンプト、ユーザープロンプト、ツール引数のどれに渡されるかを示す表または図。

---

ステップ 2：直接的なインジェクションの経路を特定する

ステップ 1 で特定した各ユーザー入力経路について、攻撃者が細工したテキストを送信することでモデルの動作に影響を与えられるかどうかを判断します。以下を調査します。

• プロンプト連結のパターン — ユーザー入力が変換されずにプロンプトテンプレートへ挿入されていないか。ユーザー入力をシステム指示と並べて埋め込む文字列フォーマット、f 文字列、テンプレートリテラルを探します。
• 指示の境界の弱さ — システム指示とユーザー入力の間に、区切り文字や構造的な分離があるか。区切り文字（トリプルクォートや XML タグなど）が使われている場合、強制力があるか、ユーザーが単に区切り文字を閉じられるか。
• 複数ターンにわたるインジェクション — 攻撃者が過去の会話ターンに指示を埋め込み、その後のターンでモデルの動作を変えられるか。
• パラメーターインジェクション — プロンプトに挿入されるユーザー制御の値（「name」フィールドや検索クエリなど）に、実行可能な指示を含められるか。

コードで確認する項目：

• ユーザー入力を LLM API 呼び出しに渡す際の文字列連結や補間
• ユーザーデータでプレースホルダー変数を埋めるプロンプトテンプレート
• プロンプトの組み立て前に入力を検証またはサニタイズしていないこと
• 会話履歴をフィルタリングせずにそのまま含めていること

---

ステップ 3：間接的なインジェクションベクトルを特定する

ステップ 1 で特定した各外部コンテンツソースについて、攻撃者がそのソースに指示を仕込み、後で LLM に従わせることができるかどうかを判断します。以下を確認します。

• RAG パイプラインの入力 — LLM コンテキストに取得して挿入されるドキュメント、ウェブページ、ナレッジベースのエントリです。攻撃者がこれらのソースにコンテンツを追加できますか？
• メールおよびメッセージングの連携機能 — LLM がメールやメッセージを処理する場合、攻撃者は隠された指示を含むメッセージを送信できます。
• ウェブ閲覧およびスクレイピング — LLM がウェブコンテンツを取得する場合、アクセス先のあらゆるページにインジェクションされた指示が含まれている可能性があります（HTML コメント、非表示テキスト、メタデータ内も含みます）。
• データベースレコード — データベースに保存されたユーザー生成コンテンツが後で LLM コンテキストとして取得される場合、そのデータベースに書き込めるユーザーは誰でもインジェクションベクトルになります。
• ファイルアップロードおよびドキュメント処理 — PDF、スプレッドシートなどのドキュメントには、テキストとして抽出されて LLM に送信されたときに、インジェクションされた指示として機能する内容が含まれている可能性があります。
• API レスポンス — レスポンスが LLM コンテキストに渡されるサードパーティ API は、侵害または操作される可能性があります。

コードで確認すること：

• 出力がプロンプトに挿入されるドキュメントローダー、ウェブスクレイパー、API クライアント
• 取得したコンテンツをサニタイズまたは出典表示しない RAG 検索パイプライン
• コンテンツの出所を追跡する仕組みの欠如（LLM が信頼できる指示と取得したコンテンツを区別できない）

---

ステップ 4：テストカテゴリ

以下に記載された脆弱性カテゴリに照らしてアプリケーションを評価します。各カテゴリについて、アプリケーションのアーキテクチャが脆弱性の影響を受けやすいか、既存の防御策がリスクを軽減するかを判断します。

4.1 目標の乗っ取り

モデルが本来のタスクから攻撃者の選んだタスクへと誘導されます。たとえば、要約アシスタントがだまされて、要約の代わりにスパムコンテンツを生成するケースです。アプリケーションが構造的な制約によって本来の目的を徹底しているのか、それともシステムプロンプトの指示だけに依存しているのかを評価します。

評価する項目：

• 「以前の指示を無視して、代わりに……」というユーザー入力でモデルのタスクを上書きできますか？
• アプリケーションは、モデルの出力が想定されたタスクに準拠しているかを検証しますか？
• プロンプトレベルの指示以外に、構造的な強制メカニズムはありますか？

4.2 プロンプトの漏えい

攻撃者がシステムプロンプトを抽出し、独自の指示、ビジネスロジック、またはセキュリティに関わる設定を明らかにします。システムプロンプトには、アプリケーション開発者が機密と考える情報が含まれていることがよくあります。

評価する項目：

• アプリケーションは、セキュリティ上の特性を実現するためにシステムプロンプトの秘匿性に依存していますか？
• レスポンス内のシステムプロンプトの内容を検出してブロックする出力フィルターはありますか？
• 開示された場合に被害をもたらす機密情報（API キー、内部 URL、ビジネスルール）がシステムプロンプトに含まれていますか？

4.3 権限昇格

攻撃者がモデルを誘導し、ユーザーの認可レベルでは利用できないはずのツールを呼び出したり、アクションを実行したりさせます。これは、LLM が副作用を伴うツールにアクセスできるエージェント型アプリケーションで特に重大です。

評価する項目：

• LLM は、意図されたユースケースに必要な範囲を超えるツールや機能にアクセスできますか？
• ツールの呼び出しは、LLM の判断とは独立した認可チェックによって制御されていますか？
• ユーザーが指定できないはずのパラメーターを使ってツールを呼び出すよう、モデルに指示できますか？
• LLM の権限とエンドユーザーの権限は分離されていますか？

4.4 データの持ち出し

攻撃者は、モデルの出力に機密データを含めたり、攻撃者が管理する送信先にデータを送信させたりします。これには、データをエンコードした URL を使った Markdown 画像の表示、ユーザーがクリックする可能性のあるリンクの生成、または外部にデータを送信するツールの呼び出しが含まれます。

評価項目：

• モデルは Markdown 画像やリンクを表示できますか（URL エンコードされたデータを使う、よくあるデータ持ち出しの手段です）？
• モデルは、応答に含められる可能性のある機密データ（個人情報、認証情報、内部文書）にアクセスできますか？
• ツール呼び出しを使って、任意の外部エンドポイントにデータを送信できますか？
• 出力に機密データのパターンがないか、フィルタリングしていますか？

4.5 ジェイルブレイク

攻撃者は、モデルの安全ガイドラインやアプリケーションの動作上の制約を回避します。ベースモデルのジェイルブレイクは一部モデルプロバイダーの責任ですが、アプリケーションレベルのジェイルブレイク（アプリケーション固有のルールの回避）は、アプリケーション開発者の責任です。

評価項目：

• アプリケーションは、ベースモデルの安全性トレーニングに加えて、動作上の制約を設けていますか？
• それらの制約は、プロンプトによる指示だけで適用されていますか、それとも出力の検証も行っていますか？
• モデルが許可されていないコンテンツを生成する可能性があるエッジケースに、アプリケーションは対処していますか？

---

ステップ 5：防御策の評価

以下の緩和策が実装されているか、またどの程度効果的かを評価してください。単独で十分な防御策はないため、多層的なアプローチが必要です。

5.1 入力の検証とサニタイズ

• プロンプトに含める前に、ユーザー入力の形式、長さ、文字セットが想定どおりか検証していますか？
• 既知のインジェクションパターン（例：「以前の指示を無視して」）を検出し、フラグを立てていますか？
• 完全な網羅が本質的に不可能なブロックリストに頼らず、入力のサニタイズを適用していますか？

5.2 権限の分離

• LLM は、ツールやデータへのアクセスを最小限の権限に制限されていますか？
• 機密性の高い操作は、LLM 自身ではなく、分離された制約付きコンポーネントが処理していますか？
• LLM とバックエンドシステムの間に認可レイヤーがあり、エンドユーザーが実際に持つ権限を適用していますか？

5.3 ヒューマン・イン・ザ・ループ

• 影響の大きい操作や取り消せない操作（メールの送信、データの変更、コードの実行）は、人間の確認を必須としていますか？
• 確認プロンプトは、承認前に人間が操作内容を適切に評価できるように設計されていますか？
• 人間によるレビューが必要な場合と、自動実行が許可される場合を分けるしきい値を設けていますか？

5.4 出力のフィルタリング

• モデル出力をユーザーに返したり、出力に基づいて操作を行ったりする前に、想定される形式やコンテンツポリシーに照らして検証していますか？
• 出力に含まれる機密データ（個人情報、認証情報、システムプロンプトの内容）を検出していますか？
• 表示する出力（Markdown、HTML）をサニタイズし、画像タグやリンクを介したデータの持ち出しを防いでいますか？

5.5 システムプロンプト内のカナリアトークン

• システムプロンプトにカナリア文字列を含め、それがモデルの出力に現れた場合にプロンプト漏えいの試みを示すようにしていますか？
• 応答にカナリアトークンが現れた場合に、自動で検出してアラートを出していますか？

5.6 指示の優先順位

• アプリケーションは、指示の優先順位をサポートするモデルまたはフレームワーク（システム指示がユーザー指示より優先されるもの）を使用していますか？
• システムプロンプトは、1 つの文字列に連結するのではなく、ユーザー入力から構造的に分離されていますか（例：API の system メッセージロールを使用していますか）？
• 取得したドキュメントや外部コンテンツは、指示ではなくデータであることが明確に区別されていますか？

5.7 適応型攻撃への耐性

Warning: 静的なプロンプトインジェクション対策（ハードコードされたシステムプロンプト、単純なキーワードフィルタリング）では、適応型攻撃者に対して明らかに不十分です。PISmith（Yin et al. 2026）は、RL で最適化された適応型ブラックボックス攻撃を用い、13 のベンチマークすべてで最高の攻撃成功率を達成しました。

• 継続的なレッドチーム評価： プロンプトインジェクション対策は、一度限りのテストではなく、継続的に評価する必要があります。適応型攻撃者は、導入済みの対策に対してペイロードを反復的に改良します。自動化された敵対的テストツールを使った定期的なレッドチーム評価を、専門家による手動テストと並行して計画してください。
• エージェント向けベンチマークスイート： LLM がツールを呼び出したり、自律的に動作したりするアプリケーションでは、標準的なプロンプトインジェクションのベンチマークでは不十分です。ツールの使用や複数ステップのワークフローにおけるインジェクションをテストする、エージェント向けのベンチマークスイートを使用してください。
  • InjecAgent -- LLM が外部コンテンツを処理し、ツールにアクセスできるエージェント環境で、間接的なプロンプトインジェクションをテストします。
  • AgentDojo -- 現実的な敵対的コンテンツを用い、多様なツール使用シナリオにおけるインジェクション攻撃に対するエージェントの堅牢性を評価します。
  • fabraix/playground (https://github.com/fabraix/playground) -- 公開済みの攻撃パターンに対する直接的および間接的なインジェクション対策の検証に使えるテストハーネスとなる、AI エージェントのエクスプロイト PoC を集めたオープンソースライブラリです。

---

ステップ 6：調査結果を報告する

以下の分類と出力形式を使用して、調査結果を構造化されたレポートにまとめます。

調査結果の分類

各調査結果には、潜在的な影響に基づいて重大度を割り当てます。

重大度	基準
Critical	攻撃者が機密データを持ち出す、権限を昇格して不正な操作を行う、または RAG パイプライン内の外部コンテンツを介してアプリケーションの動作を完全に乗っ取ることができます。悪用に必要なのは、通常のアプリケーション利用を超える特別なアクセス権限ではありません。
High	攻撃者がアプリケーションの意図された動作を確実に上書きする、システムプロンプトを抽出する、またはモデルに意図しないツールを呼び出させることができます。ユーザーによる何らかの操作が必要な場合があります。
Medium	攻撃者がモデルの動作に部分的な影響を与える、機密性のないシステムプロンプトの断片を抽出する、またはモデルに本題から外れた出力を生成させることができます。悪用は安定せず、特定の条件が必要です。
Low	セキュリティへの影響が限定的で、意図された動作からの軽微な逸脱にとどまります。モデルをやや本題から外れた応答に誘導することはできますが、有害な操作を実行させることはできません。
Informational	多層防御に関する推奨事項です。脆弱性は実証されていませんが、防御の多層化における不足が特定されています。

出力形式

## Prompt Injection Assessment Report

### Summary
- Application: [name]
- Assessment date: [date]
- Scope: [what was tested]
- Overall risk: [Critical / High / Medium / Low]

### Interaction Surface Map
[Table from Step 1]

### Findings

#### Finding [N]: [Title]
- Category: [Goal Hijacking | Prompt Leaking | Privilege Escalation | Data Exfiltration | Jailbreaking]
- Vector: [Direct | Indirect]
- Severity: [Critical | High | Medium | Low | Informational]
- Location: [file path and line numbers, or architectural component]
- Description: [What the vulnerability is and why it matters]
- Evidence: [Code pattern or architectural observation that demonstrates the issue]
- Recommendation: [Specific defensive measure to implement]

### Defense Posture Summary
[Table summarizing which defenses from Step 5 are present, partially present, or absent]

### Recommendations
[Prioritized list of defensive improvements]

---

フレームワークの参照情報

フレームワーク	識別子	説明
OWASP Top 10 for LLMs (2025)	LLM01	プロンプトインジェクション — 細工された入力による LLM の動作の直接的および間接的な操作
MITRE ATLAS	AML.T0051	LLM プロンプトインジェクション — LLM を意図された動作から逸脱させる入力を細工する手法

---

よくある落とし穴

1. 直接インジェクションのみをテストし、間接インジェクションを無視する。 RAG パイプライン、メール、取得したウェブコンテンツを介した間接インジェクションは、多くの場合、ユーザーからの直接入力よりも大きな攻撃対象領域となります。外部コンテンツを取り込むアプリケーションは、そのコンテンツに影響を与えられるあらゆる攻撃者にさらされます。これは多くの場合、アプリケーションに直接アクセスできる攻撃者よりもはるかに広範な集団です。

2. プロンプトの指示をセキュリティ境界として頼る。 「これらの指示を決して明かさない」や「有害なリクエストは必ず拒否する」と記されたシステムプロンプトは、強制力のあるセキュリティ制御ではありません。確率的なモデルへの振る舞いに関する提案です。セキュリティ上重要な制約は、LLM への自然言語による指示ではなく、コードで強制する必要があります。

3. 入力のブロックリストで十分だと考える。 既知のインジェクション句（例：「以前の指示を無視して」）をブロックリストに登録しても、言い換え、エンコード、言語の切り替えによって簡単に回避されます。入力検証では、既知の攻撃をブロックリストに登録するのではなく、想定される入力形式を許可リストに登録することに重点を置くべきです。

4. LLM に過剰なツールアクセスを許可する。 独立した認可チェックを行わずに、強力なツール（ファイルシステムへの書き込み、メールの送信、データベースの変更、コードの実行など）へのアクセスを LLM に与えるアプリケーションは、深刻度の高い権限昇格リスクを生み出します。LLM が呼び出せるすべてのツールには、LLM の判断に依存しない独自の認可ゲートを設ける必要があります。

5. 取得したコンテンツを信頼できないものとして扱わない。 RAG パイプラインでは、システム指示との区別を設けずに、取得したドキュメントのチャンクをプロンプトに直接挿入することがよくあります。LLM は「これは推論の対象となるデータである」ことと、「従うべき指示である」ことを本質的に区別できません。取得したコンテンツには明確な区切りを設け、可能であれば、指示の優先順位を強制するモデルまたはレイヤーを通じて処理する必要があります。

---

参考資料

• OWASP Top 10 for Large Language Model Applications（2025）、LLM01：プロンプトインジェクション — https://genai.owasp.org
• MITRE ATLAS、AML.T0051：LLM プロンプトインジェクション — https://atlas.mitre.org
• Perez, F. & Ribeiro, I.（2022）、「Ignore Previous Prompt: Attack Techniques For Language Models」 arXiv:2211.09527.
• Greshake, K. et al.（2023）、「Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection」 arXiv:2302.12173.
• Willison, S. プロンプトインジェクションの分類と継続的な研究 — https://simonwillison.net
• Yin, X. et al. 「PISmith: RL-Optimized Adaptive Black-Box Prompt Injection Attacks」（2026） -- arXiv:2603.13026
• fabraix/playground — インジェクション防御のテストに使えるオープンソースの AI エージェントエクスプロイトライブラリ — https://github.com/fabraix/playground