AgentSentry 論文閱讀分析：真正該防的不是某段外部內容看起來多可疑，而是它什麼時候開始接管了 Agent 下一步

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

論文基本資訊

• 論文標題：AgentSentry: Mitigating Indirect Prompt Injection in LLM Agents via Temporal Causal Diagnostics and Context Purification
• 作者：Tian Zhang、Yiwei Xu、Juan Wang、Keyan Guo、Xiaoyang Xu、Bowen Xiao、Quanlong Guan、Jinlin Fan、Jiawei Liu、Zhiquan Liu、Hongxin Hu
• 年份：2026
• 來源：arXiv:2602.22724
• 論文連結：https://arxiv.org/abs/2602.22724
• DOI：10.48550/arXiv.2602.22724
• 主題：Agentic Security、Indirect Prompt Injection、Runtime Defense、Temporal Causality、Context Purification、AgentDojo

如果最近 sectools.tw 這串文章，已經一路把 indirect prompt injection、shared memory contamination、tool poisoning、runtime authorization、tool-call boundary 這些主線慢慢串起來，那這篇 AgentSentry 值得補上的位置很清楚：真正麻煩的不是 agent 看見了惡意內容，而是惡意內容什麼時候開始在多步驟流程裡接管下一步決策，而且這個接管往往不是當場爆掉，而是延後幾個 turn 才落地。

我很喜歡這篇 paper 的原因，是它沒有只停在「偵測到可疑內容就全部停掉」那種很保守、但實務上很容易把 agent 一起打殘的防禦哲學。它想回答的是另一個更難、也更接近 production 的問題：如果今天 agent 還是得繼續完成任務，有沒有辦法在 runtime 裡先找出是哪一段外部 context 開始把它帶歪，然後把那段污染切掉，讓 workflow 繼續往 user 原本要的方向走？

這篇論文想解決什麼？

作者的問題設定非常貼近真實世界。現在很多 tool-augmented LLM agent 都會：

1. 接收使用者任務
2. 呼叫搜尋、email、calendar、文件或企業 API
3. 把工具回傳結果寫回 agent state
4. 根據累積起來的 context 再做下一步工具呼叫

問題在於，不可信內容通常不是直接進 system prompt，而是藏在 email、網頁、文件或 tool output 裡面。這些內容一旦被正常地讀進 agent state，就可能在後面的某個決策點突然開始發揮控制力。

也就是說，間接提示注入真正陰的地方，不只是它能混進來，而是它常常符合下面這種節奏：

• 前面幾步看起來都正常
• payload 先被當成普通觀測寫進 context
• agent 照常繼續規劃與呼叫工具
• 直到後面某一步，才突然做出越權或危險動作

這也是為什麼很多只看單一輸入、單一輸出的 guardrail 會失效：它們看得到「這段內容可能有問題」，卻不一定看得出「這段內容到底從哪一刻開始變成了行動上的主因」。

AgentSentry 的核心觀點：把 multi-turn IPI 看成 temporal causal takeover

這篇 paper 最值得記住的一句話，就是作者把多步驟 indirect prompt injection 改寫成一個時間上的因果接管問題。

重點不是內容看起來像不像惡意指令，而是某個工具回傳邊界之後，agent 的下一步到底主要是被 user goal 推動，還是被剛剛那段外部 context 推動。

這個視角很有用，因為它把問題從「語意分類」拉成「決策歸因」。既有很多 defense 的預設都像是在問：

• 這段文字危不危險？
• 這個 action 看起來和 user goal 像不像？
• 要不要直接拒絕？

但 AgentSentry 問的是更接近行為科學的一題：

• 如果把這段外部觀測弱化、遮蔽或做 counterfactual 重跑，agent 還會不會做出同樣的下一步？

如果答案是不會，那就代表這個 action 很可能不是來自原始任務，而是來自被污染的 context。

它怎麼做？兩段式設計：先診斷 takeover，再淨化 context

AgentSentry 的 runtime defense 可以拆成兩個核心階段：

1. Temporal Causal Diagnostics：在每個 tool-return boundary 做受控的 counterfactual re-execution，判斷是哪個邊界開始出現 context takeover。
2. Context Purification：一旦確認 takeover 由外部 context 主導，就只對那一段污染做淨化，保留任務還需要的正常證據，讓 agent 繼續完成工作。

這種設計的價值，在於它不把防禦理解成「發現可疑 → 全停」，而是「發現因果接管 → 精準切除 → 安全續跑」。

第一階段：Temporal Causal Diagnostics 到底在看什麼？

作者把檢查點放在 tool-return boundary，也就是某次工具結果被寫回 agent state、但下一個 action 還沒真正送出的那個瞬間。這個位置抓得很準，因為間接注入最常就在這裡把影響灌進後續流程。

在每個 boundary，AgentSentry 不是只看原始 execution trace，而是做幾組受控重跑，觀察 agent 下一步是否還維持。論文裡有三個很關鍵的技術點：

• controlled counterfactual re-executions：不是完全亂改 trace，而是只針對外部觀測做受控弱化，測試該 action 是否仍然成立。
• teacher-forced shadow replay：避免重跑過程因為軌跡分岔太多，反而搞不清楚 action 改變是因為 attack 還是因為 agent 自己漂移。
• hierarchical control attenuation：不是粗暴刪光內容，而是分層抑制外部觀測裡可能承載控制訊號的部分，盡量保留任務真正需要的資訊。

這整套方法的直覺其實不難懂。你可以把它想成：把 agent 當下這一步拿去做幾次「如果剛才讀到的內容沒有那麼強烈指揮你，你還會不會這樣做？」的實驗。 如果一弱化就不做了，那就很可能代表原本那一步已經被外部內容牽著走。

第二階段：Context Purification 不是清空上下文，而是盡量只清掉控制訊號

很多 defense 最大的問題，是只要懷疑有毒，就直接把整段 context 擋掉、工具停掉、任務結束。這樣的確比較安全，但也很容易讓 agent 失去實用性。

AgentSentry 比較聰明的地方，是它主張：

真正該刪的不是整段工具輸出，而是那部分會把 agent 從 user goal 帶離的控制訊號。

因此它做的是 causally guided context purification。也就是說，只有當 diagnostics 判定當前偏移主要是由外部 context 引起時，才啟動 purification，而且目標不是讓 agent 失明，而是讓 agent 少看見命令、多保留證據。

這個設計很重要，因為在很多真實任務裡，外部內容本身其實仍然帶有完成任務必需的資料。例如：

• email 本身含有要處理的正當資訊
• calendar event 裡有時間、參與者、任務背景
• 文件或網頁裡有 agent 需要的 business data

你不能因為裡面混了一句惡意指令，就把整份內容都丟掉。真正成熟的 defense，不是讓 agent 什麼都不敢讀，而是讓它把資料和命令的權重重新切開。

這篇論文怎麼評估？

AgentSentry 的評測場景不是 toy example，而是放在 AgentDojo 上，橫跨四種 task suite、三種 IPI attack family，以及多個 black-box LLM。這一點很關鍵，因為作者不是在證明「這招對某個自家 agent 剛好有效」，而是在測試：

• 多步驟 agent workflow 裡的 takeover 能不能被定位
• 定位之後能不能不靠 training-time 改模，直接在 inference time 擋下來
• 擋住之後 agent 還剩多少可用性

從論文摘要和正文主結論來看，結果相當亮眼：

• Attack Success Rate (ASR) 壓到 0%
• 平均 Utility Under Attack (UA) 為 74.55%
• 比最強 baseline 高出 20.8 到 33.6 個百分點
• 對 benign task 幾乎沒有額外傷害

這組結果有意思的地方，不只是數字漂亮，而是它對一個老問題給了比較像樣的答案：runtime defense 不一定只能靠暴力拒絕來換安全。

它和近期幾篇 agent security paper 差在哪？

如果把它放回最近這批 sectools.tw 已經寫過的脈絡裡，AgentSentry 的位置其實很漂亮。

• 和 ClawGuard 相比：ClawGuard 比較像把防線建在工具呼叫前的外部邊界，靠規則、sanitization、skill inspection 和 human approval 把危險 action 卡住；AgentSentry 則更像是往內一步，去分析哪一段上下文從何時開始劫持了 decision process，然後嘗試在不終止任務的前提下把流程拉回來。
• 和 BackdoorAgent 相比：BackdoorAgent 強調 trigger 可能沿 planning、memory、tools 三個階段持續傳播；AgentSentry 則提供了一種比較 runtime-oriented 的回答：如果污染已經進到軌跡裡，怎麼在 execution 過程中找到 takeover 發生點並局部修復。
• 和那些純 classifier 型 prompt injection defense 相比：它不是只看某段文字像不像攻擊，而是看那段文字對下一步行為的因果影響到底有多大。

換句話說，這篇 paper 真正把 discussion 從「內容審查」往「決策歸因」推進了一步。

我覺得這篇最值得記住的，不是 0% ASR，而是這個防禦哲學

如果只能留下一個 takeaway，我會選這句：

多步驟 agent 的安全問題，很多時候不是該不該讀外部內容，而是要不要讓外部內容在未被驗證的情況下持續主導未來的動作。

這句話很重要，因為它把很多 agent security 討論從「有沒有 prompt injection」拉回更本質的地方：context influence 到底有沒有被治理。

對真實部署來說，AgentSentry 其實也順手提醒了三件事：

• 不要把 tool output 直接等同可信世界狀態
• 不要只在 final response 做安全檢查
• 不要把所有 runtime defense 都設計成 stop-the-world

如果你今天真的想把 agent 放進 email、calendar、knowledge worker 或 enterprise workflow，這三點比任何單篇 benchmark 分數都更重要。

這篇論文的限制是什麼？

當然，這篇 paper 也不是沒有代價。

第一，counterfactual re-execution 本身就意味著額外延遲與成本。只要你每個 tool-return boundary 都要多做幾次 shadow replay，runtime overhead 就不可能不存在。作者有把 utility 保住，但 production 裡能不能承受，還是要看場景。

第二，這套方法比較適合可重放、可觀測、具明確邊界的工具流程。如果任務涉及高度即時互動、不可逆外部副作用或難以重播的環境狀態，實作難度會上升。

第三，它雖然比粗暴拒絕更細，但本質上仍然建立在「我們能透過受控弱化看出外部 context 的控制力」這個前提上。當攻擊越來越會把惡意指令藏在表面很像正常商業資料的結構裡時，purification 能不能一直維持高 utility，還需要更多驗證。

總結

AgentSentry 值得看的地方，不是因為它又多發明一種 guardrail，而是因為它把 agent 的多步驟間接注入風險，重新整理成一個更精確的 runtime 問題：哪一段外部 context、從哪個時間點開始，已經不只是被讀到，而是開始主導行動。

這個 framing 很強，因為它讓防禦不必只在兩個極端之間選邊：

• 要嘛完全相信模型自己能分辨好壞
• 要嘛一看到可疑就全部停機

AgentSentry 提供的是第三條路：在 runtime 裡做因果診斷，找 takeover、切污染、保留證據、繼續任務。

如果說 ClawGuard 把防線立在工具邊界，BackdoorAgent 提醒我們污染會沿 workflow 活下去，那 AgentSentry 則是在回答另一個非常實際的問題：當污染已經進來了，agent 還有沒有機會在不放棄任務的前提下，把方向盤搶回來？

我的答案是：至少從這篇 paper 看來，有，而且這條路比單純再做一層 prompt filter 更像未來。