AIDEFEND in Action AIA-0004 實證研究 發布於 AIA: 2026年4月17日

McKinsey Lilli 平台被攻破：SQL Injection 可竄改 AI 的系統提示詞

攻擊從傳統 Web 漏洞開始。McKinsey 的內部 AI 平台 Lilli 有 22 個未驗證呼叫者身分的 API 端點；其中一個端點把攻擊者可控制的 JSON 欄位名稱直接組成 SQL。CodeWall 的自主測試 agent 利用這條路徑，在約兩小時內取得後端資料庫的讀寫權限。該資料庫包含 4,650 萬則對話訊息、72.8 萬份檔案、368 萬筆檢索增強生成（RAG）資料片段、向量資料庫中繼資料，以及會影響超過 4.3 萬名使用者所用 AI 助理的系統提示詞。這些數量描述資料庫的內容，不代表每筆資料都已被讀取或外傳。

這起事件顯示，SQL 注入也可能直接影響 AI 平台的提示詞與檢索資料。防守方須像保護程式碼與憑證一樣，對這些 AI 控制資料限制存取、驗證完整性，並追查未經核准的變更。

SQL InjectionData ExfiltrationData GovernanceEnterprise AIAgentic AI
5 項對應的 AIDEFEND 防禦手法
來源: How We Hacked McKinsey's AI Platform 
作者: Paul Price (CodeWall)
原文發布: 2026年3月9日

威脅分析

  • 第 1 步：先從沒驗證的 API 端點找入口。 Lilli 有 22 個 API 端點沒做驗證，這代表攻擊者連帳號都還不用有，就能先對外露的介面一路試下去。CodeWall 的自主 agent 也是先從這個面開始探查。
  • 第 2 步：其中一個端點，會把 JSON key 直接拿去組 SQL。 CodeWall 表示，agent 約兩小時內就透過 SQL 注入取得正式環境資料庫的讀寫權限；另將 SQL 注入與不安全的直接物件參照（IDOR）漏洞串接，讀取個別員工的搜尋紀錄。這是來源分別描述的兩項結果。
  • 第 3 步：更麻煩的是，這個資料庫裡放的不只是一般業務資料。 裡面同時有 4,650 萬則對話訊息、72.8 萬份檔案、368 萬筆 RAG chunk、vector store metadata、AI 助理設定，以及 95 份提示詞與模型設定。也就是說，一旦資料庫被打穿，受影響的不是單一表格，而是整個 AI 平台怎麼回答、怎麼擷取、怎麼跟資料互動的那一層。
  • 第 4 步：寫入權限可能被用來改變 AI 行為。 這個 SQL injection 不只可讀，還允許 UPDATE。攻擊者可以用一個 HTTP 呼叫就改掉系統提示詞、竄改 RAG 內容、移除模型層的安全指示，或植入外洩資料的指令，而且不需要重部署，也不需要改應用程式程式碼。這些是已驗證寫入權限的可能影響，不代表研究者真的竄改提示詞，也不能據此認定獨立執行的後端授權會被繞過。
  • 為什麼這件事特別值得記住： Lilli 這樣跑了兩年，有 4.3 萬名使用者、每月 50 萬筆提示詞。CodeWall 表示掃描未發現這個問題，而其 agent 找到可重現的路徑；公開資料不足以推定所有人工測試都無效。McKinsey 在 2026-03-01 收到通報後，2026-03-02 就完成修補並關閉未驗證端點，處置算快，但這個案例已經很清楚地告訴我們：只要傳統 Web 漏洞能打到提示詞和擷取層，整個 AI 平台就會一起失守。

適用的 5 項 AIDEFEND 防禦手法

AID-H-021.002
Runtime Integrity Enforcement (Signed Configurations)
高
將核准的提示詞與設定整理成內容確定的簽章套件，在啟動及每次動態更新前，於本機驗證並使用同一份內容；信任金鑰與部署核准須留在遭入侵資料庫之外。這需要客戶可控的載入器，不能只把簽章放在資料列旁。未簽章、過期套件及資料庫直接送入模型的繞過路徑均須拒絕。核准簽章證明來源與完整性，不證明提示詞內容安全。
AID-H-020.001
Chunk-Level Integrity Signing
高
組合模型上下文前，將確切文字區塊、來源版本、嵌入向量內容與模型身分，對照外部簽章、版本固定且鎖定保留期限的清單。簽章者與清單須位於向量或資料庫寫入者的信任範圍之外；缺漏、過期或不符均須拒絕。若雜湊或簽章只放在可變更資料列旁，能同時替換兩者的寫入者仍可繞過。
AID-D-004.003
Runtime Configuration & Policy Drift Detection and Monitoring
中
以獨立身分比對實際生效的提示詞與政策是否符合核准版本，發現偏移後交由調查。刊載的 Argo CD 方法觀察部署資源，不會自動讀取資料庫中的提示詞資料列；本案例須另行審查涵蓋完整紀錄的資料庫或執行環境收集程序。儲存庫事件或資料庫稽核日誌本身，不能證明實際執行狀態；偵測也不會直接阻擋或還原變更。 資料庫收集程序屬於替代實作，不是刊載的 Argo CD 方法。
AID-H-018.001
Tool Parameter Constraint & Schema Validation
中
在客戶可控的 API 或工具配接器，組成資料庫操作前，先驗證確切欄位、型別與選擇器，拒絕未知 JSON 欄位名稱。這可縮小可接受的攻擊輸入，但不能取代參數化 SQL 與識別字允許清單；SQL 資料值與欄位名稱各須安全組成。結構驗證本身也不是資料庫隔離邊界。
AID-H-029.002
Lifecycle-Stage Authorization Gate
中
在 AI 各生命週期入口，於訓練、索引建立或上下文組合前，獨立解析確切資產與版本、權威用途標籤、階段及核准目的。客戶可控的資料路徑須阻止直接讀取資料庫而繞過閘道。這項控制限制 AI 資產被未經授權使用，不會修補 SQL Injection，也不等於用不同憑證隔離資料表；資料庫最小權限身分與儲存邊界須另行落實。

身為資安防禦者，我們應該這麼做

  • 盤點完整提示詞、RAG、向量 metadata 與 agent 設定清單，載入或擷取前核對核准的簽章版本。
  • SQL 資料值與識別字都須安全組成；每條 API 路徑應有明確結構、預設拒絕的身分驗證及資源授權。
  • 以獨立保護的資料庫與執行環境收集程序，監控 AI 控制資料的非預期寫入；發現後調查，不能視為已自動阻止影響。
  • 分開資產儲存層與最小權限身分，實測跨儲存層存取及各種可能繞過生命週期閘道的路徑。
  • 加入已授權、範圍明確的資安回歸與紅隊測試，記錄每次涵蓋範圍。自主測試可補強其他 AppSec 方法，不能保證找出所有漏洞。

2 個額外的防禦考量

AI 資產類別之間的影響範圍隔離

提示詞、檢索、對話與身分資料應使用權限及路徑各自受限的儲存層，並測試一個身分遭入侵後，是否仍可直接或橫向存取其他資料。只把資料表移到不同 schema 或資料庫，無法阻止同一高權限帳號存取全部資料。
建議做法: 依提示詞、RAG、對話紀錄、使用者身分及向量中繼資料分開儲存，配置各自受限的憑證與網路路徑，並實測單一身分失守後能否跨區存取。分開資料表名稱本身，不等於建立安全邊界。

資安測試涵蓋範圍

CodeWall 找到其使用工具未發現的可重現路徑，不能據此認定優於所有其他 AppSec 方法。測試須涵蓋 JSON 欄位名稱與資料值、資源授權及 AI 控制資料的寫入。
建議做法: 搭配已授權的自動與人工測試，保留證據並記錄未測範圍。

結論

McKinsey Lilli 這案最值得記住的地方，是一個傳統 Web 漏洞一旦打到提示詞和擷取資料層，後果就不再只是資料庫被看光，而是整個 AI 行為層都能被改寫。AIDEFEND  的提示詞完整性、RAG chunk 簽章、分階段授權這幾條，剛好對應這種失守方式；營運上的重點則是把提示詞、RAG chunk、vector metadata 當成需要獨立完整性控制的核心資產，而不是把它們當成普通資料列，覺得只要放在資料庫裡就安全。

最後更新: