Context / Memory Poisoning

上下文污染是什麼，跟提示注入有什麼不同？

提示注入是單次、當場發生的攻擊——攻擊指令出現在某一次互動裡，session 結束後影響通常也隨之結束。上下文污染則是攻擊者把假資料寫進 Agent 具有持續性的儲存層（向量資料庫、RAG 索引、長期記憶、對話摘要），這筆假資料會跨越 session 存在，在未來任何一次調用到這個記憶片段的互動裡都可能被引用，而且往往在攻擊者完全沒有直接參與的後續互動中被觸發。

這個差異決定了兩者的防禦邏輯完全不同：提示注入的防線在「輸入時」把關，上下文污染的防線則必須延伸到「儲存內容本身是否可信」，因為受害的不是某一次對話，而是 Agent 之後所有依賴這個記憶庫的判斷。

上下文污染為什麼會出現，是什麼原因造成的？

核心原因是 Agent 系統為了提升表現，普遍採用長期記憶或 RAG 檢索機制——讓 Agent 記得過去互動的內容、參考過去成功處理過的案例，這確實能提升準確度與效率，但也意味著任何被寫進這個記憶層的內容，都會被 Agent 當作可信來源反覆使用。多數系統在設計時對「這筆記憶是誰寫入的、可信度多高」缺乏追蹤機制（provenance tracking），記憶庫裡的資料一旦混入，很難跟原本合法寫入的內容區分開來。

另一個推力是攻擊門檻其實不高：2025 年 NeurIPS 發表的 MINJA 攻擊證明，攻擊者甚至不需要取得記憶儲存層的直接寫入權限，只靠正常的互動查詢，就能讓污染內容側寫進 Agent 的長期記憶，對多個生產環境的 Agent 架構達到超過九成五的注入成功率。

上下文污染具體怎麼運作，攻擊者實際上做了什麼？

典型模式是攻擊者在一次看起來完全正常的互動中，讓 Agent 把一筆偽造但格式跟真實記錄一模一樣的內容存進記憶庫——例如偽裝成一筆「過去成功處理過的案例」或「已核實的事實」。這筆資料存進去之後不會立刻造成任何異常，因為它還沒被任何後續查詢調用到；直到某個未來、完全不相關的使用者發出一個會觸發檢索這筆記憶的查詢，Agent 才會把這筆假資料當成可信依據引用出來，這時距離植入可能已經過了相當長一段時間，表面上看起來像是 Agent「無緣無故」突然做出奇怪判斷。

攻擊面主要集中在四個入口：Agent 主動爬取或索引的外部內容（RAG 來源）、長期記憶儲存、工具描述本身被竄改（tool poisoning）、以及多 Agent 系統裡從其他 Agent 傳遞過來的訊息。其中 RAG 來源是最容易被低估的一環，只要 pipeline 沒有做內容驗證，任何攻擊者能夠影響的內容都可能被索引進資料庫；一項針對 tool poisoning 的基準測試對 20 個主流 Agent 進行測試，記錄到攻擊成功率達七成以上，且能力越強的模型往往因為更擅長遵循指令，反而更容易中招。

上下文污染對我有什麼影響，該怎麼判斷是否已經中招？

如果你的 Agent 使用任何形式的持續性記憶（RAG、向量資料庫、對話摘要、跨 session 的使用者偏好），這個風險會隨著記憶使用時間拉長而累積——記憶庫用得越久、寫入的內容越多，被污染而未被發現的機率也越高，而且污染源頭往往跟症狀發作的時間點相隔甚遠，事後追查會比一般資安事件困難許多。

可觀察的警訊包括：Agent 偏好使用的工具突然出現無法解釋的轉變、決策路徑偏離過去建立的模式、API 呼叫失敗率異常上升——這些都可能是上下文已遭污染的行為訊號，而不是單純的模型表現波動。防範上，比較根本的做法是對記憶內容建立來源追蹤（誰寫入的、什麼時候寫入的、可信度如何），並依信任層級分區儲存記憶——例如把系統層級的政策設定、已驗證事實放進唯讀分區，需要人工審核才能異動，跟使用者對話產生的一般記憶分開存放，同時定期用一個獨立的、值得信任的模型稽核記憶庫，找出格式正常但內容跟已知事實矛盾的異常項目。