- 英国NCSCは、LLMの設計上の理由から、プロンプトインジェクション攻撃は決して完全には軽減されない可能性があると警告
- SQLインジェクションと異なり、LLMには命令とデータの分離がなく、本質的に脆弱
- 開発者はLLMを「混同しやすい代理人」とみなし、侵害された出力の影響を制限するシステム設計を行うべきと提言
プロンプトインジェクション攻撃、つまりユーザーが提供するコンテンツの中に隠れた、あるいは悪意のある指示を埋め込むことで大規模言語モデル（LLM）を操作しようとする試みは、決して適切に軽減されない可能性がある。
これは、英国国家サイバーセキュリティセンター（NCSC）のプラットフォームリサーチ担当テクニカルディレクターであるDavid Cによる見解で、彼はこの手法を評価したブログ記事でこの評価を公表した。記事の中で彼は、多くの人がプロンプトインジェクションをSQLインジェクションと比較しているが、それは不正確であり、前者は根本的に異なり、ある意味ではより危険ですらあると主張している。
両者の主な違いは、LLMが命令とデータの間に実質的な分離を一切設けていないという点にある。
本質的に混同されやすい代理人
「当初はコマンド実行として報告されていましたが、根本的な問題は、古典的なクライアント／サーバーの脆弱性よりもはるかに根深いものであることが判明しました」と彼は記している。「現在の大規模言語モデル（LLM）は、プロンプト内の命令とデータの間にセキュリティ境界を設けていないのです。」
プロンプトインジェクション攻撃は、生成AI（genAI）を利用するシステムで定期的に報告されており、「生成AIおよび大規模言語モデルアプリケーションの開発と保護」を行う際に考慮すべき攻撃として、OWASPの第1位に挙げられている。
古典的な脆弱性では、データと命令は別々に扱われるが、LLMは次のトークンを予測することのみに基づいて動作しており、ユーザーが提供したデータと運用上の命令を本質的に区別することができない。「プロンプトインジェクションが、同じやり方で適切に軽減されることはおそらく決してないでしょう」と彼は付け加えた。
NCSCの担当者はまた、業界は2000年代初頭にSQLインジェクションが十分に理解されておらず、その結果として広く悪用されたときと同じ過ちを繰り返していると主張する。
しかし、SQLインジェクションについては最終的に理解が進み、新たな防御策が標準となった。LLMについては、開発者はLLMを「本質的に混同されやすい代理人」とみなし、そのため侵害された出力の結果を制限するようなシステムを設計すべきだとしている。
アプリケーションが残留リスクを許容できないのであれば、それは単にLLMにとって適切なユースケースではない可能性があると、彼は警告している。
