AI 事件分流程序（AI 鑑識 IR）

為 AI 安全事件之首回應程序：何須立即保存、何須隔離、初始評估檢核表與為 AI 特定事件之升級標準。

AI 事件分流程序

AI 事件之首 30 分鐘決定你是否保存關鍵證據或遺失之、圍堵損害或讓其蔓延，並辨識正確回應者或以錯誤團隊浪費時間。此頁定義為 AI 系統特定之首回應程序。

首 30 分鐘

AI 事件具狹窄證據保存視窗。不同於磁碟映像與網路捕獲持久之傳統系統，AI 證據常易變：推論記錄可能輪換、模型版本可能更新，而對話脈絡視窗於會話結束時被清除。

分流工作流程

1. 1

   確認並加時戳

   記錄偵測之確切時間（UTC）、警報來源（自動化系統、使用者報告、內部發現），與作為分流回應者之你之身分。此開始事件時程。

   Incident ID: AI-IR-2026-0042
   Detected: 2026-03-15T14:32:07Z
   Source: Safety classifier alert (Llama Guard)
   Triage Responder: [Name]
   

2. 2

   保存易變證據

   於採取任何其他行動前，捕獲可能遺失之證據。按易變性順序：

   1. 活躍對話狀態 —— 若事件涉及進行中對話，捕獲含系統提示、所有使用者訊息、所有助理回應與任何工具呼叫記錄之完整對話歷史
   2. 當前模型組態 —— 記錄確切模型版本、系統提示雜湊、temperature、採樣參數與任何活躍介面卡或外掛
   3. 推論記錄 —— 確保推論記錄不即將輪換；若可能延長保留
   4. RAG 索引狀態 —— 若檢索涉及，快照當前文件索引與近期檢索記錄
   5. 工具呼叫狀態 —— 捕獲任何待定或近期工具呼叫、其參數與結果

   見 證據保存 以獲詳細保存程序。

3. 3

   評估範圍與圍堵需求

   決定事件是否為隔離（單一對話、單一使用者）或系統性（影響所有使用者、利用模型或系統提示之缺陷）。

   問題	若是 → 意涵
   任何使用者可觸發此嗎？	系統性 —— 考慮立即圍堵
   其需特定先前脈絡嗎？	可能隔離 —— 繼續評估
   模型正被主動利用嗎？	需緊急圍堵
   模型採取現實世界動作（工具呼叫、API 請求）嗎？	立即評估下游影響
   敏感資料正被暴露嗎？	資料外洩程序可能適用

4. 4

   實作初始圍堵

   基於範圍評估，採取於不破壞證據下停止出血之最小圍堵動作。

   圍堵動作	何時使用	證據影響
   終止特定會話	隔離於一對話	保存所有其他會話
   為已知 payload 加輸入過濾器	辨識特定攻擊模式	低影響；攻擊者可能適應
   啟用增強記錄	需更多資料以評估範圍	無負面影響
   降低模型能力	偵測到工具濫用	限制功能但保存模型
   切換至後備模型	主要模型之系統性漏洞	保存主要模型以分析
   使端點離線	活躍資料外洩或有害輸出	最大中斷、最大圍堵

5. 5

   執行初始嚴重度評估

   以可用資訊套用 嚴重度框架。基於部分資訊之初始分數較無分數為佳 —— 其驅動升級決策。

   即便不完整也記錄你之初始評估：

   ## Initial Severity Assessment (Preliminary)
   - Model Integrity: [score] - [brief justification]
   - Data Exposure: [score or "Unknown - assessing"]
   - Blast Radius: [score] - [brief justification]
   - Reversibility: [score or "Unknown - assessing"]
   - Exploitability: [score] - [brief justification]
   - Preliminary Severity: [level]

6. 6

   分類與升級

   套用 事件分類 分類法並遵循基於嚴重度與類別之 升級路徑。

必須立即保存者

AI 系統產出傳統 IR 中不存在之證據類型。於分流期間遺漏任何這些可使事件不可調查。

關鍵證據檢核表

證據保存指令

為常見 AI 部署模式，這些指令捕獲關鍵易變狀態：

# 捕獲當前模型部署狀態
kubectl get deployment ai-model-service -o yaml > evidence/deployment_state.yaml
kubectl logs ai-model-service --since=1h > evidence/inference_logs.txt
 
# 自組態快照系統提示
kubectl get configmap ai-system-prompt -o jsonpath='{.data}' > evidence/system_prompt.json
 
# 匯出近期對話記錄（應用特定）
# 調整查詢至你之對話儲存
psql -c "COPY (SELECT * FROM conversations
  WHERE created_at > NOW() - INTERVAL '2 hours')
  TO STDOUT WITH CSV HEADER" > evidence/recent_conversations.csv
 
# 捕獲模型版本資訊
curl -s http://model-service:8080/health | jq '.model_version' > evidence/model_version.json

常見分流錯誤

錯誤 1：於保存前嘗試重現

於保存證據前發送提示至模型以「測試」漏洞可：

• 於有狀態系統中修改對話狀態
• 若系統具量基輪換則觸發記錄輪換
• 若攻擊者正監控系統則警示之
• 於 few-shot 或脈絡中學習設定中改變模型行為

錯誤 2：立即更新系統提示

立即「修復」系統提示之直覺可理解但過早：

• 你遺失被利用之版本
• 你無法於無原始下評估修復是否實際運作
• 可能存在提示更新未處理之其他攻擊路徑
• 更新提示可能引入新漏洞

錯誤 3：視系統性議題為隔離

單一使用者之越獄報告可能指示所有使用者可利用之漏洞。於將事件分類為隔離前：

• 搜尋記錄尋找來自其他使用者之類似模式
• 測試攻擊是否需對話特定脈絡
• 檢查漏洞是否於系統提示（系統性）或對話流（可能隔離）

錯誤 4：忽略下游影響

若 AI 模型於事件期間呼叫外部工具、寫入資料庫、發送電郵或發出 API 請求，爆炸半徑延伸至模型本身以外。分流必須含：

• 辨識於事件視窗內進行之所有工具呼叫
• 評估下游系統是否於受損模型輸出上行動
• 決定下游輸出是否需被召回或恢復

初始評估問卷

使用此問卷以結構與報告事件者之初始分流對話。

分流決策矩陣

於初始評估後，使用此矩陣以決定適當回應層級。

相關主題

• 嚴重度框架 —— 為初始嚴重度評估之詳細評分
• 升級路徑 —— 於分流後路由至何處
• 證據保存 —— 詳細證據保存程序
• 記錄分析 —— 分流後調查技術

參考資料

• "NIST SP 800-61 Rev. 3: Computer Security Incident Handling Guide" - NIST（2024）- 為 AI 脈絡改編之分流程序
• "SANS Incident Handler's Handbook" - SANS Institute（2024）- 為安全事件之首回應程序
• "Incident Response in the Age of AI" - Microsoft Security（2025）- AI 特定分流考量