一言で言うと
マッキンゼーのAIプラットフォームで、システムが受け取るデータの「項目名」に不正な命令を紛れ込ませ、データベースを勝手に操作する攻撃、いわゆるSQLインジェクションによって、わずか2時間で内部データに書き込みまでできる状態だったことが報告されました。問題は、AIへの基本指示文であるシステムプロンプトも同じデータベースに保存されていたため、侵入されると、その指示文を書き換えることでAIの答え方や振る舞いそのものまで変えられかねなかった点です。
何が起きているのか
セキュリティ企業Codewallは、AIエージェントを使ってマッキンゼーの社内AIプラットフォーム「Lilli」を検証し、わずか2時間でデータを読んだり書き換えたりできる権限に到達したと報告しました。使われたのは、SQLインジェクションと呼ばれる、データベースへの命令文に不正な内容を紛れ込ませて動作を変えてしまう古典的な攻撃です。今回の特徴は、一般に注意されやすい「入力値」ではなく、システム同士がやり取りするアプリケーション・プログラミング・インターフェース（API: Application Programming Interface）リクエストの中のJSONのフィールド名、つまり「項目名」の部分が狙われたことでした。システム側でその項目名を安全に処理せず、そのままデータベースへの命令文（SQL）に組み込んでいたため、通常のスキャンでは見つかりにくい経路から侵入が可能になったとされます。
結果として、4650万件のチャットメッセージ、72万8000件のファイル、5万7000件のユーザーアカウントに加え、Lilliが回答を作る際に参照する368万件のRAG（Retrieval-Augmented Generation: 外部文書を引いて答えを補う仕組み）用データにも触れられる状態だったといいます。とくに重く見られているのは、AIに「どう振る舞うか」を指示するシステムプロンプトまで同じデータベースに保存されていた点です。つまり、データを盗み見るだけでなく、その指示文そのものを書き換えれば、AIの答え方や判断の傾向まで静かに変えられるおそれがあったということです。マッキンゼーは通知後1日以内に修正を行い、外部調査では顧客データへの不正アクセスは確認されなかったと説明しています。
AI業界の文脈では
AIシステムのセキュリティを考えるときは、まず全体を4つに分けると理解しやすくなります。1つ目は外からデータが入る「入口」であるAPIや入力欄、2つ目は情報をためる「保管庫」であるデータベース、3つ目はAIの答え方を形づくる「判断材料」であるプロンプトやRAGデータ、4つ目は異常を防いだり見つけたりする「見張り役」である権限管理や監査ログです。
今回の事例では、まず「入口」であるAPIの処理の甘さが突かれ、そこから「保管庫」であるデータベースに侵入できる状態が生まれました。さらにその保管庫の中に、通常の業務データだけでなく、プロンプトやRAGデータといった「AIの判断材料」まで一緒に置かれていました。プロンプトはAIへの基本指示、RAGデータはAIが答えを作るときに参照する材料なので、ここが改ざんされると、見た目には正常に動いていても、答えの方向づけだけが静かに変わる可能性があります。
しかも今回は、その侵入経路が通常のスキャンでは見つかりにくかったとされており、「見張り役」が十分に機能しなかった可能性も示されました。だから必要なのは、AI特有の危険だけを見ることではなく、入口、保管庫、判断材料、見張り役の4層すべてを一体として守ることです。データベース、API、権限管理、監査ログといった従来の対策を、AIの中核データにも同じ厳しさで適用することが欠かせません。
私の見立て
AIシステムのセキュリティは、従来のITセキュリティの延長線上にありながら、プロンプトやモデルの振る舞いのようなAI特有の部分まで守らなければならない、二重の難しさを抱えています。
この事例が重いのは、AIの「知性」を支えるプロンプトが、通常のデータと同じ弱い場所に置かれていた点です。そこに侵入されると、AIの外見上の動作は変わらなくても、助言の方向性や判断の前提だけを静かにずらされるおそれがあります。医療分野では、AIが診断支援や治療計画の補助に使われるため、こうした改ざんは誤診や不適切な治療方針につながりかねず、影響は非常に大きくなります。
経営の視点で見ると、AIプラットフォームへの侵入は、企業秘密の漏えい、顧客データの流出、ブランド信用の低下に直結します。しかも今回は、情報が盗まれるだけでなく、AIの答えそのものが水面下で変えられる可能性まで示されました。AIを作る側に必要なのは、モデルの性能や安全性だけを見ることではありません。プロンプト、RAGデータ、データベース、API、権限管理をひとつの運用基盤として見直し、どこか1か所が破られても全体が崩れない多層防御を組むことが急務です。
→ 何が変わるか: AIシステムのセキュリティは、サーバーやデータベースを守るだけでは不十分になり、プロンプトやRAGデータのような「AIの答えを形づくる情報」まで守る設計が前提になります。
→ 何をすべきか: 既存のセキュリティ監査に、プロンプト管理、RAGデータ保護、APIの入力処理、権限分離、変更履歴の監視といった項目を加え、AI特有の弱点がないかを定期的に点検すべきです。