McKinsey 的 Lilli 於 3 月 9 日公開。該紀錄不帶任何傷害。

2026年3月9日，安全新創公司 CodeWall 發表了一份說明，記錄它所打造的一個自主代理，是如何在大約兩小時內、而且在完全沒有任何憑證的情況下，取得麥肯錫公司（McKinsey & Company）全公司 AI 助理 Lilli 背後生產資料庫的完整讀寫權限。入侵本身發生於2月28日；這則 AI 事件檔案條目所記錄的，是這件事公諸於世的那一天。根據 CodeWall 的說法，它所觸及的資料庫以明文儲存了 4,650 萬則聊天訊息、72.8 萬個檔案、5.7 萬個使用者帳號，以及 95 條決定 Lilli 如何作答的系統提示詞——而那些提示詞就存放在這個代理能寫入的同一個資料庫裡。資料中的人全是麥肯錫自家員工：該公司表示，旗下有 72% 的員工、也就是超過 4 萬人使用 Lilli，每月處理逾 50 萬則提示詞。完整條目，連同其嚴重度與信心等級，以及它所並列的鄰近紀錄，都收錄在 Orca AI Incident Archive。

那段開頭壓縮了兩種截然不同的主張，而檔案條目對其間的差異相當謹慎。它將該紀錄評定為事件、信心等級 A、無爭議、嚴重程度高、地區為美國、類型為 INFRA——基礎設施，而非模型失效。它也記錄了並無實際危害。最後那個欄位值得再讀一遍，因為它並不表示這次暴露無害，而是表示在紀錄上並未確立任何危害；下文將區分雙方一致同意的內容，以及僅依賴一家公司對其自身研究的說法。

為什麼揭露本身即為一個有日期的獨立事件

檔案庫對本條目的摘要可回溯至 2026 年 2 月 28 日，也就是 CodeWall 的代理程式發現該缺陷的那一天，而檔案庫也將這個較早的日期另存為獨立紀錄。這種區分並非官僚作風。在 3 月 9 日之前，唯一知道 Lilli 內部發生什麼事的，只有 McKinsey 和當初向它通報此事的研究員。3 月 9 日之後，故障的形態、該公司的回應，以及關於資料庫內容的說法，全都進了公開紀錄，其他安全研究人員得以在公開紀錄上與之爭辯。

Lilli 不是附屬專案。The Register 指出其推出時間為 2023 年 7 月，功能涵蓋聊天、文件分析，以及在該公司內部研究資料中進行檢索。CodeWall 的報導也記錄了這個名稱的由來——該公司於 1945 年聘用的第一位專業女性——並描述其背後有超過 100,000 份內部文件。The Register 在同日報導這項披露時指出，員工採用率為 72%，每月提示量超過 500,000 則——這些數字是 McKinsey 自己在該平台的公開案例研究中所公布的。

探員是如何進入的

CodeWall 的記述始於文件，而非漏洞利用。其代理發現 Lilli 的 API 文件公開暴露，且內容完整：總共超過 200 個端點，多數需要驗證，另有 22 個不需要。其中一個未驗證端點會將使用者搜尋查詢寫入資料庫。數值有正確參數化，但 JSON 鍵——也就是欄位名稱——被直接串接進 SQL。

該代理之所以會注意到，是因為資料庫錯誤訊息會逐字回傳那些 JSON 鍵。CodeWall 表示，OWASP 的 ZAP 掃描器並未標記這個問題，而該代理隨後執行了十五次盲測迭代，每個錯誤訊息都讓它更了解查詢的形狀，直到線上生產資料列開始回傳。接著，它將這項注入與物件層級授權漏洞串連起來，讀取個別員工的搜尋紀錄。該公司形容整個過程完全自主，從目標選擇到產出報告，全程無需憑證，也沒有人為介入。其創辦人兼執行長 Paul Price 告訴 The Register，這個流程「從研究目標、分析、攻擊到報告，全程完全自主」。

CodeWall 說當時在裡面的東西

本節的每一個數字都出自 CodeWall 3 月 9 日的報告。由於未公開任何載荷，因此其中任何內容都無法重現或獨立計數——這是下一節將處理的一項限制。

• 4,650 萬則聊天訊息，以明文儲存，涵蓋策略工作、客戶專案、財務，以及併購。

• 728,000 個檔案，其中該報告逐項列出 192,000 個 PDF、93,000 個 Excel 試算表、93,000 個 PowerPoint 簡報與 58,000 個 Word 文件——合計 436,000 個，同一句話中剩下的 292,000 個則未予分類。

• 57,000 個使用者帳戶、384,000 個 AI 助理和 94,000 個工作區，CodeWall 稱這反映了該公司內部使用 AI 的完整組織結構。

• 橫跨 12 種模型類型的 95 個系統提示與模型配置，展示助理如何被指示、存在哪些防護機制，以及其底層搭載哪些模型。

• 368 萬個檢索增強生成文件區塊，包含 S3 儲存路徑與內部檔案中繼資料——也就是為助理提供資料的知識庫。

• 110 萬個檔案與 217,000 則代理訊息透過外部 AI API 傳輸，其中包括 OpenAI 平台上超過 266,000 個向量儲存庫。

CodeWall 視為頭條的發現，不是注入本身，而是注入落腳何處。Lilli 的系統提示是代理程式可寫入之同一個資料庫中的資料列，這意味著擁有相同存取權限的攻擊者，只要用包在單一 HTTP 呼叫中的單一 UPDATE 陳述式，就能改寫助理的指令——無需部署、無需變更程式碼，磁碟上也沒有檔案可比對差異。CodeWall 表示自家的測試僅限於驗證：它只有讀取，沒有寫入，並稱沒有生產服務受到干擾。

麥肯錫當天說了什麼

McKinsey 發言人於 3 月 9 日告訴 The Register，該公司在得知 CodeWall 所發現的所有問題後數小時內，就已全數修復。該發言人表示：「我們的調查在一家領先的第三方鑑識公司協助下進行，未發現任何證據顯示客戶資料或客戶機密資訊曾被該研究人員或任何其他未經授權的第三方存取。」並補充說：「McKinsey 的網路安全系統十分穩健。」

Silicon UK 於 3 月 13 日報導了相同立場，在 Matthew Broersma 的報導中指出：McKinsey 表示，該公司「近期由一名安全研究員告知，我們的內部 AI 工具 Lilli 存在一項漏洞」，並「迅速確認了該漏洞，並在數小時內修復了問題」，且沒有任何客戶資料或客戶機密資訊遭到存取。該報導也提到，Price 是 CodeWall 唯一的員工；這個細節值得保留，因為它是一把雙面刃——一個只有一人的研究團隊在兩小時內找到了該公司自家掃描工具沒能找到的東西，而這個只有一人的團隊也正是販售找到該漏洞之工具的一方。

相隔一天，關於這次修復的兩種說法

CodeWall 自身的揭露時程如下：該代理程式於 2 月 28 日識別出 SQL 注入並開始列舉生產資料庫；完整攻擊鏈於同日獲得確認，並記錄了 27 項發現；3 月 1 日，一封負責任揭露電子郵件寄至 McKinsey 的安全團隊，內含高層次影響摘要；該公司的資訊安全長於 3 月 2 日確認收到並要求提供詳細證據；而在 3 月 2 日，所有未經身分驗證的端點皆已完成修補並驗證，開發環境已下線，公開 API 文件也遭到封鎖。公開揭露隨後於 3 月 9 日進行。

McKinsey 的說法是，修補是在被告知後數小時內完成。{{1}}CodeWall 的時間線則把修補安排在披露電子郵件發出後的隔天。{{/1}}雙方的說法都有紀錄。兩方都未調和這些說法，本文也不試圖調和：差異在於當天修補與隔天修補，而真正重要的順序——先被告知、再修補、然後公布——並無爭議。

已確立、單一來源，以及兩者之間的落差

已確立，雙方同意：Lilli 的公開 API 介面存在一個未經身分驗證的弱點；該弱點是由外部安全研究人員而非內部人員發現；McKinsey 已確認並修補該弱點；未經身分驗證的端點已關閉，開發環境已離線，且公開 API 文件已被封鎖。

單一來源，出自 CodeWall：上述每一項計數、兩小時的時間線、十五次盲迭代、27 項有紀錄的發現，以及那些提示詞可透過同一種注入方式寫入的主張。這些都未被推翻。這些也都未經獨立驗證，因為能讓人查核的酬載並未公開，而 Price 拒絕向 The Register 提供他團隊所使用的確切提示詞。

AI 安全公司 Promptfoo 於 3 月 10 日發表了一份評估，精確指出了這項限制：公開紀錄「無法獨立證實每一項所報告的資料列數量，也無法證實漏洞利用的每一個步驟」，儘管它確實支撐得起這起事件的大致輪廓。這才是對現有材料的正確解讀。漏洞的類別可以重建；至於規模，則僅止於證詞。

記錄所不承載的傷害

這正是檔案評分真正發揮作用之處。一條能在兩小時內取得全公司助理正式環境資料庫讀寫權限的路徑，聽起來像是一筆危害紀錄，而檔案中卻沒有任何記載。這個欄位建立在三件事上：McKinsey 表示第三方鑑識調查未發現客戶資料曾遭存取的證據；CodeWall 表示其測試僅屬驗證性質，並未造成任何干擾；以及本文所檢視的報導中，並不存在任何相矛盾的調查結果。

這件事並非建立在獨立技術稽核、監管機關的認定或資料外洩通知之上。在本次檢視的所有報導中，均未獲配 CVE 識別碼——Lilli 屬於內部軟體，而非對外散布的產品，也沒有任何公告提及它——且似乎沒有任何監管機關立案調查。就本文所檢視的報導而言，並未出現任何公開證據顯示這些資料曾被使用、販售或進一步外洩。這正是此處「未記錄到實際損害」的意思：這是一項關於紀錄的證據陳述，而非認定該次暴露是安全的。

這個落差很重要，因為真正有意思的風險是未來可能發生的風險。讀取權限會暴露既有內容。對 prompt 層的寫入權限則會暴露助理接下來會說什麼——被下毒的建議、護欄遭移除、機密資料被夾帶進某個答案，而顧問隨後把那個答案貼進客戶文件。CodeWall 將這些後果描述為任何擁有相同權限的人都可觸及。沒有人證明它們曾被實際利用。這兩種說法可以同時成立：能力確實存在，而就任何人已公開的證據而言，損害並未實際發生。

為什麼它被歸類為基礎設施，而不是模型失效

檔案將此紀錄標記為 INFRA，而技術紀錄也支持這個標籤。在 CodeWall 的帳戶中，沒有任何環節需要誘騙模型。沒有越獄、沒有來自文件的提示注入，也沒有要求助理吞下的對抗性輸入。入口點是暴露的說明文件、缺失的身分驗證檢查，以及不安全的 SQL 建構；模型只是門後最有價值的東西。

Promptfoo 3 月 10 日的分析從防禦角度作出了同樣的區分：Lilli「從公開紀錄來看，像是已觸及 AI 系統的應用程式安全事件，而非模型越獄」，而許多被稱為 AI 安全的事，其實仍屬於軟體安全、資料安全與組態治理。真正屬於 AI 特有的部分在於影響範圍，而非入侵本身——因為提示、路由規則與檢索設定都是可變的應用程式資料，資料庫寫入權限便成了無須改動程式碼就能改變助理行為的能力。

之後有什麼改變？

具體的變更正是雙方所描述的內容：未經身分驗證的端點已關閉並經驗證，開發環境已下線，公開 API 文件也已封鎖。McKinsey 表示，他們發現、確認並修復了該漏洞，而其公開立場是沒有任何客戶資料遭到存取。

沒有改變的是這起事件所描述的更廣泛曝露情形。CodeWall 的文章在結尾主張，提示詞被存放在資料庫、經由 API 傳遞並快取在設定檔中，而且它們鮮少受到存取控制、版本歷程或完整性監控——這是對整體產業的論斷，而非關於 McKinsey 的調查發現，應被解讀為一家販售持續自動化測試的公司所提出的論點。該公司正處於早期預覽階段並尋找設計合作夥伴；這份披露同時也是一場示範。

紀錄留下的東西，比爭論本身更狹窄，卻也更有用。一個全公司共用的助理、一個生產環境資料庫、兩小時、沒有任何憑證，以及一條讀來是「否」的損害判定——因為能接觸到事實的兩方都說，資料並未被使用。那些計數數字屬於其中一方；漏洞則屬於雙方。