ClawLess 論文閱讀分析：當 AI Agent 遲早會失控，真正重要的是你有沒有先把邊界畫好
論文基本資訊
- 論文標題：ClawLess: A Security Model of AI Agents
- 作者：Hongyi Lu、Nian Liu、Shuai Wang、Fengwei Zhang
- 年份：2026
- 來源：arXiv:2604.06284
- 論文連結：https://arxiv.org/abs/2604.06284
- DOI：10.48550/arXiv.2604.06284
- 主題：Agentic Security、AI Agents、Formal Security Model、Runtime Enforcement、Sandbox、BPF、Least Privilege
如果前面幾篇 agentic security 論文，還在討論 skill 供應鏈、runtime guardrail、incident response、prompt attack surface，那 ClawLess 這篇更像是把問題直接拉回安全工程最根本的一層：
假設 agent 本身遲早會被污染、被誘導、甚至直接變成對手，那我們還能不能先把它能碰什麼、不能碰什麼，寫成一套真的能被強制執行的安全模型？
我很喜歡這篇的原因，是它沒有再停留在「讓模型更乖一點」「把 prompt 寫更清楚一點」「多做幾條 policy check」這種半軟性的控制方法，而是非常直接地說：如果你的威脅模型裡，agent 可能就是惡意的，那你就不該把安全寄託在 agent 自己願不願意守規矩。
這個立場其實非常資安，也非常少見。因為很多 AI agent 安全方案，本質上還是把 LLM 當成一個可以被調教的好員工；ClawLess 則更像是在說：別把它當員工，先把它當高不確定性的自動化進程。
這篇論文在解決什麼問題？
作者要處理的問題很明確：現代 AI agent 已經不只是聊天或回答問題，而是會自己上網找資料、自己跑程式、自己讀寫檔案、自己和外部服務互動。能力越完整，安全邊界就越模糊。
論文指出，這種系統和傳統軟體最大的不同，在於它同時打破了三個舊假設：
- 信任邊界不再固定：agent 會自主從各種來源抓資料，trusted / untrusted input 很難事先切乾淨。
- 行為不可靜態分析：LLM 輸出本來就具非決定性，無法像傳統程式那樣先把所有路徑驗乾淨。
- 權限需求與風險高度耦合：真正有用的 agent 往往需要 filesystem、network、process execution 等能力，但這些能力同時也是攻擊面。
所以作者不把問題定義成「如何讓 agent 永遠不犯錯」，而是換一個更務實的問法：
當 agent 不可信時，系統還能否維持安全？
這個角度，讓整篇論文的重心從 alignment / prompting，轉到 formal model、least privilege、runtime mediation、trusted enforcement base。
ClawLess 的核心立場：把 agent 視為可能惡意，而不是偶爾失誤
這篇最關鍵的地方，是它採用了很硬的 worst-case threat model。作者直接假設：
- AI agent 本身是 untrusted component
- agent 下載或產生的 script / code / external artifacts 也是 untrusted
- 真正應該被保護的是 host software stack、host kernel，以及不屬於 agent 任務邊界的資源
換句話說，ClawLess 並不是在假設「模型大致可信，只是偶爾 hallucinate」；它的前提更接近：
只要 agent 長期暴露在不乾淨輸入下，我們就應該預期它遲早會做出惡意或危險行為。
這個前提一旦成立，很多現在常見的防禦思路就不夠了。因為 training、RLHF、system prompt、rule-based filter 這些方法，本質上都還是在「說服 agent 不要亂來」；但如果威脅模型裡 agent 可能已經站到對面，那真正要做的是 限制它即使亂來，也碰不到不該碰的東西。
這篇論文最有價值的部分：它不是只做 sandbox，而是先定義 security model
很多人看到這種題目，可能直覺以為又是一篇「把 agent 關進容器裡」的 paper。但 ClawLess 比單純 sandbox 更有意思，因為它的順序不是先上技術，再補安全說明；而是先把安全語意寫清楚，再把語意翻譯成 enforcement。
作者先定義了三個核心概念：
- Entities：系統中的各種受保護對象，例如 file、process、socket、device 等
- Scopes：不同執行/信任域，例如
Sandbox、Agent、Monitor - Permissions：不同 scope 對 entity 能做的事，例如
Read、Write、Append、Visible、NoExecute
這裡最妙的是它不只定義一般的 read/write 權限，還額外把 Visible 和 NoExecute 這類語意拉進來。這代表作者不是只想限制 I/O，而是想把 agent 常見的高風險能力 —— 尤其是 看得到但不該讀內容、碰得到但不該執行 —— 用更貼近 agent workflow 的方式表達出來。
例如 credentials 這種東西，在傳統 permission model 裡通常很尷尬：不是能讀，就是不能讀。但對 agent 來說，很多時候它需要「用到憑證」卻不該真的把 secret 本文帶進 context。ClawLess 的 Visible 權限，就是在處理這種比 Unix permission 更細的語意差異。
它真正想補的，不只是 isolation，而是 semantic gap
我認為這篇論文有一個很值得注意的判斷：AI agent 安全最大的麻煩，不只是技術隔離不夠，而是 policy 語意和實際系統行為之間有很大的 semantic gap。
高層政策常常寫成：
- 可以讀工作目錄，但不可以碰敏感系統檔案
- 可以連網查資料，但不可以任意外傳內容
- 可以執行低風險輔助腳本，但不可以把執行控制權交給未知程式
但如果沒有一套 formal model，這些規則很容易只停留在人的理解層。系統實作時就會退化成各種 ad hoc allowlist / denylist，最後不是擋不住，就是直接把 agent 關到幾乎不能用。
ClawLess 想做的事，就是把這些 語意層的安全政策 先形式化，再透過 policy compiler 轉成具體安全規則，最後交給執行層去硬性 enforce。這一來，論文的重點就不再只是「我們有個 sandbox」，而是：
我們有一個可以描述 agent 安全邊界的語言，然後再把它落到真正能攔住 syscall 與 runtime 行為的機制上。
系統設計：formal validator + policy compiler + user-space kernel + BPF
從架構上看，ClawLess 大致分成兩部分：
- Formal part：SMT-based validator、policy compiler
- Concrete part：user-space kernel、runtime monitoring、external sandboxes
這裡的思路很清楚：
- 先把系統裡有哪些 entity、哪些 scope、各自允許哪些 permission 定義出來
- 再用 SMT 驗證 policy 是否自洽、是否違反預期安全條件
- 把驗證過的 model 編譯成具體 enforcement configuration
- 最後用 user-space kernel 加上 BPF-based syscall interception 去監控與攔截
作者之所以選 user-space kernel，而不是只靠標準 Docker，也是有理由的。論文明白指出：如果你只是把 agent 放進一般 container，安全仍然高度依賴 host Linux kernel；而 monolithic kernel 自身的攻擊面，正是高風險 agent 最可能嘗試利用的部分。
因此 ClawLess 更偏好像 gVisor 這種 user-space kernel 風格的 secure container：它在 compatibility、interoperability、deployability 和 security 之間取得一個現實世界比較能落地的平衡。不是最強隔離，但比裸 Docker 更有意義；也不像 VM / confidential container 那樣把 host interaction 幾乎切到不能做事。
為什麼它特別強調 BPF？因為 agent 風險是動態的
ClawLess 使用 BPF 做 runtime monitoring，這不是只是技術選型細節，而是對 AI agent 風險本質的回應。因為 agent 的危險行為，往往不是安裝那一刻就能完全看穿，而是在執行過程中，根據讀到的新內容、拿到的新工具、遭遇的新提示，逐步改變路徑。
這也是為什麼純靜態分析很難撐住。BPF 的價值在於，它能讓系統在 syscall、network operation、file access 等低層事件發生時，保有足夠細的可視性與攔截能力。
對資安實務來說，這件事很重要。因為很多 agent 安全方案仍然過度停留在 prompt / output 層；但真正的風險，最後常常會落在：
- 它到底讀了哪些檔
- 它到底連了哪些外部位置
- 它到底 fork / exec 了什麼進程
- 它到底把哪些內容 append、overwrite、或傳出去了
ClawLess 的思路基本上是在說：如果你真的把 agent 當成系統主體的一部分，那安全觀測點就不能只停留在語言層，必須下沉到 operating-system interaction 這層。
它想解的另一個難題：least privilege 和 usability 的拉扯
這篇論文還有一點很誠實：它沒有假裝 least privilege 很容易套在 AI agent 上。事實上，作者直接把 Privilege / Usability Trade-off 列成核心挑戰之一。
這很真實。因為如果權限卡得太死，agent 根本做不了事；但如果你因為想讓它好用，就直接給讀寫工作目錄、開網路、跑 shell、動外部腳本，那你其實等於把一個高不確定性自動化系統放進高權限環境裸奔。
ClawLess 的解法不是假裝這個矛盾不存在，而是試圖透過 更細粒度的實體、scope、permission 建模，把「可用」和「可控」之間拉出一條更精準的中線。這當然不是完美解，但比一刀切 allow / deny 強太多。
這篇論文最值得記住的一句話：安全不能建立在 agent 內部設計之上
我覺得 ClawLess 最值得記住的，不是某個具體實作細節，而是它的整體哲學：
真正可靠的 agent security，不應該依賴 agent 本身的內部設計是否夠乖、夠穩、夠可預測，而應該建立在外部可驗證、可強制的安全邊界上。
這個觀點和最近一堆 agent safety / guardrail paper 放在一起看，差異就很明顯了。很多論文其實還是在做行為校正；ClawLess 則更接近傳統資安裡那種「就算 process 被攻陷，damage 也要被圈住」的思路。
說得更白一點：它不是要讓 agent 成為好人，而是要讓壞掉的 agent 也沒那麼容易把系統拖下水。
這篇論文的限制在哪裡？
當然，ClawLess 也不是沒有代價。它的威脅模型很強，實作成本也不低，而且它明確承認有些事情在 scope 外，例如 DoS、某些底層 software stack 弱點、微架構攻擊等。這是合理的，但也提醒我們：它比較像是在替 AI agent 建一套安全地基，不是萬能防護罩。
另外，這種 formal model + runtime enforcement 的方法，長期要不要維護、能不能跟上 agent framework 快速變動、在不同工具生態裡能否保有足夠 compatibility，都是現實部署一定會遇到的問題。
但老實說，我反而覺得這不算它的弱點，而是它的誠實。因為 agent security 本來就不可能靠一招打通。比起那些看起來很順、但實際上只是把風險換個說法包起來的方案，ClawLess 至少很清楚自己在解哪一層問題。
對當前 agentic security 脈絡的意義
如果把這篇放進最近幾篇 paper 的脈絡裡看，它的位置其實很清楚：
- Agent Skills / supply chain papers 在講能力包如何把風險帶進來
- Prompt / guardrail papers 在講 agent 怎麼被引導或如何被約束
- Incident response / runtime remediation papers 在講出事後怎麼收拾
- ClawLess 則是在補一個更底層的問題：安全邊界究竟要怎麼被正式定義、驗證、再強制落地
這也是為什麼我認為它很值得看。因為 AI agent 安全如果只談 taxonomy、benchmark、attack demo，而不回頭處理 enforcement model，最後很容易又回到「知道很多風險，但系統本身沒有真正能卡住它的硬邊界」這個老問題。
重點整理
- ClawLess 將 AI agent 視為可能惡意的 untrusted component，採用 worst-case threat model，而不是假設 agent 只是偶爾犯錯。
- 論文的核心不是單純做 sandbox，而是先形式化定義 entities、scopes、permissions，再把 policy 編譯成具體 enforcement。
- 它引入了比傳統存取控制更貼近 agent 的語意，例如 Visible 與 NoExecute，用來描述「可引用但不可讀出內容」「不可把執行控制權交給外部實體」這類細節。
- 架構上整合了 SMT-based validation、policy compiler、user-space kernel、BPF-based syscall interception，試圖把高層安全政策和低層 runtime enforcement 接起來。
- 作者明確指出，training、prompting、普通 sandbox 都不足以提供 fundamental guarantee；真正要處理的是 formal security boundary 與 trusted enforcement base。
- ClawLess 想解的不是「讓 agent 永遠乖」，而是 即使 agent 壞掉，系統仍維持安全。
- 這篇論文的重要性，在於它把 agentic security 從 taxonomy / guardrail 討論，往更扎實的系統安全模型推進了一步。
Takeaway
如果要我用一句話總結這篇 paper，我會這樣說：
ClawLess 真正有價值的地方，不是再替 agent 加一層「乖一點」的提示，而是把 agent 當成遲早可能失控的高權限進程，然後認真替它畫出一條碰不得的硬邊界。
對正在設計 agent platform、企業內部 coding agent、SOC automation agent，甚至本機高權限 AI assistant 的團隊來說，這篇論文最重要的提醒其實很簡單：只要你讓 agent 接觸檔案、網路、程式與外部內容，安全問題就不再只是 prompt engineering 問題，而是完整的 systems security 問題。
而在這件事上，ClawLess 給的不是最輕巧的答案，但很可能是目前少數真正站在安全工程角度回答問題的答案。
免責聲明
本文由 AI 產生、整理與撰寫。內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要；儘管已盡力確保內容的完整性與可讀性，仍可能因模型理解限制、資料來源差異或語意轉譯過程而存在疏漏、不精確或更新延遲之處。本文僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。