AI 紅隊演練解析：紅隊測試什麼，又留下什麼

大多數 AI 紅隊演練的成效，都是用錯誤的成果來評判的。一週的工作產出一份簡報，簡報上說這個助理可以被說服寫出一封釣魚郵件，而事後沒有人能說清楚：這個行為是否可重現、情況有多糟，或者哪一道管控措施原本能阻止它。這門專業有真正的產出，而且不是簡報：是一組經得起反覆重跑驗證的發現，每一項都扣連到一條被跨越的界線，以及跨越那條界線的證據。這也正是紀錄所呈現的樣貌：the AI incident archive收錄了 400 筆條目，涵蓋 2024 年 12 月至 2026 年 10 月，取材自 743 個不同來源，並對每一筆給出判定，說明是否真的有人受到傷害。

這種混淆是可以理解的，因為「red teaming」被用在兩種工作上，而這兩者除了共用詞彙之外，幾乎沒有其他共同點。本文是針對這兩者的指南，說明各自應產出什麼證據，以及 AI 紅隊演練真正有別於多數資安團隊早已熟悉如何執行的網路版做法的那四個地方。

框架問題：誰擁有測試

在談範圍之前，先有個問題：這場演練由誰主持、又針對什麼目標。微軟就此發表了相對完整的公開立場之一，值得把它當成一張地圖來讀，而不是當成產品頁面。其 AI Red Team 中心將 AI 紅隊演練的概念與操作方法分開，接著再以本身就是一種論證的順序編排這項實務：總覽，然後是建立 LLM 紅隊的指南，再來是參考資料——用於分級機器學習系統攻擊的 bug bar、機器學習失效的分類法、共同責任模型，以及開發人員威脅建模指引。

讀完這套流程，方法論自然浮現。分類法決定什麼算作失敗。缺陷門檻決定哪些失敗值得修復。共同責任模型則決定一旦發現問題，由誰負責。威脅建模決定下一步該往哪裡看。少了這四者，紅隊只是在產生軼事，再硬加一欄嚴重性；而那一欄嚴重性，不過是測試人員當天下午的感覺。

微軟的開源自動化框架 PyRIT 被擺在同一個架子上，而這個擺放位置正是有用之處。編排工具組不是一套方法論；它是在分類體系與缺陷門檻已經存在之後，你用來對準目標的工具。從框架開始著手的團隊，往往最後只得到大量提示詞語料，卻沒有辦法為結果排序。

兩支紅隊，兩個不同的問題

這個領域裡最有用的一項區分，幾乎沒有人會把它寫下來：紅隊測試模型，以及紅隊測試系統，是在回答不同的問題——受測單位不同、輸出不同、負責人也不同。把兩者混為一談，正是越獄被當成安全發現回報、而真正的權限提升漏洞被歸檔為模型品質投訴的原因。

模型層級的安全性評估是一項量測問題。你是在問模型是否會產出某類內容，而要誠實回答，就需要大到足以對某個比率作出推論的樣本。受測單元是薄薄一層 API 背後的模型，方法是對抗式提示——越獄、角色扮演攻擊、多輪施壓——而產出則是對話紀錄加上傷害判定。當權重改變，或供應商的安全層變動時，整個結果就過時了。這就是為什麼這類測試通常由模型建構者或獨立評估者執行，也是為什麼其發現很少能對應到你應用程式中的特定修正。

系統級對手模擬是一個工程問題。你是在問攻擊者能否讓已部署的系統採取行動——讀取不該讀取的檔案、呼叫不該呼叫的工具、花費不該花費的金錢。受測單元是附帶工具、檢索與憑證的代理程式。方法都是熟悉的方法，只是重新設定目標：透過檢索內容而非使用者回合進行注入、工具濫用、由個別看似合理的權限拼湊而成的權限鏈、跨越租戶邊界外洩的資料路徑。輸出是一項發現，包含重現方式、被跨越的邊界，以及一位明天就能變更設定的負責人。

這兩者產出的產物互不相容，而這種不相容具有診斷意義，並非只是令人困擾。模型層級的結果，你的團隊無法「修正」，只能改用其他模型。系統層級的結果，供應商根本無法修正。如果一份報告沒有說明它屬於兩者中的哪一種，你就無法指派其中的任何項目。

一旦模型具備工具，攻擊面會變成什麼樣子

多數團隊仍在測試的攻擊面是提示詞。它也是最不有趣的一個，因為它是模型供應商投入最多心力強化的一個，也是攻擊者最難施力的一個。真正有價值的攻擊面，是應用程式自己加上的那些：代理可呼叫的工具、它讀取的檢索索引、它在對話輪次之間攜帶的記憶，以及輸出通道本身。

工具是語言模型化身為行動者的地方，而有趣的問題從來不是「它能不能呼叫工具」，而是「這個工具原本可以擁有的最小權限是什麼」。一個接受自由文字查詢的工單查詢工具，往往能被誘導去接受另一位客戶的識別碼。檢索是進入模型上下文的內容通道，這意味著任何能寫入語料庫的人——共用磁碟、客服巨集、抓取器能觸及的網頁——都是在寫入提示。記憶把單一回合變成持久狀態：在第二回合埋入的指令，到了第四十回合仍然存在。輸出是模型文字落到某個會詮釋它的地方，而渲染、Markdown、連結預覽，以及與 shell 相鄰的管線，都會詮釋文字。

只測試提示詞的評測案，會回報一份乾淨的結果，卻在錯誤的事情上是對的。

為什麼逐字稿不等於研究發現

一個發現需要具備三個特性，而聊天視窗的截圖並不具備這些特性。第一個是可重現性：從乾淨的狀態再執行一次，它依舊會發生。模型本身是非確定性的，因此可重現性是一個比率，而不是布林值——「十次裡有九次」才算是一項發現，「它只發生過一次」則只是傳聞。第二個是被跨越的邊界：用應用程式自身的說法，而非模型的說法，指出那件不該發生的事。不是「模型態度不佳」，而是「該代理讀取了屬於租戶 B 的文件」。第三個是可追溯至實際影響的嚴重性，而不是取決於測試者的直覺；這正是缺陷門檻（bug bar）存在的目的。

其他一切——對話紀錄、提示詞、模型的推理——都是支持這三者的證據。它本身並不是研究發現，這就是為什麼一個包含兩千條越獄提示詞的語料庫，其價值不如五項可重現、並附有具名對照條件的系統性發現。

AI 紅隊演練與網路紅隊演練分歧的四個地方

從網路或應用程式安全領域轉過來的團隊，往往具備良好的直覺，卻也帶著四個錯誤的假設。

• 沒有可守住的周界。網路互動有一份目標清單；代理互動則是在請求當下，從你可能尚未盤點過的來源所組裝出的上下文視窗。範圍必須以資料來源與工具權限來表達，而非主機名稱。

• 目標具有非決定性。同樣的輸入可能在週二成功，卻在週三失敗。這打破了「一次乾淨重現」的證據標準，迫使你必須報告發生率。

• 攻擊手法就是語言，而語言沒有修補程式。 你可以修正缺少的授權檢查，卻無法「修補」模型可以被說服這件事。語言層面弱點的緩解措施，得靠其他位置的管控機制——例如過濾器、範圍限制、權限邊界——這正是為什麼發現的問題必須指出管控機制，而不只是描述行為。

• 供應商也參與其中。當其他人發布版本時，你的目標就會改變。模型層級的結果僅對你測試的建置有效；若你沒有記錄版本與日期，就等於沒有結果。

如何界定首次合作的範圍

進行得不順利的專案，幾乎總是被界定為「測試 AI」。經得起時程考驗的範圍，看起來更像是這樣：一個代理程式，在預備環境中，搭配生產環境形態的資料與生產環境形態的權限；一份列出五個重要界線的清單（租戶隔離、憑證存取、支出、資料外傳、工具範圍）；明定哪些屬於禁止範圍的作業規則；說明誰有權中止執行的停止條件；以及一份定義好的證據格式，並已先於第一次嘗試達成共識，讓報告是由產出物彙編而成，而非憑記憶重建。

授權值得用一整句話專門說明，因為當目標是自家產品、工具卻屬於他人時，團隊往往唯獨跳過這一項。測試一個並非由你營運的模型、在你不擁有的基礎設施上、用刻意設計來擊破安全防護層的提示詞——這與測試你自己的部署是截然不同的活動，而書面界定的範圍正是區分兩者的關鍵。我們自家資安層級所執行的驗證關卡，存在的理由也是如此：模型層級的授權安全工作，需要雙方都有具名且可問責的當事人。

事件記錄補充了什麼

紅隊演練告訴你目標會做什麼。它無法告訴你在實際場域中會發生什麼，而控制措施的正當性論證，其實正是在實際場域中才得以成立。這正是事件帳冊所填補的缺口——而它所施加的紀律才是有用的部分：沒有至少一項來源的紀錄並不存在，而沒有危害判定的紀錄算不上事件。

把這兩份產出物放在一起看，整個循環就閉合了。紅隊會產出可重現的發現，並指出原本能阻擋它的控制措施。記錄則會告訴你：這個領域中是否已有人碰觸過那條界線、造成的危害是什麼，以及該控制措施在其他地方是否仍守得住。沒有實務先例的發現，是值得修正的假設；沒有可重現發現的實務事件，則是你還無法結案的缺陷。做對這件事的團隊，不再把「我們對模型做了紅隊測試」當成交付成果，而是開始把它視為自家帳冊中的一項輸入。

這留下了一個誠實的結語。AI 紅隊演練無法提供安全保證，任何以此名義販售的服務，賣的都是錯的東西。它產生的是一組你現在已知會被跨越的界線，附上你可以重新執行的證據，並依界線被跨越時會發生什麼事來排序。這已足以用來做決策——而且遠遠勝過一份簡報。