論文閱讀分析｜No Attacker Needed：當共享記憶 Agent 真正出事時，污染你的不一定是攻擊者，也可能只是上一位使用者的脈絡
論文基本資訊
- 論文標題：Unintentional Cross-User Contamination in Shared-State LLM Agents
- 作者：Tiankai Yang、Jiate Li、Yi Nian、Shen Dong、Ruiyao Xu、Ryan Rossi、Kaize Ding、Yue Zhao
- 來源：arXiv
- 年份：2026
- arXiv：https://arxiv.org/abs/2604.01350
這篇 Unintentional Cross-User Contamination in Shared-State LLM Agents 論文講的是一個很值得資安圈警覺、但又很容易被忽略的問題：有些 agent 根本不需要攻擊者，自己就會把一個使用者的「局部正確」脈絡，默默污染到另一個使用者的結果。
過去大家談 agent 風險，通常都把焦點放在 prompt injection、memory poisoning、malicious tool、跨會話植入這些「有人刻意搞你」的攻擊模型上。但這篇論文指出，當 agent 開始在團隊、workspace、企業內部共用長期記憶、共享摘要、共享上下文時，真正麻煩的未必是有人惡意下毒，而是 共享狀態本身把本來只對某個人、某個任務、某個時間點成立的規則，錯當成可普遍重用的知識。
作者把這種失效模式命名為 UCC（Unintentional Cross-User Contamination）。如果用一句白話來講，就是：別人的上下文，開始偷偷替你做決定。
這篇論文想解決什麼？
核心問題非常明確：共享記憶的 agent，到底會不會把 benign interaction 留下來的痕跡，錯用到下一個使用者身上？如果會，嚴重到什麼程度？
這件事之所以重要，是因為今天很多 agent 系統都在追求「持續記憶」與「跨任務效率」：
- 同一個 agent 長時間服務多人
- 透過 memory bank 保留過往互動結果
- 用 shared transcript / persistent context 減少重複工作
- 把前一次任務中的 workflow、格式、判斷規則留給下次重用
這些設計本來是為了效率與延續性，但論文指出，一旦狀態共享沒有處理 scope，就會出現很危險的現象：某個使用者在自己情境下完全合理的定義、縮寫、排序規則、格式偏好，可能被 agent 誤認成通用原則，接著無聲地套到別人身上，導致答案偏掉、分析錯向、甚至工具流程被帶偏。
這篇論文最有價值的地方：它研究的不是攻擊，而是「無人作惡也會出事」
這是本文最值得記住的重點。作者刻意把 UCC 和既有的 memory poisoning / cross-user injection 區分開來：
- 不是有人刻意藏惡意指令
- 不是有人優化 payload 來害後續使用者
- 不是典型 indirect prompt injection
- 而是一段原本局部正確、善意、合理的資訊，被 agent 錯誤升格成可重用知識
這個角度很關鍵，因為它把問題從「防惡意內容」往前推到「管理共享狀態的適用範圍」。也就是說，就算你的 agent 沒被攻擊，仍然可能因為共享記憶設計太粗糙，而持續輸出靜悄悄的錯答案。
作者怎麼定義污染？三種最常見的 contamination 類型
論文把 UCC 分成三類，這個分類很實用，因為它剛好對應到 agent 最常出錯的三個層次。
1. Semantic Contamination（語意污染）
前一位使用者留下的局部定義、解讀方式或 shorthand，被下一位使用者無意繼承。結果不是資料本身錯，而是 agent 對問題意思的理解被帶偏。
例如同一個詞在某任務裡代表過去 12 個月，但在另一個任務裡其實應該是 calendar year；共享狀態如果沒把這個 scope 綁住，agent 就可能沿用錯誤語意。
2. Transformation Contamination（轉換污染）
前一次任務使用過的聚合、去重、過濾、排序、摘要方式，被當成預設流程沿用。這時 evidence 可能都還在，但 資料被怎麼整理、怎麼壓縮、怎麼算 已經不是本次任務真正要的。
對安全分析來說，這種污染很危險，因為很多 CTI / SOC 任務不是缺資料，而是怕資料被用錯方式彙整。
3. Procedural Contamination（程序污染）
這是我覺得最接近 agent runtime 風險的一類：某位使用者曾經要求某種 workflow、某種 tool-use 順序、某種操作慣例，agent 之後就把它當成預設做法。問題不在文字，而在行動模式被繼承。
如果把這件事放到資安場景，它代表的風險很直接：別人的 incident workflow、查詢路徑、過濾門檻，可能會默默決定你今天怎麼 hunt、怎麼 triage、怎麼判風險。
實驗怎麼做？作者挑了兩種共享狀態機制來驗證
這篇論文不是只提出概念，而是真的把 UCC 放進兩種 representative shared-state 機制裡測：
- shared memory bank：類似長期記憶庫，會把先前互動寫成可回收的記錄，再於後續查詢時取回
- shared conversational context：類似多人共用、可持續累積的共享對話上下文
作者分別在這兩種模式下設計污染案例，讓前一位使用者留下 benign 但具局部 scope 的互動痕跡，再觀察後一位使用者在 clean state 與 contaminated state 下的結果差異。這種 controlled comparison 很重要，因為它能把「正常記憶重用」和「有害跨使用者誤用」拆開來看。
最重要的結果：在原始共享狀態下，污染率高達 57% 到 71%
這是本文最刺眼的數字。作者發現，在 raw shared state 的情況下，光靠 benign interaction 就能造成 57% 到 71% 的 contamination rate。
這個結果代表什麼？代表共享記憶不是偶爾出錯，而是如果沒有 scope-aware 控制，它本身就可能是一個高頻錯誤來源。更糟的是，很多錯誤不是明顯爆炸，而是以silent wrong answer 的形式出現：看起來像在正常回答，實際上已經把別人的局部脈絡偷渡進來。
對企業導入 agent 來說，這比 overt failure 更難防，因為：
- 系統不一定報錯
- 使用者不一定知道答案被誰污染
- 管理者也不容易追到是哪一段共享狀態造成誤用
- 結果會被誤認為是模型能力問題，而不是 shared-state design 問題
作者也測了防禦：SSI 為什麼有用，但又不夠？
作者提出一個 write-time defense，叫做 SSI（Sanitized Shared Interaction）。概念很直白：在互動要被寫入共享狀態之前，先做 sanitization，把那些只在局部情境下成立的規則、偏好、格式、程序慣例先清掉；如果清不乾淨，就乾脆不要寫進去。
這個方向很合理，因為它是從寫入點先擋污染，而不是等後面 retrieval 時再猜哪些東西不該讀。
不過論文的結果也很誠實：SSI 在 shared conversational context 上比較有效，但遇到包含 executable artifacts 的 shared state 時，殘餘風險仍然很高。 換句話說，文字級消毒對文字型記憶比較有幫助，但一旦共享狀態裡混進程序、工具結果、可執行工件、結構化工作痕跡，單純 text sanitization 就不夠了。
這個結論對 agentic security 很重要，因為它直接指出：你不能把 shared memory 想成只是另一段 prompt。很多時候它其實更像 runtime artifact store，而 runtime artifact 需要 artifact-level defense，不是只靠 rewrite 文本就能解決。
這篇論文對資安與 AI Agent 的真正啟發
我覺得這篇論文最值得資安團隊帶走的，不只是 UCC 這個名詞，而是它逼大家承認一件事：共享狀態本身就是安全邊界。
在很多 agent 設計裡，大家把安全邊界畫在：
- system prompt
- tool permission
- network egress
- memory injection defense
但這篇論文補上的是另一層：state scope。如果沒有把記憶、摘要、流程、工件清楚標上「這是誰的、在哪個任務有效、到什麼條件就該失效」，那 agent 的共享記憶就會天然傾向把局部知識錯當成公共真理。
放到 CTI / SOC 場景尤其危險，因為這些場景本來就高度依賴上下文與程序：
- 同樣的告警，團隊 A 與團隊 B 的 triage 門檻不同
- 同樣的 threat report，不同 investigation 的聚合方式不同
- 同樣的命名或 shorthand，在不同專案、不同客戶、不同時間窗可能意義不同
如果 agent 把這些都當成可重用知識，就會產生一種非常隱性的 operational drift：你的分析不是被攻擊者騙，而是被前一位同事的工作痕跡悄悄塑形。
我怎麼看這篇論文？
這篇論文很強的地方，在於它沒有再重複「agent 可能被 prompt injection」這條已經很擁擠的論述，而是把焦點轉向更接近 production 的問題：當 agent 真正被多人共用、真的有長期記憶、真的在共享 workspace 裡跑時，錯誤常常不是攻擊觸發，而是架構自然長出來的。
它也提醒了另一件事：persistent memory 並不等於更聰明，很多時候只是更容易把錯誤延續下去。 如果你沒有處理 scope、 provenance、 retention 與 artifact typing，記憶越長，風險不一定越小，反而可能越像一個慢性污染源。
總結
Unintentional Cross-User Contamination in Shared-State LLM Agents 真正點出的，不是某種新花樣攻擊，而是共享 agent 系統的結構性脆弱點：共享狀態如果不懂邊界，就會把善意互動也變成跨使用者風險。
它最重要的結論可以濃縮成三句：
- 共享記憶的 agent，就算沒有攻擊者，也可能高比例地把一個人的局部脈絡污染到另一個人。
- 這種污染不只改文字答案，也會改資料轉換方式與工作流程。
- write-time sanitization 有幫助，但面對 executable artifacts 與程序型殘留時，還需要更細的 artifact-level defense。
如果你正在設計企業內部 agent、SOC copilot、shared analyst assistant，這篇論文值得直接列入必讀。因為它告訴你：真正該防的，不只是壞人怎麼進來，還包括好人留下的東西，會不會在下一輪被系統用錯。
本文由 AI 產生、整理與撰寫。