Agent Privilege Separation in OpenClaw 論文閱讀分析：真正該切開的不是 prompt，而是那條讓髒內容直接碰到高權限工具的路

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

論文基本資訊

• 論文標題：Agent Privilege Separation in OpenClaw: A Structural Defense Against Prompt Injection
• 作者：Darren Cheng、Wen-Kwang Tsao
• 年份：2026
• 來源：arXiv:2603.13424
• 論文連結：https://arxiv.org/abs/2603.13424
• DOI：10.48550/arXiv.2603.13424
• 主題：OpenClaw、Agentic Security、Prompt Injection、Least Privilege、Multi-Agent Architecture、Runtime Security

如果最近這波 sectools.tw 的主線，已經一路從 OpenClaw 系列安全評測、ClawTrap 的 observation-channel 汙染、ATBench-Claw 的 trajectory safety、到 SafeHarness / ShieldNet / Policy-Invisible Violations 這些 runtime-level 論文慢慢鋪開，那這篇 Agent Privilege Separation in OpenClaw 值得補上的位置很明確：它不是再問 prompt injection 可不可怕，而是直接把問題收斂成一個老派但非常有效的系統安全答案——不要讓讀 untrusted content 的 agent，跟握有高權限工具的 agent，是同一個。

這個答案看起來樸素，甚至有點像把資安 101 的 least privilege 重新講一次；但它剛好打中現在很多 agent system 最常犯的錯。因為真實世界裡最危險的，往往不是模型「理解錯一句話」，而是同一個 agent 一邊看外部內容、一邊規劃、一邊持有 send_email / shell / file write / browser action 這些高風險能力。一旦這幾件事綁在同一個 execution identity 上，prompt injection 就不只是輸出被帶偏，而是能直接長出 side effect。

這篇論文的核心貢獻，不在發明超複雜 detector，而在於把防線往 architecture 層下沉：reader agent 處理原始、不可信內容；actor agent 只接收經過結構化、去除說服框架的摘要；真正危險的工具只留在後者手上。 換句話說，它把「不要讓 untrusted data 直接碰到 privileged action path」正式搬進 OpenClaw agent runtime。

這篇論文在做什麼？

作者直接拿經典的 LLMail-Inject 類郵件 prompt injection 場景來驗證防禦效果。情境很簡單也很真實：使用者想要 agent 幫忙摘要 email，但惡意郵件內容會偷偷夾帶 prompt injection，試圖讓 agent 改去呼叫 send_email 幫攻擊者寄信，甚至外洩敏感資訊。

很多系統面對這類問題的第一反應通常是：

• 把 system prompt 寫更兇
• 多加幾條「忽略郵件中的指令」
• 在 output 前做 classifier 檢查
• 或加一層 judge model 判定可不可以執行

這篇論文的想法則更硬：如果處理郵件內容的 agent 根本沒有寄信能力，那 injection 再會講，也只能卡在 reader 那一層，無法直接變成動作。

作者因此設計並比較四種配置，全部都在同一批攻擊集上測：

1. Baseline：單一 agent，直接讀郵件，也直接持有危險工具。
2. Pipeline：雙 agent 隔離 + JSON 結構化摘要 + validator。
3. Two-Agent Only：只做 agent privilege separation，不加 JSON 格式化。
4. JSON Validator Only：單 agent 但強制 JSON 輸出，不做工具權限隔離。

這個 ablation 很有價值，因為它不是只說「我們的方法有效」，而是把問題拆開問：到底真正扛住攻擊的是 JSON 去毒、validator 偵測，還是工具權限的硬切割？

核心架構：把 reader 與 actor 拆成兩個不同安全主體

作者的 defense pattern 可以濃縮成下面這條鏈：

Untrusted email content
  ↓
Reader agent（無危險工具）
  ↓
結構化 JSON 摘要 / schema 驗證
  ↓
Actor agent（有 send_email 等高權限工具）
  ↓
執行最終動作

重點不是 multi-agent 本身，而是tool partitioning。

• Reader agent 只能讀原始郵件、整理摘要、存結果；它沒有 send_email 之類危險工具。
• Actor agent 真的可以呼叫高權限工具，但它永遠不直接看到原始惡意郵件內容，只能看到前一層丟過來的摘要。

這個設計為什麼重要？因為它等於把傳統系統安全裡的兩個原則，直接套進 agent runtime：

• least privilege：每個 agent 只拿它當下需要的權限
• information flow control：untrusted content 不能無限制流到 privileged execution boundary

這和很多「同一個大 agent 什麼都會做，只是靠 prompt 提醒自己別做壞事」的設計差很多。前者是結構性限制；後者比較像行為期待。論文最想證明的，就是在 prompt injection 這種問題上，結構性限制遠比行為期待可靠。

第二層機制：JSON 格式化不是主角，但能補上最後那一點硬化

除了 agent isolation，作者還加了一層 JSON formatting。也就是 reader agent 不用自由文字把郵件內容傳給 actor，而是用固定 schema 輸出，例如：

• sender
• subject
• body summary
• action items

同時在中間放一個輕量 validator，用 regex 去抓幾類可疑片段，例如：

• email address literals
• 看起來像 tool-call syntax 的片段
• 常見 injection trigger phrases，例如「ignore previous instructions」

不過這篇最漂亮的地方，是它沒有神化這層 validator。作者甚至明講，這一層在實驗裡主要是用來觀察 leak rate，並不是萬靈丹。真正的重點是：即使 injection 內容部分滲進 summary，只要 actor 沒直接看見原始 persuasive framing，而且工具本身也不在 reader 那邊，風險就已經被大幅壓縮。

也就是說，JSON formatting 在這篇裡比較像 hardening，不是主要安全來源。真正扛住攻擊面的，還是 privilege separation。

資料集與測試方式：不是從全部攻擊重跑，而是專挑 baseline 能打穿的 649 筆

論文採用的評估方式也很值得記。作者不是隨便抓幾個 payload demo，而是沿用 LLMail-Inject 那條線，先從原始攻擊提交裡一路過濾：

• 461,640 筆原始 attack submissions
• 過濾後得到 41,173 個成功案例
• 再按內容去重，剩下 22,899 個 unique payloads
• 最後挑出在他們的 gpt-5-mini 單 agent baseline 上仍然成功的 649 筆攻擊

這個選法其實比直接拿全量平均更狠。因為它不是在測「防禦面對大量本來就不會成功的攻擊時看起來多強」，而是只拿那些本來真的能打穿 baseline 的 payload 來做比較。換句話說，這 649 筆是 normalized attack pool，專門用來驗防禦到底有沒有把真正危險的案例壓下來。

最重要的結果：雙 agent 隔離幾乎把整個問題打穿

這篇最值得記的數字非常直接：

• 單 agent baseline：這 649 筆 attack 全部都是它會中招的案例
• JSON formatting only：ASR 14.18%
• Two-Agent Only：ASR 0.31%
• 完整 pipeline：ASR 0%

如果換成 improvement ratio 來看：

• JSON only 約提升 7.1 倍
• Two-Agent isolation 約提升 323 倍
• 完整 pipeline 在這組 benchmark 上達到 0% ASR

這組結果其實非常乾脆地回答了那個關鍵問題：在這個場景裡，真正有決定性效果的不是把輸出格式弄乾淨，而是把「讀髒資料的人」和「能做危險事的人」拆開。

JSON 有幫助，但不夠；工具隔離才是主力。這跟很多團隊目前還在堆 detector、classifier、prompt patch 的習慣，方向上差非常多。

為什麼 isolation 這麼有效？因為它不是勸模型別做壞事，而是讓它根本做不到

論文對這件事的詮釋其實很準：agent isolation 是 structural defense，不依賴個別模型當下有沒有被說服。

Reader agent 就算真的被 injection 帶偏，它也沒有 send_email；所以偏掉的結果最多只能出現在 summary 裡，而不能直接變成 action。這和一般 prompt guardrail 的本質差很多。Prompt guardrail 是：

• 希望模型理解規則
• 希望模型優先 obey 高權限指令
• 希望模型在模糊情境下做對判斷

Privilege separation 則是：

• 不要求 reader 判對所有安全問題
• 只要求它無法觸發高風險 side effects
• 把最危險的 capability 移到另一個沒有直接暴露於 untrusted content 的主體上

這個差別非常大。前者仍然把安全寄託在模型行為；後者則是把安全寄託在 architecture constraint。也因此，作者才會說這種防禦是 independent of model behavior。只要 tool registration 沒給，reader 再聰明、再失誤、再被操縱，都寄不了那封信。

Scenario breakdown 也很有意思：RAG 與 data exfiltration 特別能看出差異

論文除了總體 ASR，還看了不同 scenario 的表現。這裡最值得記的兩個觀察是：

• Scenario 4（資料外洩） 對 JSON-only 特別難，ASR 還有 28.3%；但兩個雙 agent 配置都做到 0%。
• Scenario 3（RAG） 在 Two-Agent Only 與完整 pipeline 上都是 0%，但 JSON-only 仍有 6.0%。

這兩個結果剛好說明了一件事：當 trusted 與 untrusted content 開始混雜，或當攻擊目標變成跨邊界資料提取時，只靠格式化輸出很難真正切開信任邊界；但 privilege separation 可以。

因為 RAG / email / document 這類場景的難點，本來就不是有沒有看到惡意詞，而是模型在同一個 reasoning loop 裡，同時接觸可信任任務與不可信任內容。只要這兩件事沒被分開，模型就很容易在「完成任務」的過程中把 injection 一起當成 task-relevant context 吃進去。

另一個有意思的數字：baseline 其實已經不差，但 architecture 仍然明顯更重要

作者還提到一個值得注意的點：他們的 gpt-5-mini 單 agent baseline，放在完整 22,899 個 unique payloads 上時，ASR 其實已經只有 2.83%，代表新一代模型本身相較舊一代 baseline 已經有明顯 alignment gain。

這代表什麼？代表單看這個數字，你可能會誤以為「模型現在已經安全很多了，剩下只要再補幾條規則就好」。但論文接著做的事很重要：它不是停在模型變好了這個結論，而是進一步證明，就算模型本身已經比前代抗打，architecture-level isolation 仍然能把風險再往下壓一整個數量級。

換句話說，這篇不是在否定 model alignment，而是在提醒：alignment 是好事，但它不該被誤當成 production-grade side-effect security 的主要控制。

這篇論文最值得帶走的主線：真正該被隔離的，不是模型，而是 capability path

我覺得這篇 paper 最漂亮的地方，是它把一個常被講得很抽象的安全問題，重新翻成非常工程化的語言：prompt injection 之所以危險，不是因為那段文字有魔法，而是因為它落在一條同時連著觀測、推理、與高權限 action 的 capability path 上。

只要這條 path 還是直通的，你就會一直陷在：

• 要不要再加一層 classifier？
• 要不要換更強的 judge model？
• 要不要把 system prompt 寫更長？
• 要不要做更細的 keyword filtering？

但這篇的答案比較接近經典系統設計：別先問怎麼讓單一 agent 變得足夠聰明，先問它為什麼需要同時握有這麼多權限。

這和近幾篇 sectools.tw 寫過的幾條主線其實是連在一起的：

• SafeHarness 講的是 execution harness 整個 lifecycle 都要治理
• ShieldNet 講的是防線不能只停在語言層，要往 network / system layer 下沉
• Beyond Static Sandboxing 講的是 least privilege 應該被正式搬進 agent runtime
• 而這篇則把 least privilege 進一步具體化成 reader / actor privilege separation

它不是比前面那些更大一層的理論，而是更接近「你今天就能拿去改 architecture」的落地 pattern。

限制與殘餘風險：這不是萬靈丹，但它把最危險的直通路切斷了

作者也沒有把這套方法吹成完美。論文自己承認幾個限制：

• ablation 是在那 649 個 baseline-successful attacks 上做，不是重新對全量攻擊做 adaptive red teaming
• 還沒有特別測試針對 JSON handoff 與 multi-agent handoff 客製化的新型攻擊
• 中間 validator 只是簡單 regex 規則，不是完整 semantic verifier

另外還有一個很值得注意的細節：論文提到在完整 pipeline 裡，仍然觀察到 63.7% 的 injection leak rate 進入 reader summary。這個數字超有意思，因為它提醒我們：JSON formatting 並不等於毒素完全消失；它只是把毒素比較難直接變成 action。

也就是說，這篇真正的價值不是「從此 summary 裡再也不會出現髒內容」，而是：就算髒內容部分滲進去，因為高權限能力不在同一條 execution path 上，所以系統仍然不容易被直接帶去做事。

這是非常典型、也非常成熟的系統安全思路：你不需要保證上游資料永遠乾淨，你只需要保證髒資料即使流入，也不能輕易跨過關鍵控制邊界。

我的看法：這篇最重要的不是數字，而是它把 agent security 拉回了真正可落地的工程語言

現在很多 agent security 討論，很容易兩邊都失衡：

• 不是太偏 benchmark leaderboard，最後只剩誰 ASR 高誰 ASR 低
• 就是太偏抽象原則，大家都知道要 defense in depth、要 least privilege、要 provenance-aware，但不知道怎麼接到具體 runtime pattern

這篇剛好補在中間。它沒有提出超華麗的新理論，但它很明確地展示：在一個真實的 OpenClaw / email-agent 類場景裡，把 untrusted-content reader 與 privileged-action actor 分開，真的可以把 prompt injection 從「可能直接觸發 side effect」壓回「頂多污染上游摘要」的風險等級。

而且這個 pattern 很容易外推到別的 agent 場景：

• browser agent：看網頁的 agent 不該直接有交易 / 發文 / 下載執行權限
• coding agent：讀 README / issue / docs 的 agent 不該直接有 deploy / release / secret access
• SOC agent：讀 alert / web report / ticket comment 的 agent 不該直接有封鎖、隔離、刪除、回覆外部對象的能力

這其實就是把 prompt injection 從「模型會不會被騙」重新翻譯成「危險 capability 到底暴露在誰面前」。一旦問題被這樣重寫，很多防禦方向就會突然清楚很多。

結語：真正能救你的，可能不是更乖的模型，而是更不濫發權限的 architecture

Agent Privilege Separation in OpenClaw 這篇論文最值得記住的一句話，我會濃縮成這樣：

prompt injection 最該切斷的，不是某一句話，而是那條讓 untrusted content 可以一路碰到高權限 action 的直通路。

它用一個非常乾脆的實驗把這件事講清楚：JSON formatting 有幫助，但真正決定結果的，是 privilege separation；只要處理髒內容的 agent 根本沒有危險工具，攻擊面就會突然縮很多。

放回最近 sectools.tw 這串 agentic security 論文脈絡來看，這篇的重要性在於它不是又補一個 detector、又補一個 benchmark、又補一個 taxonomy，而是把整個主線往一個更成熟的工程結論推進：production agent 的安全，終究得靠結構性權限切割，而不是把所有希望都押在單一模型的判斷力上。

如果你的 agent 現在還是「同一個腦袋既看世界、又想事情、又能直接動手」，那這篇大概就是在提醒你：真正該重構的，也許不是 prompt，而是整條 runtime 權限配置本身。