BackdoorAgent 論文閱讀分析：真正危險的不是單步被騙，而是 trigger 沿著 agent workflow 一路活到最後

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

論文基本資訊

• 論文標題：BackdoorAgent: A Unified Framework for Backdoor Attacks on LLM-based Agents
• 作者：Yunhao Feng、Yige Li、Yutao Wu、Yingshui Tan、Yanming Guo、Yifan Ding、Kun Zhai、Xingjun Ma、Yu-Gang Jiang
• 年份：2026
• 來源：arXiv:2601.04566v2
• 論文連結：https://arxiv.org/abs/2601.04566
• DOI：10.48550/arXiv.2601.04566
• 主題：LLM Agent Security、Backdoor、Memory Poisoning、Tool Manipulation、Workflow Security、Agent Benchmark

如果前面幾篇 sectools.tw 已經一路把 prompt injection、skill supply chain、shared memory contamination、runtime authorization 這些主線鋪開，那這篇 BackdoorAgent 值得補上的位置非常關鍵：真正麻煩的，不只是 agent 會不會在當下被騙，而是攻擊者能不能在 agent workflow 的某個環節偷偷埋一個 trigger，然後讓這個 trigger 在後面幾步、甚至跨模組地持續生效。

這篇 paper 的價值，不在於它單獨又發明了一種新攻擊，而是在於它把原本很零碎的問題重新整理成一個更貼近 agent runtime 的視角：對 agent 來說，backdoor 不該只被看成模型層或資料層的單點風險，而是 planning、memory、tool use 三個功能階段之間會互相放大的工作流風險。

這篇論文到底在處理什麼問題？

作者一開始點得很準。LLM agent 跟單輪聊天模型最大的差別，不只是它可以用工具，而是它會把很多中間產物反覆寫回自己的上下文或狀態裡，例如：

• 規劃出的推理步驟與 action plan
• 從 memory / RAG 撈回來的內容
• tool 執行後得到的輸出與環境回饋

這些東西一旦被寫回去，就不再只是一次性的觀測，而會變成下一步決策的依據。也就是說，agent 的風險不是單一步驟錯一次，而是錯誤會沿著 workflow 被重複引用、放大、累積。

因此，作者要回答的核心問題其實是：

如果攻擊者把 backdoor trigger 埋在 agent 的 planning、memory 或 tools 任一階段，那這個 trigger 會不會一路傳到後續步驟，最後把整個任務導向攻擊者想要的結果？

這個問題很重要，因為它比「某個 prompt 會不會讓模型講錯話」更接近真實世界風險。在 agent 系統裡，真正昂貴的錯誤通常不是嘴巴講錯一句，而是agent 開始替你做錯事，而且做錯時看起來還像在正常完成任務。

BackdoorAgent 的核心觀點：把 agent workflow 拆成三個攻擊階段

這篇 paper 最值得記住的設計，就是把 agent workflow 的攻擊面拆成三個功能階段：

1. Planning attacks：污染 agent 的規劃、reasoning trace 或 action plan。
2. Memory attacks：把 trigger 放進 memory、RAG、knowledge store 或被取回的內容裡。
3. Tool-use attacks：透過工具回傳值、外部觀測或環境反饋，把錯誤訊號重新灌回 agent。

這個切法很實用，因為它不再把風險抽象化成「模型中毒了」這種太粗的說法，而是直接對應 agent architecture 的三個實際模組。作者甚至用一組簡潔的 workflow 公式描述 agent 的運作：

Planning -> Memory -> Tools
      \        |        /
       ---- 回寫到 context / state ----

也就是說，planning 產生的中間結果會被留下來、memory 撈回的內容會被引用、tools 回來的輸出也會繼續影響下一步。一個 trigger 只要在其中一個節點成功植入，就有機會透過 state update 與 context accumulation 持續存活。

這篇論文不是只談概念，而是真的做了一個標準化 benchmark

BackdoorAgent 不只是框架，它還配了一個標準化 benchmark，涵蓋四種代表性的 agent 任務：

• Agent QA：retrieval-grounded 的多步問答場景
• Agent Code：有 execution feedback 的迭代式程式生成
• Agent Web：需要看畫面、操作介面的多模態 web agent
• Agent Drive：帶有環境回饋的閉環 sequential decision-making

這四個任務選得很聰明，因為它們幾乎把今天大家最愛講的 agent 使用情境都涵蓋進來了：

• 知識工作型 agent
• coding / engineering agent
• browser / UI agent
• 具身或環境互動型 agent

更重要的是，作者不是只看「會不會被騙」，而是對每種任務都定義了更具體的攻擊目標：

• Agent QA：讓 agent 給出攻擊者指定的錯誤答案，但表面上仍像在正常推理
• Agent Code：誘導 agent 生成帶有破壞性操作的程式，例如刪資料庫或做危險動作
• Agent Web：讓 agent 在 UI 上點錯、買錯、選錯，但看起來仍像在完成任務
• Agent Drive：透過小擾動把 agent 導向危險控制行為，例如不安全停止

這一點很關鍵，因為它把 backdoor 風險從「抽象的 model misbehavior」拉回到具體任務目標被劫持。

作者整理了哪些既有攻擊？

論文裡把七種代表性攻擊放進同一個 taxonomy：BadChain、BadAgent、PoisonedRAG、TrojanRAG、AgentPoison、DemonAgent、AdvAgent。這些攻擊各自落在不同模組，有些偏 planning、有些偏 memory、有些偏 tools / environment。

這樣做的好處是，研究不再停在「我這一招很強」的單點比較，而是能跨攻擊類型問更重要的問題：

• 哪一個模組最容易成為持久化 trigger 的入口？
• 哪種攻擊最容易跨步驟擴散？
• 不同 backbone family 面對不同模組時，脆弱性是否一致？

這比單獨比較某一篇 RAG poisoning paper 或某一篇 agent planning hijack paper 更有價值，因為它開始逼大家從整條 agent execution path 思考防禦。

最值得記下來的結果：memory-based attacks 幾乎是系統性最危險的面

這篇 paper 最有殺傷力的結果，來自它把多種任務、多個模型家族聚合後做的 module-level 比較。

作者在 family-level aggregation 裡，把攻擊依照注入通道分成 planning、memory、tools 三類，得到的平均 attack success rate（ASR）非常值得直接抄下來：

• GPT family：planning 43.58%、memory 77.97%、tools 60.28%
• Claude family：planning 10.43%、memory 54.82%、tools 23.07%
• Gemini family：planning 39.49%、memory 75.39%、tools 48.98%
• Qwen family：planning 35.41%、memory 55.45%、tools 54.45%
• DeepSeek：planning 27.84%、memory 38.91%、tools 42.20%

這組數字的訊號非常清楚：memory-based attacks 在幾乎所有模型家族上都最穩、最危險。 這不是巧合，而是因為 memory / retrieval 內容一旦被取回，往往會被 agent 當成可信上下文，不只會影響當前步驟，還可能被重新寫回後續狀態，形成持續污染。

換句話說，這篇 paper 實際上是在替最近整波 agent memory / RAG security 敲一個更響的警鐘：對 agent 來說，memory 並不是「幫模型補知識」那麼簡單，它本身就是最容易變成持久性控制面的攻擊入口之一。

另一個更麻煩的發現：高任務準確率，不代表低可操控性

作者反覆強調的一件事，我覺得非常值得安全團隊直接帶回去用：agent 可能一邊維持看起來還不錯的 task accuracy，一邊已經高度可被控制。

這意味著如果你只用一般 benchmark 的「正確率」、「成功率」、「pass rate」來看 agent 表現，很可能會得到一個危險錯覺：覺得系統表現不錯，所以應該也算安全。但 BackdoorAgent 的結果剛好相反——有些情況下，agent 仍然看起來像在正常完成任務，卻已經被 trigger 導向攻擊者指定目標。

這種behavioral correctness 與 controllability 脫鉤，其實正是 agent 安全最麻煩的地方。因為在真實環境裡，很多事故不是模型整個壞掉，而是它「大致正常，只在關鍵點上被推歪」。

為什麼 sequential / closed-loop agent 特別危險？

論文還有一個很值得注意的觀察：順序決策型 agent 的放大效應，比 QA 或 Code 場景更嚴重。

作者拿 Agent Drive 去和 Agent QA、Agent Code 比較，發現 closed-loop sequential setting 特別容易讓小型 trigger 變成大偏航。原因很直白：在這種系統裡，每一步受到污染的 plan 或工具回饋，都會直接改變下一步的 state；錯誤不是停在當下，而是沿著狀態轉移一路滾大。

這個結果非常值得今天所有在做 browser agent、robotics agent、autonomous SOC agent、甚至自動修補 agent 的團隊注意。因為只要你的系統是：

• 多步驟
• 有持續狀態
• 會吃回自己的輸出或環境回饋

那它就天然更接近 BackdoorAgent 警告的風險模型。

這篇 paper 對藍隊 / AppSec / AI security 團隊真正的提醒是什麼？

我認為這篇最重要的 takeaway 有四個：

1. 不要再只看 backbone model。 Agent 的風險很多時候不是出在模型參數本身，而是 workflow 裡資訊如何被回寫與累積。
2. memory / retrieval 是第一級攻擊面。 凡是會被 agent 取回、引用、再寫回的內容，都應該被視為高風險輸入，而不是單純 context augmentation。
3. 單步安全測試不夠。 真正要看的不是某一步有沒有被騙，而是 trigger 能不能跨步驟持續存在、能不能穿越模組邊界。
4. 準確率不是安全性代理指標。 一個看起來很能做事的 agent，依然可能在關鍵路徑上高度可操控。

如果把它放回 sectools.tw 近期一路在寫的主線，我會說 BackdoorAgent 幾乎像是一篇「總結性警報」：agent 的風險已經不只是 prompt injection 那麼窄，而是整條由 plan、memory、tool feedback、state update 組成的執行鏈，本身都可能成為持久化控制面。

我的看法：這篇真正補上的，是「workflow-aware」安全視角

很多團隊現在談 agent security，還是很容易落回兩個舊框架：

• 把它當成單一 LLM safety 問題
• 把它當成傳統 application security 問題

但 BackdoorAgent 告訴我們，這兩個角度都不夠。因為 agent 最特殊的地方在於，它會把中間產物當成下一步世界觀的一部分。一旦這件事成立，安全分析就不能只看輸入輸出，也不能只看模型本身，而要看整條 execution trajectory。

這也是我覺得這篇論文值得被放進近期 agentic security 脈絡裡的原因：它讓「agent runtime security」從一堆零散 attack papers，開始往比較像系統工程的方法收斂。

如果你正在設計自己的 agent platform，這篇 paper 最值得帶回去問的，不是「我要不要防某個 trigger」，而是：

我的 agent workflow 裡，哪些中間狀態會被保留？哪些內容會被再利用？哪些工具輸出會被當成事實？哪些 memory 內容一旦被污染，就可能沿著後續步驟變成長程控制？

當你開始這樣問，才算真的走進 agent security 的核心。