McKinsey Lilli侵害事例 — AIエージェントが2時間で突破した脆弱性と対策

はじめに

2026年3月9日、セキュリティスタートアップ CodeWall が衝撃的なレポートを公開した。同社の自律型オフェンシブAIエージェントが、マッキンゼーの社内AIプラットフォーム「Lilli」をわずか 2時間 で突破し、本番データベースへの完全なRead/Writeアクセスを獲得したという内容だ。

露出したデータは 4,650万件のチャットメッセージ 、 72万8,000ファイル 、 5万7,000ユーザーアカウント に及ぶ。しかも攻撃に使われた手法は、2026年の最先端技術ではなく、古くから知られるSQLインジェクションの変種だった。

この事例は、AIプラットフォームを構築・運用するすべてのエンジニアにとって重要な教訓を含んでいる。本記事では、公開情報をもとに攻撃チェーンの技術的詳細と防御策を解説する。

この記事で学べること

• McKinsey Lilliの侵害がどのように発生したか（攻撃チェーンの全容）
• JSONキー結合によるSQLインジェクションの仕組み
• 書き換え可能なシステムプロンプトが生むリスク
• AIプラットフォームに必要な多層防御の設計パターン

対象読者

• AIプラットフォーム・LLMアプリケーションを開発するエンジニア
• セキュリティエンジニア・AppSecチーム
• AIエージェントを導入する組織の技術責任者

TL;DR

• CodeWallの自律AIエージェントが、McKinseyのAIプラットフォーム「Lilli」を2時間で突破した
• 攻撃経路は「未認証APIエンドポイント → JSONキー結合SQLインジェクション → 本番DB完全アクセス」
• システムプロンプトが同一DBに書き込み可能な状態で格納されており、全ユーザーへの応答を改ざんできた
• 防御には「未認証エンドポイントの排除」「パラメータ化の徹底」「プロンプト層の分離」「ゼロトラスト設計」が必要

攻撃チェーンの全容

CodeWallのレポートおよび複数のセキュリティメディアの報道によると、攻撃は以下の4段階で進行した。

Stage 1: サーフェスマッピング（API探索）

CodeWallの自律エージェントは、Lilliプラットフォームの公開APIドキュメントを発見した。このドキュメントには 200以上のAPIエンドポイント が記載されており、そのうち 22エンドポイントが認証を必要としない 状態だった。

通常のWebアプリケーションではAPIドキュメントを公開していても認証が必須となるが、Lilliでは一部のエンドポイントが認証なしでアクセス可能だった。2年以上の運用期間中、この問題は検出されていなかったと報じられている。

Stage 2: SQLインジェクションの発見

未認証エンドポイントの中に、ユーザーの検索クエリをデータベースに書き込む機能があった。ここで重要なのは、 値（value）は安全にパラメータ化されていた という点だ。一般的なSQLインジェクション対策は施されていた。

しかし、 JSONのキー（フィールド名）がSQL文に直接結合 されていた。

-- 安全: 値はパラメータ化
INSERT INTO searches (query) VALUES ($1)

-- 危険: JSONキーがSQL文に直接結合
INSERT INTO searches ({json_key}) VALUES ($1)
-- json_key = "query); DROP TABLE users; --" のような注入が可能

エージェントはデータベースのエラーメッセージにJSONキーがそのまま反映されることを検知し、 15回のブラインドイテレーション を通じてデータベース構造を段階的に解明した。各エラーメッセージがアーキテクチャの詳細を明らかにし、最終的に本番データベースへの完全なRead/Writeアクセスを獲得した。

The Register の報道によると、OWASP ZAPを含む標準的なセキュリティスキャンツールはこの変種を検出できなかったとされている。

Stage 3: データ露出

エージェントがアクセスした本番データベースには以下が含まれていた。

データ種別	件数	内容
チャットメッセージ	4,650万件	戦略立案、M&A、クライアントエンゲージメント
ファイル	72万8,000件	PDF 19.2万、スプレッドシート 9.3万、PPT 9.3万、Word 5.8万
ユーザーアカウント	5万7,000件	従業員レコード一式
AIアシスタント	38万4,000件	組織構造を反映した設定
ワークスペース	9万4,000件	チーム・プロジェクト単位の作業空間

Stage 4: プロンプト層の侵害

最も深刻だったのは、Lilliの 95のシステムプロンプト設定 （12種類のモデルにまたがる）が同一の本番データベースに格納されており、しかも 書き込み可能 な状態だった点だ。

加えて、 368万件のRAGドキュメントチャンク とそのS3ストレージパス、 26万6,000以上のOpenAIベクトルストア も露出していた。

攻撃者がシステムプロンプトを改ざんした場合の影響は甚大だ。

• 数万人のコンサルタントが利用するAIの応答内容を操作可能
• 財務モデルや戦略的推奨事項を意図的に歪曲できる
• 機密データをAIの応答に埋め込んで外部に漏洩させられる
• セーフティガードレールを除去できる
• サーバーレベルの変更と異なり、監査証跡が残らない（単一のHTTP callでUPDATE文を発行するだけ）

なぜ「自律AIエージェント」が脅威なのか

この事例が従来のペネトレーションテストと根本的に異なるのは、攻撃を実行したのが 自律型AIエージェント だった点だ。

CodeWallのレポートによると、エージェントは「マッピング、探索、チェーン化、エスカレーション」を自律的に実行した。個々の脆弱性は軽微でも、エージェントはそれらを 連鎖 させて複合的な攻撃チェーンを構築する。

OWASP Top 10 for Agentic Applications 2026 でも、エージェントの自律的なアクション連鎖能力により「単純なプロンプトインジェクションがシステム全体の侵害、データ漏洩、金銭的損失に急速にカスケードする」リスクが指摘されている。

従来のセキュリティツールが「既知のシグネチャとチェックリスト」に依存するのに対し、自律エージェントは 適応的に 脆弱性を発見・悪用する。この非対称性が、AIプラットフォームのセキュリティに新たな課題を突きつけている。

タイムラインと対応

日付	イベント
2026年2月28日	CodeWallエージェントがSQLインジェクションを発見、DB列挙を開始
2026年3月1日	McKinseyへの責任ある開示（Responsible Disclosure）
2026年3月2日	McKinseyが未認証エンドポイントをすべてパッチ適用
2026年3月9日	CodeWallが攻撃チェーンの詳細を公開

McKinseyは「大手サードパーティフォレンジック企業の支援を受けた調査の結果、この研究者またはその他の不正な第三者によるクライアントデータまたはクライアント機密情報へのアクセスの証拠は確認されなかった」と発表した。発見から24時間以内にパッチが適用されたことは、インシデントレスポンスとしては迅速な対応だった。

防御策: AIプラットフォームに必要な多層防御

この事例から得られる教訓を、具体的な防御策として整理する。

1. APIセキュリティの徹底

未認証エンドポイントの排除 が最優先だ。内部APIであっても、すべてのエンドポイントに認証を要求する設計が必要となる。

# API Gateway設定の例（概念的な記述）
security:
  default_policy: "deny_all"
  authentication:
    required: true
    methods: ["oauth2", "api_key"]
  exceptions: []  # 例外なし — すべてのエンドポイントに認証を要求

APIドキュメントの公開範囲も制限し、認証済みユーザーのみがアクセスできるようにする。

2. SQLインジェクション対策の拡張

値のパラメータ化だけでは不十分だ。JSONキー、テーブル名、カラム名など、 動的に構築されるSQL文のすべての要素 を検証する必要がある。

# 危険: JSONキーをSQL文に直接結合
def insert_search(json_data):
    for key, value in json_data.items():
        cursor.execute(f"INSERT INTO searches ({key}) VALUES (%s)", [value])

# 安全: 許可リスト（allowlist）でキーを制限
ALLOWED_COLUMNS = {"query", "timestamp", "user_id"}

def insert_search_safe(json_data):
    for key, value in json_data.items():
        if key not in ALLOWED_COLUMNS:
            raise ValueError(f"Invalid column name: {key}")
        cursor.execute(f"INSERT INTO searches ({key}) VALUES (%s)", [value])

ORMを使用している場合でも、動的なカラム名やテーブル名の構築には同様の注意が必要だ。

3. プロンプト層の分離と保護

システムプロンプトをアプリケーションデータと同じデータベースに格納してはならない。

• プロンプトを不変（immutable）にする: プロダクション環境のランタイムからは読み取り専用でアクセスし、変更はデプロイパイプライン経由のみとする
• バージョン管理: プロンプトの変更履歴をGitで管理し、差分を追跡可能にする
• 整合性モニタリング: プロンプトの不正な変更を即時検出するアラートを設定する

4. ゼロトラスト設計

AIプラットフォームを「信頼されたシステム」として扱わず、 信頼されないクライアント として設計する。

• 最小権限の原則: AIシステムが内部インフラストラクチャに直接アクセスすることを禁止し、必要最小限のAPIのみを公開する
• リクエストごとの検証: ログイン時だけでなく、すべてのリクエストでユーザーIDとアクセス権限を検証する
• 監査ログ: AIが実行したすべてのアクションをユーザーIDに紐づけて記録し、異常検知を可能にする

5. 継続的なAIレッドチーム

年次の静的なペネトレーションテストでは、自律エージェントによる攻撃を検出できない。継続的かつ自動化されたレッドチームテストの導入が推奨される。

OWASP Top 10 for Agentic Applications 2026 では、エージェントセキュリティのリスクとして「Agent Goal Hijack」から「Rogue Agents」まで10のカテゴリが定義されており、これらを網羅的に評価するフレームワークとして活用できる。

まとめ

McKinsey Lilliの侵害事例は、AIプラットフォームセキュリティにおいて以下の重要な教訓を示している。

• 基本的なセキュリティ対策の不備 が、2年以上検出されずに放置されていた。未認証エンドポイントの存在は、定期的なセキュリティ監査で容易に発見できる問題だ
• パラメータ化の「盲点」 が存在する。値のパラメータ化は実施していても、JSONキーやカラム名の動的構築という見落としがちな箇所に脆弱性が残っていた
• プロンプト層は新たな攻撃対象面 となる。システムプロンプトが書き換え可能な状態は、従来のデータ漏洩を超えた影響（全ユーザーへの応答改ざん）をもたらす
• 自律AIエージェントは攻撃能力を根本的に変える 。個別には軽微な脆弱性でも、エージェントは自律的に連鎖させてシステム全体を侵害する

AIプラットフォームの構築にあたっては、「AIシステムへの暗黙の信頼」を排除し、ゼロトラストの原則に基づいた多層防御の設計が求められる。

参考リンク

• How We Hacked McKinsey's AI Platform — CodeWall
• How an AI Agent Hacked McKinsey and Exposed 46 Million Messages — NeuralTrust
• AI agent hacked McKinsey chatbot for read-write access — The Register
• What Made McKinsey's AI Platform Easy to Hack? — Pomerium
• OWASP Top 10 for Agentic Applications 2026
• OWASP Top 10 for Large Language Model Applications