Cross-Session Threats 論文閱讀分析：很多 agent 真正缺的，不是更大的 context，而是別把碎片當安全

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Cross-Session Threats in AI Agents: Benchmark, Evaluation, and Algorithms
• 作者：Ari Azarafrooz
• 年份：2026
• 來源：arXiv:2604.21131
• 論文連結：https://arxiv.org/abs/2604.21131
• DOI：10.48550/arXiv.2604.21131
• 主題：Agentic Security、Cross-Session Detection、Prompt Injection、Memory Security、Benchmarking、Runtime Monitoring

這篇 Cross-Session Threats in AI Agents 最值得看的地方，不是它又多發明一種 prompt injection，而是它終於把一個大家其實早就碰到、卻常常假裝還能用舊方法處理的問題講白：

很多 agent guardrail 真正的盲點，不是單次對話看不懂，而是每一輪都各自看起來沒事，合起來卻早就出事了。

這就是 cross-session threat 的核心。攻擊者不再把 payload 一次塞進來，而是把它拆成很多段、很多 session、很多角色，甚至很多看起來完全正常的任務片段。你每一段單看都覺得還好，但當某個累積面把這些碎片重新拼起來時，事情就已經不是「一則危險訊息」而是一條已經活起來的攻擊路徑。

這篇在打哪個痛點？

作者的問題意識很準：agent 時代的威脅越來越有狀態，但 guardrail 還是無狀態。

現在很多防線還停在這種模型：

• 每則訊息獨立判斷
• 每次 session 重置就重新開始
• 看單條 prompt 有沒有違規字眼或危險意圖

但真正麻煩的攻擊開始長這樣：

• slow-drip prompt injection：把 jailbreak 拆成很多次、每次只放一小片
• compositional exfiltration chain：這次列檔、下次讀 config、再下次摘要、最後另一次送出去
• mosaic reconstruction：每個問題都像正常探詢，但很多次之後就拼出敏感結構
• cross-agent laundering：先讓一個 agent 產生髒資料，再讓另一個 agent 當成普通輸入接手

這些攻擊最陰的地方是：單點看都很乾淨，只有整體有毒。

作者的關鍵提醒：很多「跨 session 攻擊」真正的累積面，甚至不在 agent 記憶本身

這篇一個我很喜歡的點，是它沒有把 cross-session threat 只理解成 memory poisoning。作者把累積面講得更廣，這才像真實系統：

• persistent memory / RAG index
• shared multi-agent scratchpad
• human reviewer 的連續注意力
• 被工具改寫的資料庫欄位
• 共享 bucket 裡的檔案
• scheduler queue
• 下一個 agent 會再讀到的 environment / side effect

也就是說，cross-session risk 的重點不是「聊天視窗有沒有保留」，而是系統裡有沒有任何會跨回合、跨流程、跨代理保留狀態卻不保留來源脈絡的面。

這也是作者一直在打的一個點：很多風險不是單純的 memory accumulation，而是 semantic laundering。敏感東西進系統時是祕密，繞幾輪之後變成一段看似中性的摘要、報告、設定值、待辦事項，最後再被正常流程送出去。整條路上沒有一個點會大聲告訴你：「這其實還是髒的。」

這篇最重要的，不只是 benchmark，而是把問題正式化

論文做了三件事，但我覺得第一件最重要：它把 cross-session threat detection 從模糊直覺拉成可被測量的問題。

作者提出的 CSTM-Bench（Cross-Session Threat Memory Benchmark）不是隨便丟幾段對話，而是明確把攻擊按兩條軸線分類：

• kill-chain stage
• cross-session operation ontology：accumulate、compose、launder、inject_on_reader

這個切法很有價值，因為它在說：cross-session threat 不只是「拖很久的 prompt injection」，而是可以進一步拆成：

• accumulate：慢慢累積碎片
• compose：把看似無害的步驟串成有害流程
• launder：把髒東西洗成正常脈絡
• inject_on_reader：不是寫入時中毒，而是讀取/審閱時才被帶偏

這讓評估不再只是「有沒有抓到」，而是能看出你到底對哪一種跨 session 風險還是瞎的。

作者對現有做法的批判很狠，而且我覺得是對的：full-log correlator 也不夠

很多人看到跨 session 問題，第一個反應會是：那就把所有歷史 log 全串起來，一次丟給長 context LLM 不就好了？

這篇的回答是：不，這樣不夠，而且會在你最想抓的地方開始失靈。

作者拿三種 reader / judge 做比較時，最重要的訊號不是某個數字有多高，而是這個結論：

不管是每 session 單獨 judge，還是把全部 prompt 硬串起來的 full-log correlator，遇到真正 isolation-invisible 的 cross-session shard 時，attack recall 都會掉很兇。

更關鍵的是，這不是因為 context window 不夠大。論文明講：這些案例的累積 token 壓力還在 frontier model 可處理範圍內，退化主要不是 truncation，而是在長而連貫、但每段都很像正常工作的對話裡，相關訊號被稀釋掉了。

這個觀察很重要，因為它在提醒大家：長 context ≠ 長期威脅理解。

為什麼 bounded-memory coreset reader 比「全都留著」更像正路？

論文提出的方向，不是把所有東西留更久，而是做一個 Coreset Memory Reader：在有限容量下，只保留最高訊號的 cross-session fragments，再餵給下游 correlator。

這其實很有味道。因為它承認一個現實：

• 真正的問題不是資料太少
• 而是雜訊太多，且威脅訊號藏在看似正常的長對話裡

所以核心不是 all history retention，而是訊號保留品質。作者甚至把 ranker 穩定性拉成一級公民，提出 CSR_prefix（ordered prefix stability）這種偏 serving / runtime cost 導向的指標。這點我很買單，因為很多論文只談偵測率，不談 production 代價；但 real-time cross-session detection 真要上線，排名器如果一直 reshuffle，就會把 KV-cache prefix reuse 打爆，成本直接爬上去。

換句話說，這篇不是只在問「抓不抓得到」，而是在問：

你用什麼方式保留跨 session 高價值片段，才不會一邊抓，一邊把線上 serving 成本自己炸掉？

這篇最值得帶走的觀念：agent threat detection 要從 event correlation 轉成 intention-time correlation

作者有一段 framing 我覺得非常準：SIEM 是為事件設計的，但 agent 往往先洩漏的是意圖。

這句話很關鍵。傳統偵測系統習慣在事情發生後看：

• failed login
• suspicious network flow
• process spawn
• file write

但 agent 世界裡，很多高風險事其實會先在 prompt / tool-use intention 層浮現。像是：

• 先整理 config 再送到某個 endpoint
• 先列資料夾再摘要憑證內容
• 先要求子代理整理某些敏感資訊再回傳

也就是說，真正的 threat signal 常常在 log 還沒產生前就已經存在，只是被分散在很多輪、很多流程、很多看似合理的操作裡。這種情況下，等你把所有東西送去 SIEM 再查，很多時候已經太晚。

這篇論文的價值，不在說「大家都該用 coreset」，而在把新的失效模式講清楚

我不覺得這篇的重點是某個特定演算法一定最好。它更大的價值，是把新的失效模式講得夠清楚：

• session-bound judge 看不到 aggregate threat
• naive full-log correlator 會在長對話與稀釋場景裡失靈
• 只看 action 後事件 常常比 intention signal 慢半拍
• 只留資料不留 provenance 會讓 laundering 更容易成功

這些點其實比單一榜單更重要，因為它們直接在改大家該怎麼設計防線。

限制也很明顯：這還是第一代資料集，別拿它當最終定論

論文自己也有自知之明：這次 release 的規模、模型家族、prompt optimization 都還有限。作者明講這比較像是 first-order characterization，不是在替所有模型和方法排最終名次。

我覺得這種誠實反而好。因為 cross-session threat 本來就不是一個靠一份 benchmark 就能封死的問題。比較合理的理解是：

• 這篇先把 problem surface 做出來
• 先證明 session-bound 與 naive long-context 確實有結構性缺口
• 再給出一個偏務實的 bounded-memory 方向

我的看法：這篇真正補到的，是 agent 安全從「看單句」走向「看軌跡」的那一步

很多 agent security 研究現在還是太習慣問：

• 這句 prompt 有沒有毒？
• 這個 tool description 像不像 injection？
• 這次 action 單看危不危險？

但 cross-session threat 在逼大家承認：很多真正危險的事，根本不是一句話做成的，而是一條軌跡慢慢長成的。

所以這篇我最喜歡的地方，是它把防線重心往 trajectory / accumulation / provenance 拉，而不是繼續沉迷單次分類。這比又多打一個 jailbreak prompt 更接近 production 世界。

結語

如果要把這篇濃縮成一句話，我會這樣寫：

很多 agent 真正缺的，不是更大的 context window，而是別再把每一輪都看起來沒事，誤認成整條路真的沒事。

Cross-Session Threats in AI Agents 真正重要的，不只是它提出 CSTM-Bench 或某個 coreset reader，而是它提醒大家：當攻擊已經學會跨 session 生長，防禦如果還只會逐條看訊息，就等於每次都只盯著碎片，卻假裝自己看得見整張圖。

對 agentic security 來說，這篇不是終點，但很像是從 stateless guardrail 走向 stateful runtime defense 時，該先補上的一塊底座。