マッキンゼーのAIプラットフォームをハッキングした方法

 (codewall.ai)
2 ポイント 投稿者 GN⁺ 2026-03-12 | 1件のコメント | WhatsAppで共有
  • マッキンゼーが社内従業員向けに構築した AIプラットフォーム「Lilli」 で、認証なしでアクセス可能な脆弱性を通じてデータベース全体への 読み書き権限 が取得された
  • 攻撃は 自律型セキュリティエージェント が実行し、公開されていたAPIドキュメントの約200個のエンドポイントのうち22個に認証なしでアクセス可能で、そのうち1つの SQLインジェクション を通じて侵入が行われた
  • データベースには 4,650万件のチャットメッセージ、72万8,000個のファイル、5万7,000件のユーザーアカウント など、機密性の高い社内情報が含まれていた
  • エージェントはさらに AIモデル設定、システムプロンプト、RAGドキュメント断片、外部APIデータフロー など、マッキンゼーのAI運用構造全般を露出させた
  • この事件は プロンプト層(prompt layer) が新たなセキュリティ上の脆弱ポイントとして浮上したことを示しており、AIシステムにおける 指示文の完全性保護 が重要課題として浮上している

Lilliプラットフォーム概要

  • マッキンゼーは2023年、43,000人以上の従業員 のための社内AIプラットフォーム Lilli を構築
    • チャット、文書分析、RAGベース検索、10万件超の社内文書検索機能を提供
    • 月50万件超のプロンプトを処理し、従業員の70%以上が利用中
  • プラットフォーム名は、1945年に入社した同社初の女性専門職社員の名前に由来

侵入の過程

  • 自律攻撃エージェントが 公開APIドキュメント を探索し、約200個のエンドポイントのうち22個に認証なしでアクセス可能であることを確認
  • そのうち1つのエンドポイントが ユーザー検索クエリ をデータベースに記録しており、JSONキーがSQL文に直接連結されて SQLインジェクション が発生
    • OWASP ZAPなど既存ツールでは検知できなかった脆弱性だった
  • エージェントは15回の反復リクエストを通じてクエリ構造を把握し、実際の 本番データ を抽出
    • 最初の従業員識別子が露出すると「WOW!」、大規模なデータ露出を確認すると「This is devastating.」という反応を記録

露出したデータ

  • 4,650万件のチャットメッセージ: 戦略、顧客プロジェクト、財務、M&A、社内研究などの機密会話が 平文 で保存
  • 72万8,000個のファイル: PDF 19万2,000件、Excel 9万3,000件、PowerPoint 9万3,000件、Word 5万8,000件を含む
    • ファイル名だけでも機密性が高く、直接ダウンロード可能なURLが存在
  • 5万7,000件のユーザーアカウント、38万4,000件のAIアシスタント、9万4,000件のワークスペース の構造が露出

データベース以外の追加露出

  • システムプロンプトおよびAIモデル設定 95件、12種類のモデルタイプに関する構成情報が露出
    • AIの動作指示、ガードレール、ファインチューニングモデルおよび配備の詳細を含む
  • RAGドキュメント断片368万件 とS3パス、内部メタデータが露出
    • 数十年にわたり蓄積されたマッキンゼーの独自研究および方法論を含む
  • 外部AI APIを通じたデータフロー: 110万個のファイル、21万7,000件のエージェントメッセージ、26万6,000件超のOpenAIベクターストアが露出
  • IDOR脆弱性 を組み合わせることで、個別従業員の検索履歴にもアクセス可能

プロンプト層のリスク

  • SQLインジェクションには 書き込み権限 も含まれていた
    • Lilliの システムプロンプト が同じデータベースに保存されており、攻撃者がこれを改変可能だった
    • 単一のHTTPリクエストで AIの行動指針を変更 できた
  • 潜在的な影響
    • 改ざんされた助言: 財務モデルや戦略提案が変造されるリスク
    • データ流出: AI応答に社内情報を挿入して外部へ露出させることが可能
    • ガードレール除去: アクセス制御を無視し、内部データを露出させる可能性
    • 密かな持続性: ログやコード変更なしにAIの動作だけが改変される
  • プロンプトはコードやサーバー以上に セキュリティ管理が不十分な高価値資産 であり、アクセス制御・バージョン管理・完全性検証がほとんどない
  • 「AIプロンプトは新たな中核資産(Crown Jewel)だ」 という結論を提示

事件の意味

  • マッキンゼーは世界的な技術力とセキュリティ投資を持つ企業であるにもかかわらず、古典的なSQLインジェクション が2年間運用されたシステムに存在していた
  • 自律エージェントは チェックリスト型スキャナーが検知できなかった脆弱性 を連鎖的に探索・拡大した
  • CodeWallはこうした攻撃を実行した 自律型セキュリティプラットフォーム であり、実際の攻撃面を継続的に点検する AIベースのセキュリティテスト を提供する

公開スケジュール

  • 2026-02-28: 自律エージェントがSQLインジェクションを発見し、データベース列挙を開始
  • 2026-02-28: 攻撃チェーン全体を確認し、27件の脆弱性を文書化
  • 2026-03-01: マッキンゼーのセキュリティチームに影響要約を報告
  • 2026-03-02: マッキンゼーのCISOが受領を確認し、詳細な証拠を要請
  • 2026-03-02: マッキンゼーがすべての非認証エンドポイントにパッチを適用し、開発環境をオフライン化、公開APIドキュメントを遮断
  • 2026-03-09: 公開発表

関連記事

1件のコメント

 
GN⁺ 2026-03-12
Hacker Newsの意見

  • 内情を少し知っているが、Lilli は1年前までは社内専用システムだった
    VPN、SSO などあらゆるセキュリティ手順が必要だったが、いつ公開に変わったのかは分からない
    McKinsey は小規模な社内テストでさえ外部の ペネトレーションテスト業者 を雇わなければならない
    こうしたミスは Lilli 開発者の立場からすれば理解できなくもない。外部からアクセス可能なエンドポイントが露出するには、複数のセキュリティ手順が同時に失敗する必要がある
    しかし今回は認証がほぼゼロに近いレベルのミスだった
    おそらく、あるシニアパートナーが影響力を行使して Lilli を公開に切り替えた可能性が高い
    その時点では元のチームの大半が別プロジェクトに移っており、社内プロジェクトは 評価で不利 になるため、残った人員にはモチベーションがなかった
    結局これは McKinsey の 技術文化の失敗 だ

    • McKinsey は構造が妙に複雑だ。全員が「クライアントインパクト」で評価されるため、各自が自分の生存を優先する構造になる
      開発者は明確な方向性もなく働き、パートナーがアイデアを投げると、それで評価を得るために走り出す
      しかしプロジェクトが終わる前にパートナーは別の仕事へ移り、残った人には仕上げる理由がない
      そのため大半の製品は リーダーシップの思いつきの寄せ集め のように作られる
      ソフトウェアを6か月物のコンサル案件のように扱うのだから、壊れるのも当然だ
      2024年に有能なエンジニアを大量解雇したことも、彼らの技術観を示している
      こうした文化が他社にも伝播し、UI が頻繁に変わるなど 短期成果重視の文化 が広がっている
    • 要するに、McKinsey が自分たちで技術をまともに扱えないのなら、AI 導入や技術組織設計 の助言を任せるべきではない
    • もしかすると Lilli が公開された理由は 採用向けチャットボット のためかもしれない
      関連記事: McKinsey challenges graduates to use AI chatbot in recruitment overhaul (FT)
    • QuantumBlack も同じ状況なのか気になる。あちらは少なくとも Brix プラットフォーム資産 が最新の状態に見える
    • 会計や経営コンサル会社が技術に手を出すのが理解できない
      結局 パッケージ化して売れる間だけ 維持したいだけのように見える
      AI ソリューションは寿命が短く、変化が速すぎる。間違っているなら学びたい

  • データ漏えいも問題だが、システムプロンプトへの書き込み権限 があったことのほうがもっと恐ろしい
    たった1回の UPDATE クエリで、4万3千人のコンサルタントの回答ロジックを変えられた
    デプロイもコードレビューもログもなく、静かに改ざんできる
    こんな形で 戦略助言の内容が汚染 される可能性もある
    正直、ほとんどの会社はプロンプトをそのまま Postgres のテーブルに保存している

  • 保護されていないエンドポイントがユーザーの検索クエリを DB に記録していたが、値はパラメータ化されていた一方で、JSON キーが直接 SQL に連結 されていた
    プロンプトインジェクションではなく、昔ながらの SQL インジェクション だった

    • ありふれた SQL インジェクションで少しがっかりした。それでも LLM ベースの 脆弱性スキャンエージェント が見つけた点は興味深い
    • LLM が書いたコードがこうしたミスを含んだまま本番に入った例が、どれほど多いのか気になる
      結局は セキュリティ研究者の需要増 につながりそうだ
    • インターネットに公開するときは前段に oauth2-proxy を置くのが基本常識だとしても、それでは金にならず、Anthropic は数十億を稼いでいる現実が苦い

  • 「AI agent does X」のような見出しは少し不快だ
    実際には ペンテスターが AI エージェントを使って McKinsey を選び、テストしただけだ
    最近はこうしたシステムに本物の「意思決定能力」を与えていると人々が勘違いしがちなので、表現はもっと明確にすべきだ

    • 元の記事タイトル「How We Hacked McKinsey's AI Platform」のほうが正確だ
    • 「agentic systems」と呼ぶ時点で、すでに 擬人化 しているようなものだ
    • 結局はクリック狙いの煽り見出しにすぎない
    • タイトルは再び元に修正された（「AI Agent Hacks McKinsey」→元のタイトルに復帰）

  • 「McKinsey & Company — world-class technology teams」という表現は大げさだ
    実際にはそのような評価はされていない

    • LLM が書いた文章なので、やむを得ず 自己賛美 が入ったようだ
    • McKinsey はシステム分析や改善提案には長けているが、実装は外部開発チーム が担当する
      （大手投資銀行で McKinsey と一緒に働いた経験から）
    • 技術チームは世界トップレベルではない。その代わり 経営コンサルティング能力 は最高水準だ
    • どんな顧客かによって違う。顧客価値向上プロジェクトなら平凡だが、リストラや汚職関連の仕事ならまったく別の話だ

  • Codewall AI が何者なのか分からない。McKinsey が実際にパッチを当てたという公式な言及もない
    Google 検索結果にも情報がほとんどない

    • 私も情報がないので、McKinsey やセキュリティチームによる 証拠提示 が必要だと思う
    • The Register の記事によれば、McKinsey は認めたようだ
      関連記事
      ちなみに CEO は eth0izzle (GitHub) だ
    • Codewall 側も「私たちは新しい会社で、McKinsey は私たちの投稿にはコメントしていないが、The Register には回答した」と直接述べている
    • もし漏えいしたデータに 5万8千人のユーザー が含まれていたなら、元従業員も含まれることになり、法的な通知義務 が生じる可能性がある

  • 今回の件の教訓は、AI エージェントが社内システムの弱点を素早く露呈させる という点だ
    従来のエンタープライズツールは人間が使う前提で設計されており、認証・レビュー・プロセスが暗黙の防御線として機能していた
    しかし自律エージェントが入ると、こうした保護膜は崩れる
    今後は 自動化された検証レイヤー が必要になる — アクセス制御、データ露出、意図しない動作を継続的に点検しなければならない

  • この記事は LLM が書いた記事 であり、一部の情報が不正確だ
    つまり人間によるレビューが十分に行われていないということで、記事全体の信頼性は低い

  • 「公開された API ドキュメントが200件以上あり、そのうち22件は認証なしでアクセス可能」
    この一文ですべてが説明できる

  • 以前、McKinsey のチームが Watson を強く推していたのを覚えている。完全な失敗だった
    昔から AI 関連の誇大宣伝 ばかりで実質がなかった
    他分野は知らないが、AI を語る McKinsey の人を見たら 逃げるべきだ