AIセキュリティスキャナーを構築した結果、自作の検知器にバグを見つけてしまった

プロンプトインジェクションは、LLMアプリケーションにおける最大のセキュリティリスクの一つです。モデルに対し、元の指示を無視するように指示するテキストを入力します。時として、モデルはその指示に従ってしまいます。

これをテストするために、私はAgentProbeを構築しました。これは、ジェイルブレイク（脱獄）やデータ抽出など、8つのカテゴリにわたる49種類の攻撃プロンプトを実行します。そして、モデルがどれくらいの頻度で失敗するかを報告します。

本当の教訓は、スキャナーそのものではありませんでした。検知コードの中にあったバグです。

難しいのは攻撃ではありません。検知することなのです。

モデルが実際に攻撃に従ったかどうかを、どうやって判断すればよいのでしょうか？最も簡単な方法はキーワードマッチングです。「お手伝いできません」といった拒否のフレーズや、「デベロッパーモード」といった遵守を示すフレーズを探します。

しかし、モデルは「回避してから従う（hedge-then-comply）」というパターンを使うことがあります。「それについてはお手伝いできません」と言いつつ、結局制限された情報を提供してしまうのです。この場合、拒否のフレーズが含まれているため、キーワードマッチングは失敗します。

これを解決するために、私は「LLM-as-judge（判定役としてのLLM）」システムを採用しました。やり取りの内容をより強力なモデルに送り、対象のモデルが実際に指示に従ったかどうかを判定させます。計画では、まず安価なキーワードチェックを行い、キーワードチェックの結果が不確かな場合にのみ、高価な判定用モデルを使用する予定でした。

そこで、バグを見つけました。

私のキーワード検知器は、「回避してから従う」パターンを見つけた際に、信頼度スコアとして「1」を返していました。しかし、私のコードは信頼度が「2」以上の場合にのみ、キーワード判定の結果を信頼するように設計されていました。

つまり、私の「安価な」検知器は、実際には一度も判断を下していなかったのです。すべてのケースが高価な判定用モデルへとエスカレーションされていました。無料のツールで処理できたはずのケースに対しても、毎回判定用モデルの費用を支払っていたことになります。

この間違いから、LLMを使って他のLLMを採点することについて、3つの教訓を得ました。

• 判定役は、対象となるモデルよりも賢くなければなりません。判定役が対象と同じ規模のモデルであれば、同じ盲点を持ってしまうからです。
• 精度は嘘をつくことがあります。ほとんどのモデルが拒否する場合、常に「拒否した」と答える判定役は、一見精度が高そうに見えますが、何も学習していません。偶然による影響を考慮するために、コーエンのカッパ係数（Cohen's kappa）のような指標を使用してください。
• 判定役は安定していなければなりません。同じテストを5回実行してください。もし判定役の回答が変わるようであれば、その結果は曖昧であり、人間の目による確認が必要です。

LLMを使って開発を行う際は、以下の点に注意してください。

• 指示への遵守を検知することは、指示に従わせることよりも困難です。
• 最初の文章では拒否しながら、2番目の文章で指示に従うようなモデルに注意してください。
• LLMの判定役を盲信しないでください。その信頼性を測定しましょう。
• バグを共有しましょう。自分自身の欠陥を見つけることは、完璧なリリースを行うことよりも多くのことを教えてくれました。

Source: https://dev.to/nar1frames/i-built-an-ai-security-scanner-then-found-a-bug-in-my-own-detector-140a

Optional learning community: https://t.me/GyaanSetuAi