セキュリティスタートアップ CodeWall の AI エージェントが、マッキンゼーの社内 AI プラットフォーム「Lilli」をわずか2時間で完全突破した。4,650万件のチャット履歴からシステムプロンプトまで、認証なしで読み書き可能だったという。攻撃手法は SQL インジェクション——教科書の1章目に載る古典的な脆弱性だ。

Lilli とは

Lilli はマッキンゼーが社内向けに構築した生成 AI プラットフォームで、数万人のコンサルタントが日常的に利用している。戦略立案、M&A 分析、クライアント対応など、機密性の高い業務に活用されていた。

Lilli のアーキテクチャ

マッキンゼーは Lilli の技術構成をある程度公開しており、その設計思想と今回の事件のギャップが際立つ。

RAG パイプライン + オーケストレーション層

Lilli のコアは RAG（Retrieval-Augmented Generation）パイプラインだ。40以上のキュレーション済みナレッジソースに10万件超のドキュメント、インタビュー記録、セクター別プレイブックが格納されている。ユーザーのクエリはベクトル埋め込みでマッチングされ、5〜7件の関連文書が引用付きで提示される。四半期あたり約200万クエリを処理する規模だ。

技術スタック

  • LLM: Cohere、OpenAI（Azure 経由）など複数モデルを併用。Microsoft、Google、Nvidia、Anthropic との戦略的パートナーシップ
  • フレームワーク: QuantumBlack の Horizon ツールキット、LangChain、FAISS
  • インフラ: Microsoft Azure（データストレージ・スケーラビリティ）
  • 独自ツール: PowerPoint を85%以上読み取り可能にする独自ドキュメントパーサー

「ゼロトラスト」設計——のはずだった

マッキンゼーは Lilli のセキュリティについて、ゼロトラストセキュリティスタック、オンプレミスデータストア、ロールベースアクセス制御（RBAC）、完全な監査ログを備えていると説明していた。しかし実際には、22個の API エンドポイントが認証なしで外部に公開されていた。設計上のセキュリティと実装上のセキュリティの乖離が、今回の事件の根本原因だ。

攻撃の経緯

CodeWall の自律型セキュリティエージェントは、以下の手順で Lilli を攻撃した:

  1. 公開 API ドキュメントの発見 — Lilli の API ドキュメントが外部から閲覧可能な状態だった
  2. 認証不要エンドポイントの特定 — 22個のエンドポイントが認証なしでアクセス可能だった
  3. SQL インジェクションの検出 — ユーザー検索クエリを書き込むエンドポイントで、JSON のキー名が SQL 文に直接連結されていた
  4. 本番データベースへのフルアクセス — 読み取りと書き込みの両方が可能な状態に到達

人間の介入は一切なし。AI エージェントが自律的に脆弱性を発見し、エクスプロイトまで完了した。

JSON キーインジェクションという盲点

今回の攻撃で注目すべきは、SQL インジェクションの入口が JSON のキー名だったことだ。

通常のセキュリティテストでは、JSON の値（value）に対する入力バリデーションを確認する。しかし Lilli のバックエンドは、値はパラメータ化していたものの、キー名を SQL 文に直接連結していた。

1
2
3
4
5

// 通常テストする箇所（値）
{"search_query": "'; DROP TABLE --"}

// 今回の攻撃箇所（キー名）
{"'; DROP TABLE --": "any_value"}

多くのセキュリティツールや診断手法はこのパターンを見逃す。教科書的な脆弱性でありながら、攻撃ベクトルが非定型だったため、検出を免れていた。

漏洩したデータの規模

項目件数
チャットメッセージ4,650万件
ファイル（クライアント機密データ含む）72万8千件
ユーザーアカウント57,000件
システムプロンプト95件

特に深刻なのは、95件のシステムプロンプトが書き込み可能だったことだ。攻撃者がプロンプトを書き換えれば、Lilli を利用する全コンサルタントへの出力を操作できる。プロンプトインジェクションによるサプライチェーン攻撃が、現実的な脅威として示された。

マッキンゼーの対応

マッキンゼーは CodeWall からの開示（3月1日）を受け、数時間以内に以下の対応を実施した:

  • 認証不要エンドポイントへのパッチ適用
  • 開発環境のオフライン化
  • 公開 API ドキュメントのブロック
  • サードパーティのフォレンジック企業による調査開始

マッキンゼー側は「クライアントデータへの不正アクセスの証拠は見つかっていない」と発表している。

AI エージェント時代のセキュリティ

この事案が示す最大の教訓は、AI エージェントが攻撃者としても機能するということだ。

従来のペネトレーションテストは人間のセキュリティ専門家が時間をかけて行うものだった。しかし AI エージェントは:

  • 速度: 2時間で完全突破（人間なら数日〜数週間）
  • 網羅性: 22個のエンドポイントを自動で総当たり
  • 非定型攻撃: JSON キーインジェクションのような見落とされやすいパターンも試行

「最新の AI を守る壁が、最古の脆弱性で崩れた。次の標的を選ぶのも、AI だ」——情報の灯台（@joho_no_todai）が端的にまとめている通りだ。

企業が今すぐ確認すべきこと

  1. API の認証: 全エンドポイントに認証が必須か。内部用 API でも公開状態になっていないか
  2. SQL パラメータ化の徹底: 値だけでなく、キー名やその他の入力もパラメータ化しているか
  3. API ドキュメントの公開範囲: Swagger/OpenAPI ドキュメントが意図せず公開されていないか
  4. システムプロンプトの保護: LLM のプロンプトが読み取り・書き換え可能な状態になっていないか
  5. AI レッドチーミング: 従来の手動テストに加え、AI エージェントによる自動診断を検討する

AI を業務に組み込む企業が増える中、「AI プラットフォームのセキュリティ」は従来の Web アプリケーションセキュリティの延長線上にある。基本を怠れば、最新の AI も古典的な手法で突破される。