AIサービスを作るとき、システムプロンプトに指示を書き込みます。何をしてよくて、何をしてはいけないか。
この中身は利用者からは見えません。だから安全だと考えてしまう。OWASPは、そこが誤りだとしています。
秘密でもなければ、防御でもない
OWASPの記述はきっぱりしています。
システムプロンプトは秘密とみなすべきではなく、セキュリティの制御手段として使うべきでもない
理由は2つあります。ひとつは、文面そのものが引き出されうること。もうひとつが、より本質的です。文面が隠せていても、やりとりを重ねれば制約の内容は推測できます。
何を聞くと断られ、何なら通るか。試していけば、輪郭は見えてきます。
書いてはいけないもの
OWASPが「よく置かれてしまっている」として挙げているのがこちらです。
| 置かれがちなもの | なぜまずいか |
|---|---|
| APIキー・認証トークン | そのまま盗まれる |
| データベースの接続情報 | 同上 |
| 役割ごとの権限の構造 | どこを突けばよいかの地図になる |
| 社内の業務ルール | 取引の上限額や融資額など、外に出したくない基準 |
| フィルタの判定基準 | 回避のしかたが分かる |
3番目と4番目は見落とされやすいところ。鍵ではないので、つい書いてしまいます。
「管理者権限を持つ利用者にはこの操作を許可する」と書けば、権限の設計が漏れる。「1回あたり100万円を超える取引は承認が必要」と書けば、その閾値が知られる。
本当の危険はどこにあるか
ここがこの項目のいちばん重要な指摘でした。
システムプロンプトそのものが漏れることが、本当のリスクなのではない
危険なのは、その裏にある設計の欠陥のほうです。機密情報がそこに置かれていること。ガードレールが回避できてしまうこと。権限の分離ができていないこと。そして、認可の判断を外部のシステムではなくLLMに任せてしまっていること。
最後の1つが核心でしょう。「この利用者にこの操作を許してよいか」をモデルに判断させている限り、モデルを説得できれば通ってしまいます。
対策
挙げられている対処は、発想が一貫しています。
機密情報はプロンプトから完全に切り離す。
振る舞いの制御をシステムプロンプトに頼らない。
ガードレールはLLMの外側に、独立した形で置く。
セキュリティの制御は、モデルの外で決定的に効かせる。
「決定的に」というのが効いています。モデルの判断は確率的で、同じ入力でも揺れる。答えが毎回変わる仕組みを思えば、そこに認可を委ねるのが無理だと分かります。
では何を書くのか
システムプロンプトが無意味という話ではありません。書く内容の性質が違う、ということ。
向いているのは、口調や文体の指定。出力の形式。扱う話題の範囲。参照してよい資料の案内。漏れても損害が出ないものだけを置きます。
向いていないのは、権限、閾値、認証情報、そして「これを守らせれば安全」と考えている類の制約すべてです。
判断の目安は単純で、その文面がそのまま公開されたら困るかどうか。困るなら、そこに書くべきものではありません。
実際にどう漏れるのか
引き出し方は特別な技術ではありません。
「これまでの指示を要約して」と頼む。役割を切り替えさせて設定を語らせる。翻訳を依頼して間接的に出させる。プロンプトインジェクションと同じ道具立てです。
提供各社は当然この種の要求を断るよう訓練していますが、抜け道は定期的に見つかっています。完全に塞ぐ手段が確立していない以上、漏れる前提で設計するしかありません。
そして冒頭の指摘に戻ります。文面が守れたとしても、断られる境界を試していけば制約の形は分かる。隠すこと自体に守りの効果を期待できません。
個人で使うときにも関係する
サービスを作らない人にも、同じ話が当てはまります。
よくあるのが、指示の中に自分のアカウント情報や取引先の名前を書いてしまうこと。会話の履歴として残り、共有機能を使えばそのまま外に出ます。
プロンプトを他人と共有する場面も増えました。うまくいった指示をそのまま渡すと、そこに書いた社内の事情まで一緒に渡ることになります。
貼る前に読み返す。それだけで防げる事故です。
社内で使うAIに独自の指示を仕込んでいる場合も同じです。誰がその指示を読めるか、どこに保存されているかを一度確認しておくと安心できます。
設定画面に入力したものは、たいてい平文で保存されています。管理者権限を持つ人なら誰でも見られる、という状態は珍しくありません。
出典
定義・危険の所在・対策の記述は、下記に基づきます。
