上一篇我們提到，生成式 AI 已經成為現今防守方與攻擊者的工具，今天要再往前一步，看很多滲透測試工程師第一次接觸 AI 都會遇到的觀念轉換，打 AI 和打傳統系統，不是同一件事，這也是近幾年逐漸受到重視的一個名詞「AI Red Team」。

傳統滲透測試，找的是工程漏洞，那 AI Red Team 在測什麼？

過去做網頁滲透時，我們很自然會先找到系統的入口，登入頁、API、檔案上傳、管理介面等，接著開始分析輸入、驗證、權限、資料庫等嘗試找出漏洞，如果漏洞存在，同樣的輸入，在相同環境下，大多會得到相同的結果，因此傳統滲透測試很大一部分工作，就是確認這些可驗證、可重現的弱點是否存在。

現在把目標換成大型語言模型，它不像傳統程式，沒有一條寫死的規則可以驗證，生成式 AI 就是一台文字接龍機，挑下一個字看的是機率。

NIST 在 AI 600-1 生成式 AI 風險管理指引裡，把 AI red-teaming 定義為「一種有結構的測試活動，用來探測 AI 系統，找出像是不準確、有害或帶有歧視性的輸出等缺陷與弱點，通常在受控環境中、並與系統開發者合作進行」。換句話說 AI Red Team 的核心工作，是用攻擊者的角度，驗證 AI 系統是否會被誤導、濫用、繞過，或造成超出設計預期的行為。

這裡的「AI 系統」不只是模型，一個聊天機器人背後，至少包含以下四層：

• 資料（Data）：模型的知識從哪裡來，包含訓練資料、RAG 知識庫、被檢索進來的文件，以及使用者當下輸入的內容。
• 模型（Model）：負責推理與生成的 LLM 本身，也包含包在它外面的系統提示與安全機制。
• 應用（Application）：包住模型的應用程式，例如聊天介面、工具呼叫、Agent 編排、企業流程整合。
• 系統（System）：撐起這一切的基礎設施，包括模型服務、API、雲端環境、權限與金鑰。

這四層之外，還有一條橫跨全部的供應鏈，從別人訓練好的模型、第三方套件到外掛，之後會一起攤開來看。

因此聊天只是其中一步，要分析的是整個 AI 系統會怎麼運作。

• 資料從哪裡進來？
• 哪些元件可以修改它？
• 哪些服務彼此信任？
• 模型能存取哪些資源？
• 哪些權限是模型代替使用者操作？

打不中不代表沒有漏洞

前面有提到，模型挑下一個字看的是機率，這件事對測試的影響很大，同一句話問兩次，走的路徑就可能不一樣，何況上下文、系統提示、模型版本都還會再影響它。一個 Prompt Injection 打過去被擋下來，不代表這條路走不通，可能多打幾次就有一次會過；反過來成功一次也不等於穩定可利用。

這種不確定性在一般的推論服務上，即使把隨機性關掉也消不掉，Thinking Machines Lab 把 temperature 設成 0，用同一個提示詞連續產生 1000 次回應，仍然得到 80 種不同的答案，前 102 個 token 一模一樣，第 103 個開始分岔，原因是推論服務會依當下的負載，把請求湊成不同大小的批次，批次一變，底層的運算順序跟著變，浮點數算出來的結果就有微小差異，這點差異只要影響到某一個 token 的選擇，後面的回答就一路走向不同方向（Defeating Nondeterminism in LLM Inference）。

每一層都沒問題，但串起來就出事了

一封信就能把資料帶走

圖片來源：iThome

2025 年 6 月，Aim Labs 揭露了 Microsoft 365 Copilot 的一個零點擊漏洞 EchoLeak（CVE-2025-32711），Microsoft 將它評為 CVSS 9.3。攻擊者只要寄一封看起來正常的郵件給受害者，把指令藏在 HTML 註解或白底白字裡，受害者不需要打開這封信，只要向 Copilot 問一個相關的問題，這封信就會被檢索進模型的上下文，接著模型照著信裡的指令，把使用者手上的內部文件內容整理出來，透過自動載入的圖片連結送到攻擊者的伺服器。

把這條攻擊鏈對回剛剛那四層會很清楚：指令藏在資料層（被檢索進來的郵件），繞過偵測機制發生在模型層，把資料帶出去靠的是應用層自動載入 Markdown 圖片的行為，而最後那個外連之所以沒被擋，是因為它走的網域在系統層的內容安全政策白名單裡。研究團隊把這種模式稱為 LLM Scope Violation，完整分析可以參考他們後續發表的研究論文。

每一層單獨看都「照設計運作」，串起來就是一條不需要使用者點任何東西的資料外洩路徑，如果測試時只把聊天視窗當成唯一的輸入框，這條攻擊鏈根本不會被發現。

那些老問題也沒有消失，只是又疊了一層

Microsoft 的 AI Red Team 累積測試超過 100 個生成式 AI 產品後，把經驗整理成 Lessons From Red Teaming 100 Generative AI Products，其中一個案例是他們在一套影音處理的生成式 AI 服務裡，找到一個 SSRF 漏洞，成因是服務用了一個過時的 FFmpeg 元件，跟模型一點關係都沒有，他們在報告裡提醒：AI 系統的資安問題，很多依然來自過時的相依套件、錯誤處理不當、輸入輸出沒有清洗這些老問題（可參考 Microsoft Security Blog 的整理）。

由此可知，資料基礎設施、模型服務、部署環境，本質上還是你熟悉的伺服器、API 和雲端設定，用的還是那套老功夫，新增的是疊在上面那層 AI 專屬的手法，針對應用層的提示注入、針對資料層的投毒、針對模型的對抗樣本與模型竊取。

這篇的小總結

所以下次要測試 AI 系統，先別急著在聊天視窗裡打 Payload，把前面那五個問題問過一輪：資料從哪裡進來、誰可以改它、哪些服務彼此信任、模型能碰到什麼、哪些權限是模型替使用者在操作，這五個問題的答案，往往就是你的攻擊路徑。

下一篇，我們就沿著這個思考方式，把一個看起來很普通的 Chatbot 一層一層拆開，從資料、模型、應用、系統到供應鏈畫出完整的 AI Attack Surface。