Clawed and Dangerous 論文閱讀分析：當開放式 Agent 真正拿到記憶、工具與權限後，安全就不再只是防 Prompt Injection
論文基本資訊
- 論文標題：Clawed and Dangerous: Can We Trust Open Agentic Systems?
- 作者：Qin Wang
- 年份：2026
- 來源：arXiv:2603.26221
- 論文連結：https://arxiv.org/abs/2603.26221
- 主題：Agentic Security、Open Agentic Systems、Memory Poisoning、Tool Supply Chain、Runtime Governance、Secure-by-Construction
如果前幾篇還在問：LLM 能不能幫 SOC 做事？agent 能不能做 incident response？多代理系統該怎麼 benchmark？那麼這篇 Clawed and Dangerous: Can We Trust Open Agentic Systems? 其實是把問題再往前推一層：當 agent 已經不只是聊天模型，而是變成一個會規劃、會記憶、會叫工具、會拿著使用者權限直接動手的開放式系統時，我們到底該用什麼方式去談它的安全？
我認為這篇論文最有價值的地方，不在於它又多列出幾種 prompt injection，而在於它很明確地指出：open agentic systems 的安全問題，已經不能再沿用「傳統軟體是可預測控制流」那套直覺來理解。 在這類系統裡，規劃是 runtime 才生成的，外部輸入與工具輸出都可能影響下一步決策，記憶會跨 session 留下狀態，而執行的權限又常常是直接借用人的權限。換句話說，真正的難題不是某一招攻擊，而是在持續不確定性之下，如何治理 agent 行為本身。
這篇論文為什麼值得補進最近這條主線？
最近 sectools.tw 這串文章，已經一路碰到不少 agentic security 的切面：
- 有的談 threat model，例如 autonomous agent 的生命週期風險如何擴散。
- 有的談 guardrail，例如 AgentDoG 怎麼做診斷式安全控管。
- 有的談 incident response，例如 AIR 把善後能力帶回 agent safety。
- 有的談 benchmark，像 SOC-bench、CVE-Bench、SIABench 去問模型到底會不會做真實工作。
但這篇 paper 的角色不太一樣。它比較像一篇架構層的收斂文：不是只守一個點、也不是只評一個任務，而是試圖把整個 open agent ecosystem 當成一種新的軟體系統類型來分析。作者甚至直接把 OpenClaw 當成這個 broader class 的代表案例之一，因為這類系統把幾個關鍵屬性都放大得很清楚：
- LLM 不是只回答，而是會當 planner
- 系統有外部 tools / skills
- 存在 persistent memory
- 能在 host 或 cloud 上做 privileged execution
- 還有 third-party extensibility，也就是工具與 skill 的供應鏈問題
一旦五個條件同時成立，agent 的安全挑戰就不再只是「模型會不會胡說八道」，而是會變成一個真正的系統安全與軟體工程治理問題。
作者的核心主張：agent security 的本質，是軟體架構與生命週期工程問題
這篇最值得記住的一句話，大概就是：
agent security 不是只靠 prompt robustness 就能解決；真正決定勝負的，往往是 capability design、execution isolation、interface contract、provenance，以及 operational governance。
這個觀點我很認同。因為過去很多 agent security 討論，太容易落進兩種極端：
- 要嘛一直強調 prompt injection，把幾乎所有問題都壓成輸入污染
- 要嘛一直強調模型 alignment，好像只要模型夠乖，系統就會安全
但 open agentic systems 的真實問題明明更髒也更工程化。你今天不是只在防一個模型，而是在防一條動態生成的行動鏈：
- 使用者用自然語言提出模糊意圖
- planner 用模型去解釋意圖
- 中途還會吃進 retrieved content、tool outputs、memory
- 再把結果翻成實際工具呼叫
- 最後寫檔、跑 shell、打 API、改 repo、動雲端資源
這條鏈路裡，每一段都在轉譯 authority。也因此，真正要問的不是「模型本身對不對」，而是：系統到底有沒有對權限擴張、能力暴露、狀態污染、以及事後回收做出可治理的約束。
這篇論文怎麼切 open agentic systems？五個定義特徵很重要
作者先給了一個很清楚的定義：open agentic systems 是一類更廣義的系統形態，而不是某一個特定產品。它們有五個核心特徵：
- LLM-based planner：模型在 runtime 解讀意圖、產生多步驟行動。
- External tools or skills：可以做有副作用的操作，例如 file I/O、shell、network、API call。
- Memory / persistent context：會跨 invocation 保存或取回資訊。
- Privileged execution：能在 host、cloud 或兩者上以使用者授權行動。
- Third-party extensibility：工具、skills、MCP servers 可以由外部開發者擴充。
這五點之所以關鍵，是因為它們一起成立時，安全風險會從單輪對話問題，膨脹成跨時間、跨元件、跨供應鏈的系統問題。尤其是第三點跟第五點——persistent memory 與 third-party extensibility——幾乎就是這一波 agentic security 為什麼會變麻煩的核心原因。
為什麼傳統軟體安全的幾個假設，在這裡會失效？
這篇 paper 很漂亮的一段，是它沒有急著先談攻擊，而是先談：我們以前為什麼能把軟體安全做得相對可控？又是哪些前提在 agent 系統裡壞掉了？
作者列出幾個被 open agentic systems 打破的舊假設，我覺得非常值得記：
1. 規格可以在部署前講清楚
傳統軟體大多假設 acceptable behavior 可以事先定義得夠清楚；但 agent 的實際行為往往是 runtime 才拼出來的，會受到工具結果、外部內容、記憶與環境狀態影響。這代表你很難在事前把「允許什麼、不允許什麼」寫成完整規格。
2. 上線前測過就有意義
在一般系統裡，測試、review、靜態分析、formal analysis 都是有力的 assurance gate；但對 open-ended tasks、外部工具與開放環境裡運作的 agent 來說，再完整的 pre-deployment test suite 也很難涵蓋真正的 runtime 組合爆炸。
3. 失敗是例外，不是結構性常態
傳統安全常把 compromise 當成要努力避免的事件；但作者認為對 open agentic systems 而言，misalignment、misuse、partial compromise 比較像結構性可能性，而不是純例外。這不是悲觀，而是比較務實。
4. 權限委派是穩定且清楚的
舊式權限模型通常假設 principal 與 authority transfer 還算清楚，但在 agent 系統裡，權限會沿著 user → planner → memory → tool → host 一層層被轉譯，中途每層都可能失真。也因此，問題已經不是 access control list 寫得好不好，而是delegation fidelity 到底能不能被持續約束。
看到這裡，其實你就會明白作者為什麼一直強調：這不是一個只靠輸入過濾就能補救的問題。
六維分類法：這篇論文最有用的骨架
這篇論文真正的主體，是作者提出的一個 六維 analytical taxonomy。它的目的不是把東西分類得更漂亮，而是逼大家從軟體工程角度去看：風險發生在什麼生命週期、跨了哪個 trust boundary、打到了哪些 capability surface、控制應該放在哪一層、證據又有多成熟。
六個維度分別是：
- Failure Mode
- Lifecycle Phase
- Trust Boundary
- Capability Surface
- Control Locus
- Evidence Type
這六維裡，我覺得最有價值的是中間三層：lifecycle、trust boundary、control locus。因為這三個維度直接決定你要怎麼做 engineering，而不是只做 attack catalog。
Failure Mode：作者列出九種常見失敗類型
這裡面包含：
- Indirect prompt injection
- Instruction confusion
- Tool misuse / confused deputy
- Memory poisoning
- Supply-chain compromise
- Privilege escalation / sandbox escape
- Side-effect amplification
- Multi-agent delegation abuse
- Governance failure
最值得注意的是最後兩個：multi-agent delegation abuse 與 governance failure。很多文章愛談 injection，但比較少認真把「權限撤銷做不好」、「政策漂移沒人發現」、「事故後回收能力不足」也當成安全失敗的一部分。這篇把它講白了：如果你沒有 revocation、audit、incident response，那也是 security failure，不只是管理瑕疵。
Lifecycle Phase：把 agent security 拉回工程生命週期
作者把生命週期分成：
- Spec：能力宣告、意圖規格、工具契約、風險分類
- Design：trust decomposition、planning/execution 分離、隔離域設計
- Implementation：tool wrappers、permission manifests、parser hardening、memory pipeline
- Test：benchmarks、adversarial task suites、utility-security tradeoff
- Deploy：signing、rollout、registry governance、revocation
- Ops：logging、audit、provenance、permission revocation、incident response、recovery
這裡我最喜歡的一點，是作者把 Deploy 跟 Ops 拆開。因為在 agent 世界裡，工具不是裝完就沒事，它可能在日後多次 session 裡持續被呼叫，權限與行為風險也會變。把 Deploy 和 Ops 混成一團，等於把最真實的治理問題藏掉。
Trust Boundary：作者畫出七個關鍵邊界
這七個 boundary 幾乎可以當成 open agentic systems 的 threat map：
- user ↔ agent
- content ↔ agent
- planning ↔ execution
- agent ↔ tool
- runtime ↔ host
- memory ↔ future sessions
- supply chain ↔ organization
其中我覺得最重要、也最容易被低估的，是這三條：
- planning ↔ execution：模型輸出的文字，什麼時候變成真正會動系統的操作？
- memory ↔ future sessions：今天寫進去的東西，怎麼污染明天？
- supply chain ↔ organization：第三方技能到底是誰在替你信任？
只要這三條 boundary 沒守好，很多看似「局部」的安全漏洞都會被放大成跨時序、跨主體的問題。
Capability Surface：把風險翻成可碰觸的資源
作者也列出九種 capability surfaces，像是：
- filesystem
- shell / process
- network
- browser state
- credentials
- cloud resources
- repositories / CI/CD
- memory stores
- physical actuators
這一層很實用，因為它提醒你：安全不是抽象說「agent 被騙了」，而是問它最後可以碰到什麼資源。一個同樣的 prompt injection，如果最後只能讀一段公開網頁，風險和能改 repo、跑 shell、打 cloud API，根本不是同一級別。
這篇論文看完整個文獻後，得出什麼結論？
作者一共整理了 50 篇文獻，涵蓋 attacks、benchmarks、defenses、audits 與一些工程基礎工作。看完之後，作者給出的整體判斷很鮮明：
- 文獻在 attack characterization 上已經相對成熟
- benchmark 建設也進展很快
- 但 deployment controls、operational governance、persistent-memory integrity、capability revocation 仍然偏弱
這句話其實很像在幫整個 agentic security 領域做一次體檢。也就是說，我們現在已經很會：
- 證明 agent 會被打
- 設計 benchmark 去測它會怎麼被打
- 提出一些局部 defense
但我們還不夠會：
- 設計一個能長期上線的 deployment control model
- 保證 persistent memory 不會慢性中毒
- 在事後有效撤銷權限與做 incident recovery
- 把安全治理內建成平台能力，而不是外掛補丁
如果用一句很白話的話說：我們現在比較會做 agent 的紅藍演習，還不太會做 agent 的制度治理。
我認為這篇最重要的啟發：真正該做的是 secure-by-construction agent platform
作者後面提出 reference doctrine 與 evaluation scorecard，重點都在推一件事：open agentic systems 應該往 secure-by-construction 的平台設計走，而不是每出一種新攻擊，就再補一種 classifier。
這個方向的核心精神其實很清楚：
- 把高風險 capability 明確切開，而不是一把全開
- 把 planning 和 execution 之間放上 policy mediation
- 讓 memory 有 provenance、隔離與回收能力
- 讓 tools / skills / MCP servers 有 admission 與 revocation 機制
- 讓 deployment 後還能持續 audit、rollback、contain、recover
這種思路也剛好和最近不少 paper 的趨勢接起來：大家已經慢慢意識到，agent security 不能只靠「模型更聰明」或「輸入過濾更準」，而得回到比較老派、但更可靠的系統工程原則——最小權限、分層控制、隔離、可追溯、可撤銷、可恢復。
這篇和前面幾篇有什麼不同？
如果把它跟最近幾篇放在一起看，差異會很清楚：
- AgentDoG 比較像是在問：如何診斷 agent 行為是否危險？
- AIR 比較像是在問：agent safety 出事後，怎麼做 runtime remediation 與 incident response？
- Security Analysis and Mitigation of Autonomous LLM Agent Threats 比較像是在畫一張 lifecycle threat map。
- 這篇 Clawed and Dangerous 則更進一步，直接把 open agentic systems 視為一種需要 secure-by-construction doctrine 的平台型軟體。
也就是說，這篇不是單點更深，而是視角更高。它想解的不是某個 exploit，而是：當 agent 已經是平台，而不是 feature，安全應該怎麼重新設計。
限制在哪？
當然，這篇 paper 也不是沒有局限。
- 它偏向 systematization / synthesis paper，不是實證型 benchmark paper，所以如果你只想看精確分數或 SOTA 排名，這篇不會給你那種快感。
- 不少建議還是 doctrine 層級，也就是方向對，但具體落地仍要看各平台實作。
- 很多證據來自快速移動中的 preprints 與 lab reports，作者自己也坦白區分了 evidence maturity。
但這些限制並不會讓它失去價值。恰恰相反，當一個領域太碎、太快、太容易被 demo 帶著跑時，這種收斂型 paper 反而很重要。 它提供的不是一個立即可複製的產品，而是一套比較能幫你判斷「接下來該把工程力花在哪裡」的框架。
總結
Clawed and Dangerous: Can We Trust Open Agentic Systems? 值得看的地方，不是它又替 agent security 多加了一個 buzzword，而是它很明確地把問題重新定義了：open agentic systems 的安全，本質上是一個關於動態委派、持久記憶、外部能力、供應鏈擴展與營運治理的軟體工程問題。
如果要把這篇濃縮成一句 takeaway，我會寫成這樣：
真正危險的從來不只是某一段惡意 prompt，而是當一個會規劃、會記住、會叫工具、還拿著你權限的 agent，沒有被設計成可治理、可撤銷、可稽核、可復原的系統。
對正在做 SOC agent、coding agent、enterprise automation，或任何高權限 LLM workflow 的團隊來說，這篇 paper 提醒得很直接：下一階段的 agent security 競爭，重點不只是誰更會攔攻擊，而是誰的平台從一開始就比較值得被信任。
免責聲明
本文由 AI 產生、整理與撰寫。