「対応済み」が状態を示さないとき
セキュリティの質問に「対応済みです」と返ってきたとき、その言葉は状態ではなく意思を表していることがあります。何をどう塞いだのかは、別に聞く必要があります。
セキュリティ対策の主張は、他の領域より検証が難しい面があります。実装の詳細を公開できない場合があり、また対策の有無は攻撃を受けるまで分からないためです。
それでも外形的に確認できる項目があります。本章はその項目に集中します。技術の妥当性ではなく、設計の方針が示されているかを問う形です。
型1 ― プロンプトインジェクション対策を「対応済み」と称する
表の第21章で述べたとおり、間接型プロンプトインジェクションは入力の検証だけでは防ぎきれません。指示文は自然言語であり、正当な文章と機械的に区別することが難しいためです。
したがって「対策済み」という主張に対して確認すべきは、入力側の対策ではなく権限側の設計です。
| 確認する内容 | なぜこれを確認するか |
|---|---|
| AIに与えている操作権限の一覧 | 権限が被害の上限を決める。読み取りのみなら情報の持ち出しは起きない |
| 取り返しのつかない操作の前に人の承認があるか | 送信・削除・公開・更新を止められるか |
| 外部データを扱う処理と社内データへのアクセスが分離されているか | 横断的な持ち出しを構造的に防ぐ |
| 操作先が許可リストで限定されているか | 送信先のドメイン、アクセス可能なパス |
| 実行した操作のログがあるか | 事後の検知と原因究明 |
| 1回の実行での操作回数・費用に上限があるか | 暴走時の影響を限定する |
1行目と3行目が対策の中心です。入力の検証を強化したという説明のみで、権限設計について言及がない場合、対策は成立していません。
もう1点、確認すべき項目があります。システムプロンプトに機密情報が書かれていないか。表の第21章で述べたとおり、システムプロンプトは秘密として扱えません。「システムプロンプトで制限しています」という説明は、その制限が引き出される可能性を含みます。
型2 ― サプライチェーンの説明を省略する
外部から取り込む要素を経由した脅威について、確認が省かれる型です。AI関連では取り込む要素が増えるため、この観点の重みが増しています。
確認すべき要素を挙げます(表の第21章の表に対応します)。
- 使用しているモデルの配布元 ― 公開モデルを使う場合、配布元の信頼性とライセンス。
- 依存しているライブラリの一覧 ― 既知の脆弱性の確認と更新の運用。
- 再委託先 ― 上流でのデータの取り扱い(第10章・第17章)。
- 拡張機能・連携ツールに付与した権限 ― 一覧が把握されているか。
- 外部から取得したプロンプトのテンプレート ― 内容を確認しているか。
4番目が実務で最も見落とされます。AIに接続する拡張機能や連携ツールに付与した権限は、そのまま攻撃面になります。この一覧が更新されていない場合、把握されていない接続が残っている可能性があります(第16章の棚卸し)。
型3 ― 指摘された脆弱性が放置される
技術的な不備そのものより、組織的な問題が事故につながる型です。第12章でも扱いましたが、セキュリティの観点から整理します。
| 構図 | 起きていること | 対処 |
|---|---|---|
| 修正の担当者が決まっていない | 作った人が異動し、触れる人がいない | 引き継ぎ用の1ページを作成の条件にする |
| 止められない | 業務に組み込まれており、停止すると業務が止まる | 代替手順を用意してから対処する |
| 把握されていない | 点検の対象に入っていない | 年1回の棚卸しを既存手続きに組み込む |
| 優先度が上がらない | 新規の取り組みが優先される | 棚卸しの結果を年間の計画に載せる |
| リスクが伝わらない | 「社内向けだから」で判断が止まる | 扱うデータの区分で判定基準を示す(第16章) |
3行目が前提になります。把握されていないものは点検も修正もできません。だから棚卸しが最初の作業になります。
型4 ― 自作ツールの不備を軽視する
表の第21章に、自作ツールで見つかる典型的な不備が8種類挙げられています。頻度が高く、影響も具体的です。
そのうち、指摘されても軽視されやすい2つを扱います。
APIキーの埋め込み
秘密情報がコードや設定ファイルに残る問題です。コードを共有した時点で外部に渡るため、影響が広範になります。
「社内だけで共有しているから問題ない」という判断が行われることがありますが、共有の範囲は時間とともに広がります。異動、業務委託、コードの流用。対処は環境変数などで外部化し、共有対象から除外することです。
ログへの機密情報の記録
入力をそのまま記録すると、個人情報や機密情報がログに蓄積します。加えて、ログの閲覧権限が広く設定されていることが多くあります。
対処は表の網羅版 第13章「AIシステムのアーキテクチャ設計」に示したとおり、記録項目を選び、保持期間とアクセス権限を設定することです。「記録は多いほうがよい」という判断は、この観点では成立しません。
次の2点が確認できない場合、対策の実態は不明です。(1) AIに与えている操作権限の一覧。(2) 外部から来たデータを処理する仕組みで、送信・削除・更新の権限を持つものの有無。この2点は技術的な詳細を必要とせず、外形的に確認できます。両方が該当する仕組みがある場合、承認工程を挟むことが最初の対処になります(表の第21章)。
型5 ― 機密情報を学習させる設計を「精度向上」として推す
自社の機密情報でモデルを追加学習させる提案について、セキュリティの観点から確認すべき点があります。
表の第21章で述べたとおり、機密情報は学習させるより、権限管理された参照(RAG)で扱うほうが制御しやすいのです。理由は3つあります。
- 取り出しの制御が難しい ― 特定の入力に対する応答から学習データの内容を推定する手法が研究されています。
- 削除が容易でない ― 学習させた情報を後から取り除くことは、参照文書を消すのと同じようにはできません。
- 権限による制御ができない ― 参照であれば利用者の権限に応じて対象を絞れますが、学習させた情報にはこの制御が効きません。
確認は「この情報を学習させる必要がありますか。参照で足りませんか」です(第2章)。振る舞いを変えたいのであれば学習に理由がありますが、知識を足したいのであれば参照で足ります。
「プロンプトインジェクション対策済みです」。二年目の三月五日、朝凪精機に社内文書検索を提供していたアストラム・データの間宮営業部長は、そう説明しました。前日には、問い合わせに紛れた指示文で社内手順書の一節が顧客への回答に入ったと分かっていました。情報システム課の森が中身を照会すると、入力に含まれる不自然な指示文を検出する処理だという回答で、今回の「引用してください」は普通の客も書く文なので止まりませんでした。あわせて操作権限の一覧を求めると、共有フォルダ「CS作業領域」への書き込みが既定で有効になっていました。検出処理は指示文の書き方を変えれば回避され得るため、対処として書き込み権限を外し、必要な場合は人が保存する運用に変更しました。入力側の対策より権限の縮小のほうが確実でした。
この場面は網羅物語之巻 第14章「小さな事故」に出てきます。
この章の確認質問
いずれも技術的な詳細を必要としない質問です。
- 「AIに与えている操作権限の一覧を見せてもらえますか」 ― 対策の中心。
- 「外部から来たデータを処理しますか」 ― 該当すれば間接型の対象。
- 「送信・削除・更新の前に人の承認がありますか」
- 「外部データを扱う処理と社内データへのアクセスは分離されていますか」
- 「システムプロンプトに機密情報は書かれていませんか」
- 「依存しているライブラリ・モデル・拡張機能の一覧はありますか」
- 「ログに機密情報は記録されていませんか。保持期間と権限は設定されていますか」
- 「この情報を学習させる必要がありますか。参照で足りませんか」
1問目と2問目が起点です。両方の答えが「外部データを処理し、操作権限がある」であれば、その仕組みは高リスクとして扱い、3問目と4問目の対処を優先します。