SecTor 2025 | Investigate & Respond to Attacks on GenAI Chatbots
三句話摘要
從三個真實場景出發，教你如何對 AI 聊天機器人遭受攻擊時進行事件調查與應變。 記錄用戶輸入、Guard rail 分數與工具執行 I/O 是 AI 聊天機器人事件應變的基礎建設，沒有這三者，任何攻擊都無從調查。 風險分級決定事件類型：低風險機器人（只提供通用資訊）主要面臨品牌損傷；中風險（存取個人化資料）可能洩漏 PII/PHI；高風險（可執行操作）則可能造成遠端代碼執行或未授權存取，分級思維是調查優先序的基礎。
重點整理
重點- 1
風險分級決定事件類型：低風險機器人（只提供通用資訊）主要面臨品牌損傷；中風險（存取個人化資料）可能洩漏 PII/PHI；高風險（可執行操作）則可能造成遠端代碼執行或未授權存取，分級思維是調查優先序的基礎。
- 2
LLM-as-Judge 分數是調查入口：盲目逐一閱讀用戶輸入沒有效率，應先利用 Judge 的分數分佈找出時間節點，再聚焦「攻擊前後 Judge 分數漂移」與「規則型過濾和 LLM Judge 決策之間的落差擴大」，這兩個訊號代表攻擊正在逐步突破防線。
- 3
Prompt Injection 本質等同 SQL Injection：系統提示詞（System Prompt）無法完全阻止用戶提示詞（User Prompt）主導模型行為，尤其當 LLM 連接外部工具（Python 執行器、API、MCP Server）時，未經驗證的用戶輸入直接流入工具執行層，後果等同 RCE。
- 4
訓練資料洩漏難以偵測，RAG 權限管理是盲點：模型反轉攻擊（Model Inversion Attack）的查詢語句看起來平凡，且可分散於長時間避開閾值警報；RAG 資料源往往只記錄 URL 指標而非當時快照，事後根本無法還原洩漏當下的資料內容。
實用技巧與重點
乾貨- 風險分級：低（通用資訊）→ 品牌損傷；中（個人化資料）→ PII/PHI 洩漏；高（可執行動作）→ 未授權存取、RCE
- 必記日誌欄位：user_prompt、message_thread_id、web_session_id、chatbot_output、LLM model name & version、timestamp、chatbot_version、guardrail 分數
- 攻擊手法一：Emoji Attack：在文字中插入 Emoji 或異常 Unicode，使 tokenizer 拆字方式改變，導致 Judge 無法辨識原本應封鎖的詞彙（如 "Tay🔥lor" 被拆為兩個 token）
- 攻擊手法二：記憶污染（Memory Poisoning）：更新用戶長期記憶（Persistent Memory），使後續自動注入至 System Prompt 的內容繞過 Judge 偵測
- 攻擊手法三：Prompt Injection → RCE：事件規劃機器人將數學計算委派給 Python，攻擊者提交含 `subprocess.run(curl ...)` 的「數學題」，觸發任意命令執行
- 攻擊手法四：Model Inversion Attack：反覆提問精煉問題，從 LLM 重建原始訓練資料中的 PII
- 工具：LangChain LLM Math tool（有已知安全疑慮）、Plotly 動態代碼生成（Vanna/JFROG 研究案例）、Vanna Python 套件
- 防禦層次：規則型過濾（Regex）→ LLM-as-Judge（數值評分 + 閾值）→ System Prompt 強化 → 工具輸入/輸出驗證 → 訓練資料清洗 → RAG 權限控管 + 歷史快照
- RAG 日誌建議：記錄指標/URL（非完整資料），但資料源本身需支援時間點還原（archival）
- Playbook 調查順序：可疑 User Prompt → Guard rail 分數分佈 → 對應 Output → Tool 執行 I/O → 資料源審查 → 遏制（規則過濾 → Judge → System Prompt 更新 → 用戶輸入消毒）
結論
結論“記錄用戶輸入、Guard rail 分數與工具執行 I/O 是 AI 聊天機器人事件應變的基礎建設，沒有這三者，任何攻擊都無從調查。”
完整解析
詳細Gen AI 聊天機器人正快速普及，但大多數企業的事件應變團隊尚未針對它建立標準作業程序。Airbnb 資深工程師 Alan Sto 在這場演講中，從事件調查者的視角切入，以三個場景逐步拆解機器人可能遭受的攻擊鏈，並在最後提出一份通用的 Playbook 框架。
第一個場景是低風險的天氣機器人，突然對所有用戶回應泰勒絲主題的天氣預報。調查起點是日誌：若沒有記錄用戶輸入、對話 ID、Guard rail 分數，根本無從追蹤攻擊路徑。調查後發現，攻擊者利用機器人的正向回饋機制（強化學習），大量提交含有泰勒絲主題的請求並對回應按讚，逐漸讓模型「學到」這種輸出是被獎勵的。初步以規則型過濾（Regex）封鎖名字無效，因為攻擊者接著改用 Emoji Attack——在關鍵詞中插入 Unicode 特殊字元，打亂 tokenizer 分詞邏輯，使 LLM Judge 無法識別本該攔截的詞彙。更進一步，攻擊者還污染了機器人的長期記憶，讓污染後的指令在每次對話中自動注入至 System Prompt，形成持久性影響。這個場景教導我們：機器人的輸入遠不止「用戶當下打的字」，回饋管道與記憶都是攻擊面。
第二個場景是高風險的活動規劃機器人，EDR 告警顯示其 EC2 實例正向惡意 IP 發出 curl 請求。查詢日誌後找到關鍵：攻擊者提交了一個偽裝成數學算式的 Prompt，實際內容是含有 `subprocess` 呼叫的 Python 代碼。原來開發者為了讓機器人精確計算，在 System Prompt 中指示 LLM 把所有數學題轉成 Python 再執行，卻未對用戶輸入做任何驗證。這是 Prompt Injection 的典型模式——本質上和 SQL Injection 一樣，只是把不受信任的用戶輸入與受信任的 System Prompt 拼接在一起。更關鍵的是，由於 LLM 輸出天生不具確定性，若沒有事先記錄工具的輸入輸出，事後試圖重建攻擊行為幾乎不可能。LLM 連接工具的能力越來越強（MCP、跨 LLM 呼叫），每個工具都是潛在的攻擊落點。
第三個場景是理論上「低風險」的醫療諮詢機器人，卻在暗網出現病患資料。調查後發現 AI 團隊對訓練資料的匿名化處理不完整，攻擊者透過模型反轉攻擊（Model Inversion Attack），以平凡無奇的問題逐步探詢，重建出原始訓練集中的 PII。這類攻擊難以偵測，因為單一查詢看起來完全合理，且可分散在數天、數週的時間內進行，不觸發任何量化閾值。演講者同時提醒，RAG 架構雖然讓機器人可以存取外部資料庫、Google Drive 等動態資料源，但若日誌只記錄 URL 而非當下資料快照，事後根本無法確認洩漏當時的資料內容。
綜合三個場景，演講者歸納出 Playbook 的核心調查流程：先從 Guard rail 分數異常找到攻擊時間窗口，再聚焦可疑 Prompt → 對應 Output → Tool 執行 I/O → 資料源審查。防禦要分層：規則型過濾快速遏制、LLM Judge 精確評估、System Prompt 設定明確拒絕條款、工具輸入前驗證、訓練資料清洗，以及 RAG 資料源的時間點快照能力缺一不可。最重要的是，這些準備工作應在事件發生前完成，包括讓公關、法務等非技術團隊也理解 LLM 的運作原理，否則在戰情室裡解釋什麼是 RAG 只是浪費寶貴的應變時間。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
