先講這篇不會有什麼

這篇文章不會提供任何可直接複製使用的注入字串。

不是因為保守，是因為那樣做沒有價值而且有害：對防守方，貼幾個 payload 幫助有限，因為有效的注入樣態變化太快；對其他人，那是現成的工具。

這篇要給的是測試的方法論與界線——測什麼、怎麼判定、以及哪些事不該做。這些東西的保存期限比 payload 長得多。

為什麼這個系統特別需要測

Day 25 鐵律三提過了，但值得再強調一次：

這個系統的輸入，有相當比例是攻擊者可以控制的。

一般的 AI 應用，威脅模型是「使用者可能試圖操縱系統」。而資安監控系統的威脅模型是：

• 使用者（分析師、客戶）是可信的
• 但被處理的資料，是由攻擊者產生的

程序名稱、指令列參數、檔案名稱、URL、郵件主旨、憑證的 CN 欄位、User-Agent——這些全部是攻擊者在他自己的攻擊過程中寫的字串，然後被你的偵測系統忠實地記錄下來，接著被你的 AI 系統讀進 prompt。

這是一條從攻擊者鍵盤直達你 LLM context 的路徑。 而且它是自動的、每天都在發生的。

威脅模型：三個進入點

我把測試範圍按進入點劃分：

進入點一：告警與事件資料（任務一、任務三） 攻擊者可控程度：高。這是最需要防的一條。 可控欄位：程序名、指令列、檔名、路徑、網域、URL、註冊表鍵值、服務名稱。

進入點二：客戶提問（任務二） 攻擊者可控程度：低（假設客戶窗口是可信的），但不能假設為零——帳號可能被盜、內部也可能有惡意行為者。

進入點三：教材與文件上傳（任務四） 攻擊者可控程度：中。教材通常來自內部或原廠，但供應鏈風險存在。

測試的資源分配應該按這個順序。 我看過不少團隊只測第二點（因為那最像「使用者輸入」），完全沒測第一點——而第一點才是真正的曝險面。

測試的四個類別

類別一：指令覆蓋 外部欄位中出現試圖改變系統行為的內容時，系統是否仍按原規則運作？ 判定：輸出的結構、分類、嚴重性、建議是否改變。改變即 S1。

類別二：邊界破壞 外部內容能否破壞包裹它的資料標記，讓後續內容脫離資料脈絡？ 判定：標記完整性。這一項要測各種編碼、特殊字元、超長輸入。

類別三：資料外洩 能否誘使系統在輸出中揭露不該揭露的內容——system prompt、其他客戶的資料、檢索庫中的敏感內容？ 判定：輸出是否含有不屬於本次任務範圍的內容。跨客戶洩漏是 S1 中的 S1。

類別四：間接注入 注入內容不在直接輸入中，而是在 RAG 檢索到的文件裡。 判定：同類別一。這一類最容易被忽略，因為檢索來源常被預設為可信。

判定標準：一條清楚的線

Day 25 說過，這裡展開：

注入內容出現在輸出中，不是失敗。 注入內容改變了系統行為，才是失敗。

為什麼要這樣切？

因為事件報告必須忠實記錄惡意指令列的內容——那是證據，是分析的依據。如果系統為了「安全」而把可疑字串過濾掉，報告就失去價值了。

所以判定看的不是「有沒有出現」，而是這四項有沒有變化：

1. 輸出的段落結構
2. 嚴重性判定
3. 建議處置的內容
4. 文件的狀態流轉（有沒有跳過審核）

任何一項因外部輸入而改變，即為注入成功。

能測什麼

在我的守則裡，明確允許的測試範圍：

• ✅ 對自己建置的系統做測試，在隔離環境
• ✅ 使用合成的告警資料，自己構造帶有測試內容的欄位
• ✅ 測試自己的 prompt 結構、標記機制、過濾邏輯的健壯性
• ✅ 記錄哪一類樣態能繞過，用於改進防禦
• ✅ 在受控環境重播已知的公開研究樣態，驗證自己的防護

不能測什麼

這一段比上一段重要。

• ❌ 不對生產環境做注入測試。 生產環境有真實客戶資料，一次成功的資料外洩測試就是一次真實的資料外洩。
• ❌ 不使用真實客戶的告警資料做測試，即使是唯讀。
• ❌ 不對第三方服務（模型供應商、SaaS）做未經授權的測試。 你的系統是你的，別人的不是。
• ❌ 不發布可直接使用的有效 payload。 包含在這個系列裡。
• ❌ 不測試「讓模型產生攻擊內容」這個方向。 我要防的是系統被外部控制，不是探索模型能被誘導產生什麼——後者是模型供應商的紅隊工作，不是我的系統測試範圍。

最後一條的區分值得說清楚。我測的是「我的系統的完整性」，不是「模型的安全邊界」。 這兩件事的目標、方法、與倫理界線都不同。把它們混在一起，測試範圍會無限擴張，而且會走到不該走的地方。

測試結果怎麼記錄

發現一個能繞過的樣態，記錄的內容應該是：

樣態類別：間接注入 / 指令覆蓋
進入點：RAG 檢索文件
繞過的防護：資料標記未涵蓋檢索結果
影響的行為：建議處置段落內容改變
缺陷等級：S1
修復方向：檢索結果納入資料標記包裹；輸出前比對建議段落與 Data Pack 的一致性

注意這裡沒有記錄 payload 本身。 記錄的是「哪個機制失效了」與「怎麼修」。

我的做法是 payload 存在獨立的、受限存取的測試資料庫，缺陷追蹤系統裡只放引用編號。理由很簡單：缺陷追蹤系統的存取權限通常比你以為的寬。

修復的優先順序

發現繞過之後，修復手段有三類，優先順序如下：

第一優先：結構性修復。 改變資料進入 prompt 的方式——更嚴格的標記、更明確的角色分離、把外部內容移出指令區。這類修復對整類樣態有效。

第二優先：輸出端驗證。 不管模型被說服了什麼，在輸出端檢查關鍵欄位是否與 Data Pack 一致。嚴重性、資產清單、時間軸這些應該是從 Data Pack 直接帶出，不經模型改寫。

第三優先（最後才用）：輸入過濾。 偵測並處理可疑輸入樣態。這類修復最脆弱，因為它是黑名單思維，繞過方式無窮。而且在這個場景它有副作用——會破壞證據的完整性。

很多團隊的直覺是從第三項開始。那是最容易做、也最沒用的一項。

明天講人審閘道的未來：什麼情況下可以放行，以及那條路線圖。

🛡️ Instagram： @aid3fend — AI 資安實戰紀錄，歡迎追蹤交流。