你的 OpenClaw agent 到底有多少權限？我重新審了一遍，嚇了一跳
最近花了兩個週末重新整理了一遍我的 OpenClaw 設定。起因是某天在做 code review 的時候突然想到：我給 agent 的 tool 權限是不是太寬了？
原本的設定很典型——一個 gateway token、一個 session，工具清單基本上是全開：讀檔、寫檔、跑 shell、存取外部 API... 全部都在同一層。設定起來很快，跑起來也沒什麼問題。當時的想法是「反正在本機，有 sandbox 包著就好了」。
但這個想法有個根本問題：你把所有風險集中在一個點上了。
Sandbox 本身不是問題，問題是你以為 sandbox 夠了，所以裡面的東西就不用再設邊界。這就像說「反正家裡有門鎖，所以客廳、臥室、保險箱就不用分開鎖了」。
我重新看了一遍所有 skill 的設定之後發現，有幾個工具的組合在 agent 自主跑的時候其實挺危險的：
exec+write如果同時給，agent 基本上可以做到任何事- 有些 skill 原本只需要
read，但我懶得細分就直接給了全套 - shell 指令沒有分高低風險，
ls和rm -rf的審批流程是一樣的
技能少的時候這些問題看不出來，但我現在跑的 workflow 有十幾個 skill，風險面就變大了很多。
我的改法是把工具權限拆成三層來思考：
tool 層：每個 skill 只宣告它真正需要的工具。我之前有個部署通知的 skill，裡面根本沒有理由需要 exec，但因為我是複製一個有 exec 的 skill 改的，就這樣留下來了。這次全部重新審了一遍，沒用到的全部拿掉。
identity 層：不同類型的任務用不同的 session context 跑。讀取型的 workflow（掃 inbox、查 calendar）和寫入型的（發訊息、改檔案）分開，不要混在同一個 agent session 裡。
審批層：針對高風險指令加人工確認。我把自己定義的「高風險」列出來：
- 刪除任何檔案
- 跑沒有
--dry-run的 deploy script - 對外發出的通訊（email、非內部的 webhook）
這三類現在全部都要我手動 approve，不管是哪個 skill 呼叫的。
加了審批流之後的感受：一開始覺得煩，大概有三四天，按 approve 按到很無聊。但某天有個 skill 跑到一半，我看了一眼覺得「等等這個指令是在幹嘛」，然後拒絕了。查下去才發現是 skill 裡有個小邏輯錯誤，如果沒有審批直接過的話，會把一個暫存目錄整個清掉。
不嚴重，但也不是我想要的結果。
這個經驗讓我想清楚一件事：審批不是在保護我不被惡意攻擊，而是在保護我不被自己的 skill 邏輯錯誤害到。 我之前以為安全設計是要防外部威脅，但其實大部分的風險來自內部——我自己寫的 skill、我自己設的邏輯、我自己的 typo。
另外還有一件事：audit log。
以前我沒有留 log 的習慣，覺得反正在本機、反正是我自己在用。但 agent 跑的東西越來越多，有時候我已經記不清「這個檔案是我改的還是 skill 改的」、「這個 issue 是我開的還是自動化開的」。
現在的做法是把每個 skill 的重要動作寫到一個 log 檔，格式很簡單：
2026-04-20T14:32:11+08:00 [ci-notify] opened issue #142 (build failed: main)
2026-04-20T14:32:15+08:00 [ci-notify] notified #dev-alerts
2026-04-21T09:11:03+08:00 [inbox-triage] moved 3 emails to /archive
不需要很花哨，但有這個之後查起來差很多。尤其是出 bug 要 debug 的時候，能看到 agent 到底做了什麼步驟，省了很多時間。
總結這次改架構的心得：
- Skill 少的時候寬鬆沒關係，但 skill 多了之後一定要重新審整體權限
- Sandbox 是必要的，但 sandbox 裡面還是要有內部邊界
- 審批機制的價值不在於防攻擊，在於讓你看清楚 agent 在幹嘛
- Audit log 就算最土的 append-only .txt 也比沒有強
不是什麼革命性的架構改動，就是把「我有一個 agent 在跑」改成「我知道這個 agent 在每一層有哪些權限、做了哪些事」。差別聽起來不大，但實際維護起來差很多。
有在跑比較複雜 workflow 的人可以參考看看，這個坑早踩早好。
作者：Jesse