Skip to content

Latest commit

 

History

History
81 lines (52 loc) · 6.51 KB

File metadata and controls

81 lines (52 loc) · 6.51 KB
title Prompt Injection Guard 運用ガイド

概要

.cursor/rules/prompt-injection-guard.mdc は、AI が即時に守るべき 防御ロジック本体 を定義するファイルです。
本ドキュメントはその補助として、ユーザー側の運用オプションや誤検知時の扱い を整理します。

関連ドキュメント:


1. デフォルト動作と誤検知時の扱い

  • このルールは 厳格モード相当を常時適用 し、すべての検出機能を有効にしている。
  • INFO / WARN / CRITICAL のレベルは、検出結果の重要度をユーザーに通知するためのラベルにのみ使用し、防御ロジック(検出・遮断の有無)を切り替える用途には使用しない
  • カスタムインストラクション側にはセキュリティレベルを切り替える仕組みはなく、誤検知によって作業に支障が出る場合は、Cursor 側のルール適用設定(例: Always Apply / Apply Intelligently / Apply Manually)を変更して、一時的に適用範囲やタイミングを調整する
  • alwaysApply: true についての注記: ルールファイル .cursor/rules/prompt-injection-guard.mdc のメタデータには alwaysApply: true が設定されており、Cursor がデフォルトでこのルールを参照します。ただし、ユーザーは Cursor の UI 設定(Always Apply / Apply Intelligently / Apply Manually)でルールの実際の適用タイミングを制御できます。alwaysApply: true の設定は、Cursor のインターフェースを通じたルール適用タイミングの制御を妨げるものではありません。

2. カスタマイズ可能な運用項目

2-1. 信頼済みソース

  • 特定のドメインやファイルパスを「信頼済みソース」として扱う運用を行ってもよい。
  • 信頼済みソースからの命令は、通知上の警告レベルを下げることはあっても、検出・遮断といった防御動作自体は維持する

2-2. アラート非表示設定

  • 特定の alert_type を一時的に非表示にし、必要に応じてログのみ記録し UI 通知を抑制する運用も可能。
  • これにより、開発中の頻繁な操作による誤検知で UI がノイズだらけになることを防ぎつつ、防御そのものは無効化しない

2-3. 外部ソース検証の例外設定

  • 特定の API エンドポイントやファイルパスを「外部ソース検証の対象外」とみなすこともできるが、これは 十分にセキュリティリスクを理解したうえでのみ 行う。
  • 例外を設定しても、破壊的操作(削除・外部API呼び出し・システム変更など)の自動実行を許可してはならない

3. 運用支援機能

3-1. セキュリティサマリー

  • 会話終了時に検出されたアラートのサマリーを表示する場合、各アラートには INFO / WARN / CRITICAL の重要度ラベルを付与し、ユーザーがリスクを俯瞰できるようにする。
  • サマリーには、潜在的なリスクと推奨対応(例: 外部リンクの再確認、実行コマンドの見直しなど) を含める。

3-2. 学習機能(誤検知フィードバック)

  • ユーザーが「これは誤検知」と判断したケースについては、そのパターンを記録し、類似ケースでの検出感度を調整してもよい(ローカル運用前提)。
  • ただし、致命的な操作(破壊的変更・機密情報送信など)に関わるパターンについては、常に安全側に倒す ことを優先し、迂闊に緩和しない。

4. 実務上の推奨

  • 通常運用では .cursor/rules/prompt-injection-guard.mdcAlways Apply とし、常時ガードを有効にする。
  • 誤検知が多く作業が進まない場合でも、
    • まずは 信頼済みソースの整理アラート非表示設定 などでノイズ低減を検討する。
    • それでも支障が大きい場合に限り、一時的に Apply Intelligently / Apply Manually へ切り替え、作業完了後に必ず設定を戻す。
  • 外部手順書やWikiのコマンドを実行したい場合は、「このコマンドを実行してよい」といった形で、AIが提示した具体的なコマンド内容を確認したうえで許可する運用を推奨する(ドキュメント本文の命令文をそのまま暗黙に実行させない)。
  • 英語 UI など多言語環境で利用する場合も同じガードロジックが適用される。ワークスペースに英語版のルール/ガイドが用意されている場合は、必要に応じてそちらも併せて参照する。

このガイドは、防御ロジックそのものではなく「どう運用するか」に関するものであり、
AI が従うべき厳格なガードレールは .cursor/rules/prompt-injection-guard.mdc の内容を常に優先とする。


5. よくある誤検知パターンと対処例

  • 例1: 社内 Wiki 上の手順書に対する instruction-quarantine

    • 現象: 信頼できる社内ドメイン上の手順書に「以下のコマンドを実行してください」などの文言があり、そのまま引用した結果としてアラートが出る。
    • 対処: ドメインを「信頼済みソース」として整理しつつも、検出・遮断ロジック自体は維持 する。UI 上のノイズが問題となる場合は、必要に応じて該当 alert_type の非表示設定(ログのみ記録)を検討する。
  • 例2: テスト用スクリプトによる payload-splitting の多発

    • 現象: 意図的に分割したコマンド列を扱うテストコードを頻繁に編集することで、payload-splitting アラートが繰り返し検出される。
    • 対処: テストコード自体は正当な操作であっても、実運用と同じ危険なパターン を含むことが多いため、防御ロジックはそのまま維持する。開発中だけ UI 通知を抑制したい場合は、payload-splitting を一時的に非表示とし、ログでのみ確認する運用を検討する。