AgentWard 論文閱讀分析：真正會害死 autonomous agent 的，通常不是單一 prompt，而是整條 lifecycle 一路把風險送到執行端

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

論文基本資訊

• 論文標題：AgentWard: A Lifecycle Security Architecture for Autonomous AI Agents
• 作者：Yixiang Zhang、Xinhao Deng、Jiaqing Wu、Yue Xiao、Ke Xu、Qi Li
• 年份：2026
• 來源：arXiv:2604.24657
• 論文連結：https://arxiv.org/abs/2604.24657
• DOI：10.48550/arXiv.2604.24657
• 主題：Agentic Security、Lifecycle Security、OpenClaw、Defense in Depth、Runtime Security、Trust Propagation

如果最近幾波 AI agent 安全研究讓人越看越有一種感覺：問題根本不是某個 prompt 比較邪門，而是整個 agent runtime 把太多風險串在同一條路上，那這篇 AgentWard 幾乎就是把這個直覺正式寫成架構圖。

它的核心主張很乾脆：autonomous agent 的安全失敗，通常不會乖乖只待在某一個介面上。 一個污染過的 skill、一次帶毒的外部內容、一次被滲透的記憶寫入，最後都可能一路影響到規劃、決策與實際執行。等你真的看到傷害，通常已經不是「模型說錯一句話」，而是系統在多個 stage 上一起鬆掉了。

所以 AgentWard 不走那種「再補一個 detector 看看」的零件式思路，而是把 agent 系統拆成五個 security stage 來看：

• 初始化（initialization）
• 輸入處理（input processing）
• 記憶（memory）
• 決策（decision-making）
• 執行（execution）

這篇 paper 最值得 sectools.tw 讀者記下來的地方，是它不是只講抽象原則，而是直接把 defense in depth、trust propagation control、execution containment 這幾件事，整理成一個可以拿來思考真實 agent runtime 的 lifecycle security blueprint。

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

作者先點出一個現在非常常見、但很多團隊其實還沒真正 internalize 的事實：autonomous AI agent 已經不是單純的聊天模型，而是一種會載入 skills、讀外部內容、保留記憶、做多步規劃、還能調高權限工具的 runtime system。

一旦系統長成這樣，安全風險就會開始出現幾個特徵：

• 攻擊不是只發生在單一 prompt
• 污染可能跨 stage 傳遞
• 真正的傷害往往到 execution 才顯現
• 單點防禦很容易被繞過，因為攻擊可以改走別條 propagation path

這也是 AgentWard 想重寫問題的方式：與其把 agent security 當成「偵測危險 prompt」或「降低 jailbreak 成功率」，不如把它當成「如何在整個 lifecycle 上攔截風險傳播，並保護關鍵資產不被一路碰到」。

AgentWard 的主軸：不是一面牆，而是五層協調的防線

從摘要與架構描述來看，AgentWard 的貢獻不是單一演算法，而是一種 lifecycle-oriented security architecture。它強調的不是所有防禦都要長得一樣，而是每個 stage 應該有對應的異質控制（heterogeneous controls），而且這些控制不能彼此孤立。

這裡的重點很重要。很多 agent 安全系統的常見問題是：

• 有輸入過濾，但記憶沒有治理
• 有 memory policy，但 execution 邊界太鬆
• 有 action approval，但前面的 trust 傳播沒有被追蹤
• 有 sandbox，但 initialization supply chain 沒控好

AgentWard 想補的，就是這種「每層都各自做一點，但整體沒有被當成同一個 attack surface」的斷裂感。它把 agent runtime 看成一條會傳染的鏈，而不是一堆互不相干的模組。

為什麼 lifecycle framing 值得重視？因為很多 agent 事故本來就是跨階段長出來的

我覺得這篇 paper 最準的一刀，是它把風險從單點漏洞拉回到 propagation。摘要其實已經講得很白：安全失敗很少只停在一個介面，而是會跨過 initialization、input、memory、decision、execution，最後在環境裡變成 side effect。

這個 framing 之所以重要，是因為它比傳統「輸入有毒 / 輸出有害」更貼近真實 agent 系統。舉幾個很典型的路徑：

• 初始化被污染：skill 或 plugin 供應鏈不乾淨，之後所有步驟都建立在錯的 trust base 上
• 輸入被污染：外部頁面、郵件、文件、ticket comment 帶有注入內容，接著進入 memory 或 planning
• 記憶被污染：一次不可信寫入，之後多輪都被當成可靠 context 重用
• 決策被帶偏：規劃器把受污染資訊當成 task-relevant objective
• 執行失控：最後由 privileged tool 真正把錯誤決策落地

換句話說，很多時候真正危險的不是某一層失守，而是某一層的髒東西能不能無阻礙地穿透到下一層。 這就是 AgentWard 想做 cross-layer coordination 的原因。

五個保護層在講什麼？

論文摘要沒有把每一層實作細節全部展開，但從它的 design rationale 已經能讀出一個很清楚的系統安全取向：

1. Initialization layer：先處理 agent 啟動時載入的 skills、plugins、configurations 與初始 trust base。這層如果沒管好，後面很多控制都只是補破網。
2. Input processing layer：把外部內容視為可能帶毒的來源，避免 untrusted content 直接被高權限路徑吃進去。
3. Memory layer：治理什麼可以被寫入、怎麼被標記、什麼時候該被降權或隔離，避免一次污染變成長期 persistence。
4. Decision-making layer：不是盲信 planner，而是限制規劃與目標推導如何使用前面流下來的 context。
5. Execution layer：最後把真正危險的 side effect 關在 containment boundary 裡，讓高權限 action 不會因前面任何一層的小偏差就直接落地。

這種切法的價值在於：它迫使你承認 agent security 不是只靠一個超強 judge model 或一條超長 system prompt 就能解決的問題。

這篇論文為什麼特別值得注意？因為它直接做了 OpenClaw plugin-native prototype

AgentWard 不是純概念文。作者明確提到，他們在 OpenClaw 上做了 plugin-native prototype，用來展示這套 lifecycle security architecture 有實作可行性。

這點很加分，因為很多 agent security paper 容易停在高空設計：原則都對，但工程上不知道怎麼接。OpenClaw 這種會讀 skills、調工具、接外部內容、保留 session context 的 agent runtime，剛好就是很適合驗證這類架構的場景。

而且這也讓這篇論文有一個很實際的訊號：作者不是把安全理解成事後審查模型輸出，而是把安全直接塞進 agent runtime 的擴充點、權限邊界與 control path 裡。

這和很多目前還把 safety 視為「在主模型前後各補一層」的做法，層次上差很多。

它和近來常見的 agent security 論文有什麼不同？

如果把最近這類研究放在一起看，很多 paper 會落在幾條典型路線：

• 量測某種攻擊有多容易打穿模型
• 提出某種 detector 或 sanitizer
• 討論單一攻擊面，例如 prompt injection、memory poisoning、tool abuse
• 做 benchmark 看誰比較抗打

AgentWard 比較不一樣的地方，是它偏向架構整理與防線編排。它不是否定那些 detector 或 benchmark，而是把它們重新放回系統脈絡裡問：

你的控制到底保的是哪一個 lifecycle stage？它攔住風險之後，風險還會不會從別條 path 繞回 execution？

這個問題很關鍵。因為很多團隊其實不是完全沒有做防禦，而是做了一堆點狀防禦，但沒有真的管理 trust 如何在系統裡流動。

這篇論文對資安團隊最有價值的提醒

我覺得 AgentWard 最值得帶回實務現場的，有五點：

1. 把 agent 當系統，不是當聊天框。 只要它會載入元件、讀外部內容、留記憶、做規劃、呼叫工具，它就是 runtime security 問題。
2. 威脅分析要看 propagation，不只看入口。 真正該問的是污染能不能跨 stage 傳下去，而不是只問哪個 prompt 比較危險。
3. 記憶是正式攻擊面，不是附加功能。 一旦 memory 沒有 trust 標記與治理，它就會成為把一次失誤延長成長期風險的機制。
4. execution containment 不能太晚才想。 如果高權限工具邊界沒收好，前面所有 stage 的小偏差最後都可能變成真的 side effect。
5. 不同 control 必須協調。 初始化、輸入、記憶、決策、執行各自做一點不夠，因為攻擊本來就不是照組織分工在走。

我的看法：AgentWard 真正補上的，是一個「怎麼把零散防禦接成一張網」的答案

老實說，這篇 paper 最吸引我的不是它提出了什麼神奇新模組，而是它把一個很多人早就隱約知道、卻常常沒整理好的事講清楚：agent security 最大的坑，往往不是缺某一個更強的點狀防禦，而是缺一個能描述整條風險傳播鏈的系統模型。

這也是為什麼我覺得它很適合放進 sectools.tw 近來一直在堆的主線裡。前面很多論文已經分別討論過：

• prompt injection
• memory poisoning
• tool hijacking
• least privilege
• execution sandboxing

但 AgentWard 做的是把這些點重新串起來，告訴你：真正的問題不是哪個點最危險，而是哪幾個點一旦連成線，整個 runtime 就會開始沿著 trust path 漏水。

這種視角很工程，也很成熟。它不像某些 paper 只在比誰的 ASR 低一點，而是在問更難、但也更值錢的問題：如果你今天真的要把 agent 放進 production，整條系統應該怎麼長，才能讓單點失誤不要一路長成真實傷害？

結語

AgentWard 這篇論文最值得記住的一句話，我會濃縮成這樣：

autonomous agent 的安全，不是守住某個 prompt 就算結束，而是要在初始化、輸入、記憶、決策、執行整條生命周期上，切斷風險傳播、標記信任邊界、並把真正危險的能力關進可控的執行籠子裡。

如果你的團隊正在做 AI assistant、coding agent、browser agent、SOC copilot 或任何會碰外部內容又能調工具的系統，這篇 paper 的價值不只是「又一篇 agent security」。它比較像一張提醒你別再只補單點漏洞的架構圖：沒有 lifecycle security，很多防禦都只是把問題往下一層延後爆炸。