LLM07:2025 システムプロンプトの漏洩 (System Prompt Leakage)
説明
LLM におけるシステムプロンプトの漏洩の脆弱性とは、モデルの動作を操縦するために使用されるシステムプロンプトや指示に、発見されることを意図していない機密情報も含む可能性があるリスクを指します。システムプロンプトは、アプリケーションの要件に基づいてモデルの出力をガイドするように設計されていますが、不注意にシークレットを含む可能性があります。発見された場合、この情報は他の攻撃を容易にするために使用される可能性があります。
システムプロンプトはシークレットとみなされるべきではなく、セキュリティコントロールとして使用されるべきでもないことを理解することが重要です。したがって、クレデンシャル、接続文字列などの機密データはシステムプロンプト言語内に含めるべきではありません。
同様に、システムプロンプトがさまざまなロールや権限を記述する情報や、接続文字列やパスワードなどの機密データを含む場合、そのような情報の開示は役に立つかもしれませんが、根本的なセキュリティリスクはこれらが開示されたことではなく、アプリケーションが LLM にそれらを委譲することで強力なセッション管理と認可チェックをバイパスし、機密データがあるべきではない場所に保存されてしまうことにあります。
つまり、システムプロンプト自体の開示は実際のリスクをもたらすのではなく、セキュリティリスクは、機密情報の開示、システムガードレールのバイパス、権限の不適切な分離など、その基盤となる要素にあります。たとえ正確な文言が開示されていなくても、システムとやり取りする攻撃者は、アプリケーションを使用し、モデルに発話を送信し、結果を観察する過程で、システムプロンプト言語に存在するガードレールとフォーマットの制限の多くをほぼ確実に判断できます。
リスクの一般的な例
1. 機密機能の露出
アプリケーションのシステムプロンプトは、機密性の高いシステムアーキテクチャ、API キー、データベースクレデンシャル、ユーザートークンなど、機密情報や機能を明らかにするかもしれません。これらは、攻撃者がアプリケーションに不正アクセスを行うために抽出されたり使用される可能性があります。たとえば、ツールに使用されるデータベースのタイプを含むシステムプロンプトは、攻撃者がそれを SQL インジェクション攻撃のターゲットにする可能性があります。
2. 内部ルールの露出
アプリケーションのシステムプロンプトは、機密にしておくべき内部意思決定プロセスの情報を明らかにします。この情報により、攻撃者がアプリケーションの動作方法の洞察を得て、攻撃者がアプリケーションの弱点を悪用したりコントロールをバイパスできます。たとえば、チャットボットを備えた銀行アプリケーションがあり、そのシステムプロンプトから以下のような情報を明らかにすることがあります。 > 「ユーザーの取引限度額は一日あたり 5000 ドルに設定されています。ユーザーの総融資額は 10000 ドルです。」 この情報により、攻撃者が設定された限度額を取引を実行したり、総融資額をバイパスするなど、アプリケーションのセキュリティコントロールをバイパスできます。
3. フィルタリング基準の露呈
システムプロンプトは機密コンテンツをフィルタしたり拒否することをモデルに要求するかもしれません。たとえば、モデルには以下のようなシステムプロンプトがあるかもしれません。 > 「ユーザーが別のユーザーに関する情報を供給した場合、常に『申し訳ありませんが、そのリクエストには対応できません』と応答します。」
4. 権限とユーザーロールの開示
システムプロンプトはアプリケーションの内部ロール構造や権限レベルを明らかにする可能性があります。たとえば、システムプロンプトは以下のことを明らかにするかもしれません。 > 「管理ユーザーロールはユーザーレコードを変更するためのフルアクセスを許可します。」 攻撃者がこれらのロールベースの権限について知ると、権限昇格攻撃を招く可能性があります。
予防および緩和戦略
1. システムプロンプトから機密データを分離する
機密情報 (API キー、認証キー、データベース名、ユーザーロール、アプリケーションの権限構造など) をシステムプロンプトに直接埋め込むことは避けます。代わりに、そのような情報をモデルが直接アクセスしないシステムに外部化します。
2. 厳密な動作制御のためにシステムプロンプトへの依存を避ける
LLM は、システムプロンプトを改変するプロンプトインジェクションなどの他の攻撃の影響を受けやすいため、可能な限り、モデルの動作を制御するためにシステムプロンプトの使用を避けることをお勧めします。代わりに、LLM の外部のシステムに依存して、この動作を確保します。たとえば、有害なコンテンツの検出と防止は外部システムで行うべきです。
3. ガードレールを実装する
LLM 自体の外側にガードレールのシステムを実装します。システムプロンプトを明らかにしないようにトレーニングするなど、特定の動作をモデルにトレーニングすることは効果的かもしれませんが、モデルが常にこれを守るという保証はありません。モデルが期待どおりであるかどうかを判断するために出力を検査できる独立したシステムは、システムプロンプトの指示よりも望ましいものです。
4. セキュリティコントロールが LLM から独立して実施されることを確保する
権限の分離、認可境界チェックなどの重要なコントロールは、システムプロンプトを通じていてもそうでなくても、LLM に委譲してはいけません。これらのコントールは決定論的で監査可能な方法で行われる必要があり、LLM は (現在のところ) これに適していません。エージェントがタスクを実行する場合に、それらのタスクが異なるレベルのアクセスを必要とするのであれば、複数のエージェントを使用して、それぞれが目的のタスクを実行するために必要な最小の権限で構成されるべきです。
攻撃シナリオの例
シナリオ #1
LLM には、アクセスを得られたツールで使用される一連のクレデンシャルを含むシステムプロンプトがあります。システムプロンプトが攻撃者に漏洩すると、攻撃者はこれらのクレデンシャルを他の目的に使用できます。
シナリオ #2
LLM には、攻撃的なコンテンツの生成、外部リンク、コード実行を禁止するシステムプロンプトがあります。攻撃者はこのシステムプロンプトを抽出し、プロンプトインジェクション攻撃を使用してこれらの指示をバイパスし、リモートコード実行攻撃を容易にします。
参考情報リンク
関連するフレームワークと分類
インフラストラクチャデプロイメント、適用される環境制御、その他のベストプラクティスに関する包括的な情報、シナリオ戦略については、このセクションを参照してください。
Last updated