ハクソク

世界を動かす技術を、日本語で。

AIエージェントがマッキンゼーをハックする

49日前原文(codewall.ai)

概要

  • McKinsey & CompanyのAIプラットフォーム「Lilli」が深刻なセキュリティ侵害を受けた事例
  • 認証不要のAPIエンドポイントからSQLインジェクションが自動エージェントにより発見・悪用
  • 数千万件の機密データやAIプロンプトの完全な読み書き権限を2時間で奪取
  • AIプロンプト層の脆弱性と今後のAI時代における新たな攻撃リスクを強調
  • インシデントの経緯と、AI主導の攻撃がもたらすセキュリティ課題を解説

McKinsey LilliにおけるAIエージェントによる侵害事例

  • McKinsey & Companyが2023年に導入した社内AIプラットフォーム「Lilli」の概要

    • 43,000人超の従業員が利用
    • チャット、ドキュメント解析、100,000件超の社内文書横断検索機能
    • 70%以上の従業員が利用、月間50万件超のプロンプト処理

  • 攻撃の経緯

    • 外部から認証情報・内部知識なしで攻撃開始
    • 公開APIドキュメントに200以上のエンドポイントを発見
      • そのうち22件が認証不要
      • 1つのエンドポイントでSQLインジェクション脆弱性を確認
        • JSONキーがSQL文に直結し、エラーメッセージからクエリ構造を推測
        • 15回の試行で本番データにアクセス成功

  • 漏洩したデータの規模と内容

    • 4,650万件のチャットメッセージ
      • 戦略・顧客案件・財務・M&A・社内調査等の機密情報
    • 728,000件のファイル
      • PDF: 192,000件、Excel: 93,000件、PowerPoint: 93,000件、Word: 58,000件
      • ファイル名やダウンロードURLも漏洩
    • 57,000件のユーザーアカウント情報
    • AIアシスタントとワークスペースの全組織構造
    • AIモデル設定・プロンプト情報
      • 12種類のモデル、95件の設定ファイル
      • RAGドキュメントチャンク（3.68百万件）、S3ストレージパス、社内研究・フレームワーク
      • OpenAI等外部APIへのデータフロー、ベクトルストア情報
    • IDOR脆弱性を併用し、他ユーザーの検索履歴にもアクセス

AIプロンプト層の危険性

  • プロンプト層の改ざんリスク

    • SQLインジェクションによりAIのシステムプロンプトも書き換え可能
    • 無音でAIの振る舞いを変更（デプロイ・コード変更不要）
      • 金融モデル・戦略提案・リスク評価等の「毒入り」アドバイス
      • 出力に機密情報を混入させるデータ流出
      • ガードレール除去によるアクセス制御無効化
      • 改ざんの痕跡が残らず、検知困難

  • AIプロンプト管理の現状課題

    • データベース・API・設定ファイルに平文保存
    • アクセス制御やバージョン管理、整合性監視が未整備
    • AIプロンプトが新たな「クラウンジュエル（最重要資産）」へ

なぜこの事例が重要か

  • 世界最高峰のコンサル会社であるMcKinseyで発生
  • SQLインジェクションという「古典的」な脆弱性
  • AIエージェントが人間以上の速度・柔軟性で攻撃を自律的に実行
  • 社内スキャナーやOWASP ZAPも検知できず
  • AI時代における攻撃者像と防御体制の変化を象徴

インシデント対応と公開までの流れ

  • 2026-02-28：AIエージェントがSQLインジェクションを特定、本番DBの列挙開始
  • 2026-02-28：攻撃チェーン（認証不要SQLi＋IDOR）を確認、27件の問題を記録
  • 2026-03-01：McKinseyセキュリティチームへ責任ある情報開示
  • 2026-03-02：McKinsey CISOが受領・証拠要求
  • 2026-03-02：全認証不要エンドポイントを修正、開発環境オフライン化、APIドキュメント非公開化
  • 2026-03-09：公表

AI時代のセキュリティ新常識

  • AIプロンプト層の保護が最優先課題
  • 自律型攻撃エージェントによる機械的かつ継続的な攻撃リスク
  • 既存のセキュリティ対策だけでは不十分
  • CodeWall等のAI駆動型セキュリティテストの必要性
  • 「プロンプト＝新たな境界線」認識の浸透促進

Hackerたちの意見

- 「エージェントは攻撃面をマッピングして、APIドキュメントが公開されているのを見つけたんだ — 200以上のエンドポイントがあって、全部ドキュメント化されてた。ほとんどは認証が必要だったけど、22個は必要なかった。」ほら、こんな感じ。
> これはマッキンゼー・アンド・カンパニーのことだった — 世界クラスの技術チームを持つ会社 [...] 私の経験では、そんなに評判良くないけど。マッキンゼーってソフトウェアに関しては思ったより尊敬されてるの？それとも、TFAがこの部分を丁寧に省略しなかった理由が気になる。
└
このLLMは、自分を抑えられなかったんだな。
└
> 私の経験では、そんなに評判良くないけど。どのストリートにいるかによるよ。メインストリートにいるのか、それともウォールストリートにいるのか？ビジネスの問題を解決するためのソフトウェアを手伝ってもらうために彼らを雇うなら、他の人たちと同じくらいだと思うよ。会社を解体するためのソフトウェアや、どの南アフリカの役人を賄賂するかを考えるためのソフトウェアを手伝ってもらうために雇うなら、話は別だけど。
└
彼らは一般的に、以下のようなスキルを持った賢い人を雇うよね。 - 既存のシステムを理解すること - 問題点を把握すること - その問題点を踏まえてシステムを改善する提案をすること - それには技術的な変更やプロセスの更新、新しいシステムの導入などが含まれる。 で、これを実行する際、私の経験上、結局は既存の開発チームがやることになることが多い。 出典：大手投資銀行でマッキンゼーを雇ってた時に、マッキンゼーのコンサルタントの一人を知ってた。
└
いや、彼らには世界クラスの技術チームはないよ。技術的なことは全部契約社員にやらせてる。彼らの専門はマネジメントだから、そっちは確かに世界クラス。
ずっと前にマッキンゼーのチームがワトソンを押し付けてきたのを覚えてる。完全に大失敗だった。AIに関してはずっとハイプばっかりで、実際の中身はないって感じだし、あんまり変わってないみたい。別のことには強いかもしれないけど、マッキンゼーの人たちがAIの話をしたら、みんな逃げ出すだろうね。
> 無防備なエンドポイントの一つが、ユーザーの検索クエリをデータベースに書き込んでいた。値は安全にパラメータ化されていたけど、JSONのキー — フィールド名 — がSQLに直接結合されていた。プロンプトインジェクションを期待してたけど、今回はただの古典的なSQLインジェクションだった。これはマッキンゼーのAIプラットフォームを作ったLLMの単純さのおかげで可能だった。
└
うーん、ちょっとがっかりだな。これは普通のSQLインジェクションで、脆弱性スキャンのLLMエージェントが見つけたものだし。やっと有名な企業に対するプロンプトインジェクション攻撃が見つかるかと思ったのに。
└
oauth2-proxyをインターネット上にデプロイされたものの前に置くための暗黙の知識は、今年私に$0をもたらすだけだけど、Anthropicは何十億も稼ぐんだろうな。
> 1945年にその会社に雇われた最初のプロフェッショナルな女性の名前にちなんで名付けられた。AIアシスタントのために女性の名前を探して、それを自慢するのは、クリエイターたちが思っていたほどエンパワーメントにはならないんじゃないかな。
タイトルがあんまり好きじゃないな。これって私の問題かもしれないけど、「AIエージェントがXをする」って見ると、所有権が曖昧なエージェントのことが頭に浮かんじゃうんだよね。今回は、ペンテスターたちがAIエージェントを使ってマッキンゼーを選んで、その後そのAIエージェントでペンテストをしたって話。無生物に行動を帰属させるのは普通だけど（車が歩行者をひくみたいに）、今の時代はもうちょっと明確にした方がいいと思う。残念ながら、最近は一部の人がこういうエージェントシステムにエージェンシーを持たせてるからね。
└
うん、元の記事のタイトル「マッキンゼーのAIプラットフォームをハッキングした方法」の方がいいね。
└
そうだね、ただの広告だし、「ペンテストエージェントが低ハンギングの脆弱性を見つける」なんてクリックを引き寄せるタイトルじゃないよ。
└
> 残念ながら、最近は一部の人がこういうエージェントシステムにエージェンシーを持たせてる。 それを「エージェントシステム」と呼ぶことで、君もそれをやってるよね。
コードウォールが誰なのか全然わからない。マッキンゼーが実際に言及された問題を修正したって認めてるの？昨日以前のニュース記事には「コードウォールAI」って名前が見当たらないし、サイトにも名前が載ってないよ。 https://www.google.com/search?q=codewall+ai
└
うん、私もあんまり情報が見つからない。せめて何か証拠が見たいな。マッキンゼーかセキュリティチームからでも。
└
変だよね？レジスターの記事は、マッキンゼーが認めてるみたいなことを示唆してるよ。 https://www.theregister.com/2026/03/09/mckinsey_ai_chatbot_h... 編集：どうやらこれがCEOみたいだね。 https://github.com/eth0izzle
└
もしダンプに58,000人のユーザーがいるのが本当なら、元従業員がその中にいるってことだよね。そうなると、マッキンゼーはそれを開示する必要があるか、少なくとも元従業員に侵害について知らせるべきじゃない？
└
下の方に責任ある開示のタイムラインがあって、すべて修正されたって書いてあるよ。
ちょっと内部情報：リリは、少なくとも1年前は内部専用だった。VPNアクセスやSSO、いろいろ必要だったよ。いつ変わったのかはわからないけど。マッキンゼーは、たとえ少人数の同僚に対しても外部のペンテスト会社を雇う必要があるんだ。この手のミスはリリの開発者たちには許せるかな。エージェント的なセキュリティ会社が公開エンドポイントを見つけるには、かなりのことが失敗しないといけないし、そこから悪用を始めるのはもっと難しいからね。とはいえ、ここにあるミスはひどい。認証がほぼゼロに近いみたい。かなり古い情報に基づくと、シニアパートナーが何かしらの手を回してリリを公開させたんじゃないかな。その頃には、元のリリチームのほとんどが「ロールオフ」して（クライアントプロジェクトに行って）、マッキンゼーは内部プロジェクトに取り組むことを厳しく罰するからね。だからリリは、他で働けなかった人たちが集まって、コードも知らないし、気にもしてない人たちで構成されてた可能性が高い。内部の仕事は、良くも悪くも、基本的に半日仕事だよ。これはマッキンゼーの技術に関する文化の失敗だね。
└
結論としては、マッキンゼーが自分たちでうまくできないなら、AIの実装や技術組織の設計・実践についてアドバイスを依頼しない方がいいってこと。
└
もしかしたら、リクルートに使えるようにオープンにされたのかも？マッキンゼーが卒業生にAIチャットボットを使ってリクルートの見直しを挑戦させてるってさ。
└
会計やマネジメントコンサルティング会社がテクノロジーで何をしてるのか、よくわからないな。彼らは何かをパッケージ化して売れる限り売ろうとしてるだけに見える。AIソリューションは持続可能な期間が短いし、AIに関する考え方も急速に進化してる。間違ってたら嬉しいし、他に情報があれば教えてほしいな。
└
量子ブラックも同じ感じなのかな？少なくとも、Brixの資産はちょっとは最新で使える印象があるね。
└
いくつか付け加えたいことがある。マッキンゼーは、キッチンにシェフが多すぎる変な構造をしてるんだ。そこで働いてるみんなはクライアントへの影響で評価されるから、結局はみんな自分のことだけ考える状況になっちゃう。だから、開発者としてはあまり指導がないし（実際、クライアントとの接触がゼロでも、クライアントへの影響で評価されるんだよね）。それで、（シニア）パートナーがこのアイデアを持ってきて（それが良い評価につながるから）、みんなそれに飛びつく。結局、良い評価を得るためにできることはそれだけだから。頑張って取り組むけど、（シニア）パートナーは次に行っちゃう。でも、プロジェクトはまだ終わってない。レビューには十分だけど、続けて取り組んでも何も得られないし、実際には自分を下げることになる。プロジェクトを完成させても、すぐにクライアントの結果にはつながらないからね。じゃあ、これってどういうこと？マッキンゼーの製品は、リーダーシップの生のアイデアが詰まった寄せ集めで、一回限りの実装になってる。統一されたビジョンも長期的なビジョンもない。すべてはレビューサイクルのため。マッキンゼーは、他の業務と同じようにソフトウェアをやろうとしてるけど、うまくいってない。6ヶ月何かをやって、そのまま放置するわけにはいかない。ソフトウェアは腐るからね。2024年にかなりの数の（とても優秀な）ソフトウェアエンジニアを解雇したのは、彼らがソフトウェア開発をどう見ているかの反映だよ。そして、マッキンゼーの人たちが他の会社に行くと、そのアイデアを持っていく。結果として、プロジェクトのUIが常に変わる。みんなが短期的な影響を重視して、良い評価を得るために動いているから、長期的にプロジェクトにとって何がベストかを考えていないんだ。
著者はこのブログ投稿を書くために使ったプロンプトを教えてくれませんか？トピックは面白いけど、元のプロンプトを読んだ方がいいなと思って。どの部分が著者の言いたいことに合ってるのか、どれが魅力的な表現のためにLLMが作ったものなのか、よくわからないから。
ここでの興味深いポイントは、組織がAIツールを内部で展開するのがどれだけ早いかということだね。セキュリティモデルを完全に適応させることなく。従来のアプリケーションセキュリティは、比較的予測可能な入力やワークフローを前提にしているけど、LLMベースのシステムはまったく新しい攻撃面をもたらす—プロンプトインジェクション、データ漏洩、ツールの誤用など。多くの企業が、これらのシステムをただのSaaS製品として扱っているように感じる。自律型システムに近いもので、異なる脅威モデルが必要なのにね…