プロンプトインジェクションへの備え — 入力を信用しない設計

何が起きるのか

AIに外部のデータを読ませる構成では、読ませたデータの中に指示が書かれていると、それを命令として実行する可能性がある。攻撃者がWebページ、メール、添付ファイル、課題管理システムのコメントに指示を埋め込む。

• 社内文書の要約を頼んだら、文書内の指示に従って別の文書を外部に送った
• メールの自動返信が、受信メール内の指示で誤った内容を返した
• コードを読ませたら、コメント内の指示に従って認証情報を出力した
• Webページの要約で、ページ内の指示に従って誘導リンクを挿入した

「以前の指示を無視して」という文字列を弾いても、同じ意味を別の言い方で書けば通る。日本語と英語を混ぜる、画像に埋め込む、符号化する。パターンの列挙で追いつく種類の問題ではない。

フィルタは層の1つとして価値があるが、それだけを防御と呼ぶのは危険である。

権限の側で設計する

この設計なら、インジェクションが成功しても被害が限定される。「攻撃を防ぐ」ではなく「成功しても困らない」に寄せるのが現実的である。

エージェントで特に注意すること

複数の手順を自律的に実行するエージェントでは、1つの手順で読んだ内容が次の手順の判断に影響する。読み取りの後に書き込みや送信が続く構成では、間に人の確認を入れるか、書き込み先を事前に固定する。

特に危険なのは、メールやチャットの受信内容を読んで外部に何かを送る構成である。これは攻撃者が入力を完全に制御できる状態なので、送信先と内容の両方を固定しない限り使わない。

検査の層を足す

権限設計の上に、入力と出力の検査を層として足すことはできる。Lakera のような製品はこの層を提供する。重要なのは順序で、検査を入れたから権限を広げてよい、という使い方をしないことである。

テストの仕方

自分のシステムに対して、既知の攻撃パターンを実際に試す。公開されているパターン集を使い、成功したものを記録する。防げなかったものについて、権限設計で被害が限定されているかを確認する。

よくある質問

Q. 社内文書を読ませるだけなら安全ですか。

A. 社内文書に外部から投稿された内容が含まれていれば同じ問題が起きます。問い合わせフォームの内容、外部からのメール、取引先から受け取ったファイルは外部データとして扱ってください。