限制要放在 agent 的視線之外
說穿了就是：寫在 agent 指令裡的安全規則不是 hard limit，那是 instruction。
Reddit 上有個非技術背景的人在問 OpenClaw 怎麼設安全基線，他的方向是 dedicated machine、throwaway Google account、UFW 加 OpenSnitch，我覺得思路是對的，但這個根本的問題沒有點到。你在 SOUL 或 system prompt 裡面寫「只能讀 X 不能寫 Y」，agent 在正常情況下會遵守，但那個遵守是軟性的，不是物理約束。prompt injection、設定漂移、或是你自己改了一行，那些規則就不算數了。
真正能信賴的是 agent 看不到、也控制不了的那幾層。
網路出口是最直接的一層。UFW 預設 deny outbound，然後手動開 allowlist：
ufw default deny outgoing
ufw allow out to <OpenClaw API IP range> port 443
ufw allow out to 1.1.1.1 port 53
不是開一個 allow out 443 讓所有 443 流量通過，而是只開 agent 實際需要的 endpoint。就算 agent 被 prompt inject 要去打外部服務，防火牆層直接擋，請求根本送不出去。OpenSnitch 可以做到 per-process 的 outbound approval，但日常維護成本比較高，適合你真的有時間管的情況。
費用邊界也是一樣的邏輯。API key 掛預付卡，設單月上限 $20 美金。不是信任問題，是把後果鎖住，key 洩漏或 agent 被利用去爆 API 用量，損失上限就在那裡，不是你的主卡額度。
帳號分離要做到位。throwaway Google account 是好的起點，但要往下一層：服務 calendar 跟個人 calendar 徹底分開，agent 的 OAuth scope 只開寫入服務 calendar 的權限，不給讀個人行程。email 如果要接，只給一個空的 alias，不讓 agent 碰主 inbox 的 token。做了這個分離之後，你自然會清楚 agent「能夠」做什麼跟「被允許」做什麼的差距，這個差距才是真正的安全問題所在。
Dedicated machine 這個方向對，但重點不只是「隔一台機器」。機器上的帳號設計更重要：agent process 跑在低權限 user 下，不給 sudo，home directory 不讓 agent 直接寫，log 統一導到 agent 無法存取的路徑。如果 agent 在那台機器上跑的是 root，隔離就沒什麼意義了。
寫在 agent 裡的東西是你對它的期望，不是系統的約束。真正的約束是網路出口的 port allowlist、預付卡的額度上限、OAuth scope 的邊界，和帳號的最小權限設計。這幾條 agent 看不到，也繞不過去。
作者：CtrlC