把 OpenClaw 2.0 丟上 Linux 雲端主機，裝完就能對話，並不表示這台機器「安全」。預設安裝其實偏保守：本機安裝時 Gateway 綁回環、陌生私訊先給配對碼、群組多半要點名。真正會在第七天出事的，是三件預設沒關嚴的事疊在一起——沙箱預設關、工作階段工具預設能看見整台 Gateway、模型 API Key 仍可能以明文躺在 Agent 碰得到的檔案裡。
我們以「一個人值守、遠端 API、單一 Telegram 通道」把同一台 Ubuntu 雲端主機連跑 7 天，每天只做一件檢查：權限、SSH 與監聽、API Key、瀏覽器、Agent 隔離。結論先講：在單一信任域裡，它可以安全地常駐；把互不信任的同事、客戶或公開群塞進同一套 Gateway，官方自己也不把它當成租戶隔離。規格怎麼買見 OpenClaw 2.0 VPS 部署實測：CPU、記憶體和磁碟，本文只回答「跑一週之後，哪些口子還開著」。
先給判斷：安全，但有前提
OpenClaw 官方把一台 Gateway 寫成一個信任邊界：適合一個人，或彼此已經信任的小團隊。互相對抗的使用者、不同客戶、不同業務線，要拆成獨立 Gateway、獨立憑證，最好再拆 Linux 使用者或整台機器。這是 OpenClaw Gateway 安全文件 開篇就寫死的模型。你若用「多租戶 SaaS」的標準去審，幾乎每一條預設策略都會不合格；用「我自己的值班機」去審，預設值大多站得住。
7 天裡我們反覆跑 openclaw security audit。安裝當天最刺眼的不是「連接埠裸奔」——本機安裝預設 loopback，公網掃不到 18789——而是工具執行落在宿主機、跨 Agent 工作階段預設互相可見。這兩條不修，後面開瀏覽器技能、再加一個「唯讀客服」人格，爆炸半徑會從「這台機」變成「這台機上所有對話和金鑰」。
7 天怎麼跑，避免把「沒出事」當成「安全」
機器是 2 vCPU / 8 GB 的 Ubuntu 24.04，本機 install.sh，遠端 API，systemd 使用者單元常駐。SSH 只留金鑰、關密碼登入。Gateway 保持 bind: loopback，控制面用 SSH 本機轉發進 Control UI，沒有把 18789 丟給安全群組。通道只開 Telegram，dmPolicy 保持配對。我們故意沒有一開始就開 Docker 沙箱，就是為了看預設姿勢在第七天還剩什麼。
每天固定三組證據：openclaw security audit --json 的 findings、ss -lntp 與雲端廠商安全群組對照，以及 ~/.openclaw 目錄權限和明文金鑰掃描。不統計「模型有沒有被成功誘導」這種無法重現的故事，只統計設定有沒有漂、檔案有沒有被人（或 Agent 自己）寫鬆。
檢查一：權限——預設把 exec 留在宿主機上
OpenClaw 2.0 的沙箱是可選的。Gateway 永遠在宿主機上；只有打開 agents.defaults.sandbox 之後，工具執行才會進 Docker / Podman。關掉時，host=auto 會落到 gateway 本機。對「我信任自己」的個人助手，這很順手；對「通道裡會出現連結、附件、轉發」的值班機，這等於把提示詞注入的終點接到了部署使用者的 shell。
第 1 天的 audit 穩定打出兩類訊號：工具爆炸半徑偏大，以及 security="full"——官方說它是受信任操作員的預設體驗，不是漏洞。我們的取捨是：個人主 Agent 可以暫時保留宿主機執行，但必須同時滿足三件事：通道配對、檔案工具限工作區、tools.elevated 關掉。家庭或公開入口的第二個 Agent，必須 sandbox.mode: "all"，工作區 ro 或 none，並拒絕 exec / browser / gateway / cron。
目錄權限比很多人想的更容易漂。把設定從筆電 scp 上去、用 Docker 卷映射、或讓 Agent 自己複製 openclaw.json，都可能把 600/700 寫成 644/755。openclaw security audit --fix 會收緊狀態目錄和設定檔權限，但不會替你打開沙箱。獨立 Linux 使用者跑 Gateway，比繼續用 ubuntu/root 更重要：金鑰、工作階段庫、工作區都落在這個使用者的家目錄裡。
host=auto 回落到宿主機；如果你寫成 host=sandbox 卻沒提供執行環境，執行會失敗而不是偷偷回落到本機。不要為了「別報錯」把 host 改回 auto 然後以為自己隔離了。
檢查二：SSH 與監聽——控制面不要出現在公網
第 2 天我們從外網掃這台機。本機安裝路徑上，18789 只聽 127.0.0.1，安全群組只放 22，掃描器看不到 Gateway。這是 OpenClaw 文件裡「普通主機安裝」的預設，也是 7 天裡最省心的一條。反過來，官方也提醒：容器映像預設會暴露綁定，必須配上認證，不能把 Docker 連接埠對應理解成「和本機安裝一樣安全」。
SSH 本身我們只檢查三件事：禁止密碼登入、禁止 root 密碼、金鑰演算法不是十年前的雞肋。Gateway 的遠端存取走 SSH 隧道或 Tailscale，不走「把 Control UI 反向代理到 443 再忘了 token」。Gateway 的 HTTP/WebSocket 共用一個連接埠，上面還有 Control UI 和 Agent 寫出來的 widget 頁面；這些頁面按官方說法應視為不信任內容，不能和你已經登入的管理後台同源。
Docker 發布連接埠還有一層常見錯覺：-p 18789:18789 會走 Docker 自己的轉發鏈，只改 UFW 的 INPUT 不夠。官方安全文件專門寫了 DOCKER-USER 鏈。若走容器，外網複測必須針對公網 IP。最小暴露面可以對照 OpenClaw Linux 雲端主機最小暴露面與 SSH/HTTPS 決策，再回到本文看「跑一週之後有沒有被人改成 0.0.0.0」。
節點配對也算 SSH 面。sshVerify 用操作員 SSH 回讀裝置身分，不是「能連上就自動批准」。autoApproveCidrs 預設關，只對第一次、無額外 scope 的 node 角色生效。第 2 天我們確認這兩項都保持預設，沒有為了少點一次確認把自動批准打開。
檢查三：API Key——明文還在，Agent 就讀得到
第 3 天專門掃金鑰。OpenClaw 2.0 已經有 SecretRef：模型供應商的 apiKey、閘道 token、部分通道憑證可以改成 env / file / exec / store。官方也寫明：明文仍然可用，SecretRef 是按欄位自願啟用的。所以「我已經升級到 2.0」不等於「金鑰離開了磁碟」。
真正危險的不是「金鑰在機器上」——值班機總得有一份——而是金鑰落在 Agent 用 read / exec 就能打開的路徑：openclaw.json、.env、產生出來的 models.json、退休的 auth-profile 封存。提示詞注入不需要攻破 SSH，只要模型願意「把設定讀出來發到聊天裡」。官方 OpenClaw 金鑰管理文件 把遷移完成的標準寫得很硬：支援的欄位都改成 SecretRef、舊明文被擦掉、openclaw secrets audit --check 乾淨；剩下不支援的輪替類憑證，用作業系統使用者、容器或外部代理隔開。
Gateway token 要單獨看待。能呼叫 /v1/chat/completions、/tools/invoke 或管理 RPC 的共享密鑰，官方直接稱為全權操作員金鑰。不要把它寫進 Agent 工作區，不要塞進技能倉庫。輪替清單很短：產生新 token、重啟 Gateway、改遠端用戶端、確認舊值失效。第 3 天我們把模型 Key 遷到環境變數 SecretRef，把 Gateway token 留在僅部署使用者可讀的環境檔裡，工作區裡不再出現 sk- 開頭的行。
openclaw.json.bak、打包帶走的工作區、同步碟裡的副本，都要移出 Agent 能列到的目錄，或乾脆刪掉。
檢查四：瀏覽器——等於把操作員的手交給模型
第 4 天我們開了一次瀏覽器技能，當天就關掉。原因不是 Chromium 吃記憶體——8 GB 機器能扛一輪——而是控制面語意：遠端瀏覽器控制在官方文件裡被寫成與操作員存取等價。Agent 點到的頁面，用的是那個瀏覽器設定檔裡的登入態、Cookie 和已儲存密碼。個人日常 Chrome 設定檔絕對不能借給它。
可執行的隔離是分層的。獨立瀏覽器設定檔，關掉密碼管理員和同步；下載目錄單獨放，當不信任檔案處理；控制連接埠只留在回環或 tailnet，不要 Funnel 到公網。OpenClaw 2.0 的沙箱瀏覽器可以跑在獨立容器和獨立 Docker 網路 openclaw-sandbox-browser 裡，預設不給 allowHostControl。SSRF 策略預設攔住私網位址；只有你顯式打開 dangerouslyAllowPrivateNetwork，它才會去打內網。第 4 天我們確認這項保持預設關閉。
Chrome 擴充中繼和 CDP 遠端連接埠，按「能看見分頁 = 能當這個人」來管。現有工作階段模式並不更安全，它只是更像你。節點如果跑在另一台有桌面的機器上，節點配對就是管理員權限。7 天結論：文字助手不要開瀏覽器；非開不可，就給它一台沒有個人帳號的設定檔，並且不要和本機 7B 模型搶同一份記憶體。
檢查五：Agent 隔離——預設不是租戶隔離
第 5、6 天我們加了第二個 Agent，只給它唯讀工具，本以為工作階段會隔開。並沒有。預設 tools.sessions.visibility 是 all，tools.agentToAgent.enabled 是 true。未沙箱的 Agent 可以列出、搜尋、閱讀其他 Agent 的工作階段，包括你以為「給家人用的唯讀人格」。沙箱工作階段預設只被夾在自己的派生樹上，但這不會隱藏它們的轉寫：未沙箱的主 Agent 照樣讀得到。
要在同一台 Gateway 上做人格隔離，至少把可見性收到 agent 或 self，關掉或白名單化 agent-to-agent，並且不要用 scope: "shared" 讓所有人共用一個沙箱容器。私訊如果會進多個人，把 session.dmScope 設成 per-channel-peer，否則所有私訊都會滾進主工作階段。這些都是協作護欄，不是敵對租戶邊界。客戶 A 和客戶 B 必須拆 Gateway。
控制面工具也要按 Agent 收。gateway 能讀設定（裡面有拓樸和金鑰線索），cron 能留下你下線之後還在跑的任務。對任何會讀到不信任內容的 Agent，官方建議直接 deny 這兩類，再加上 sessions_spawn / sessions_send。外掛與技能目錄按「可信程式碼」對待：只裝你審過的來源，用 plugins.allow，改完重啟。
第 7 天複查：哪些漂了，哪些沒漂
第七天把五張清單再走一遍。監聽位址沒有漂，配對策略沒有漂，安全群組沒有被人加 18789。漂掉的是工作區裡多出來的一份除錯用 .env 副本，以及我們為了重現瀏覽器技能而留下的暫時 allowHostControl 註解——差點在合併設定時帶進正式環境。audit 在收緊權限之後變乾淨，但只要沙箱仍關著，它仍會提醒你這是受信任操作員姿勢，不是多使用者姿勢。
| 檢查 | 第 1 天 | 第 7 天 | 要不要改 |
|---|---|---|---|
| 權限 / 沙箱 | 沙箱關，exec 在宿主機 | 主 Agent 仍宿主機；唯讀 Agent 已沙箱 | 有不信任輸入就開沙箱 |
| SSH / 監聽 | loopback + 僅 22 | 未漂 | 保持；容器須另測連接埠對應 |
| API Key | 明文在 openclaw.json | SecretRef + 工作區無 sk- | 必改，並掃備份 |
| 瀏覽器 | 未開 | 獨立設定檔驗證後關閉 | 預設關；開則獨立設定檔 |
| Agent 隔離 | visibility=all | 收到 agent，A2A 關閉 | 第二個人格出現當天就改 |
把這張表讀成決策：OpenClaw 2.0 在 VPS 上可以安全地跑一週、也可以安全地跑一年，前提是你接受「一台 Gateway 一個信任域」，並且願意在開第二條人格、開瀏覽器、開公網反向代理之前重新跑 audit。缺的不是新功能，是把預設的「我信任操作員」改成你真實的威脅模型。
怎麼收口：一張按場景的清單
不要追求一次配到「企業級零信任」。按你今晚就要上線的場景，把必須同時成立的條件寫下來。條件打架時，拆機器比在同一套設定裡疊例外更便宜。
| 場景 | 最低可接受 | 建議姿勢 | 明確不要 |
|---|---|---|---|
| 自己用的文字助手 | loopback + 配對 + 金鑰 600 | 再加 SecretRef、工作區限制 | Gateway 綁 0.0.0.0 且無 token |
| 家人／同事共用一台 | per-channel-peer + 可見性 agent | 唯讀人格沙箱，A2A 關閉 | 共用主工作階段、共用瀏覽器設定檔 |
| 要瀏覽器技能 | 獨立設定檔 + 私網控制面 | 沙箱瀏覽器容器，SSRF 保持預設 | 個人 Chrome、Funnel 公網 |
| 不同客戶或業務線 | 獨立 Gateway + 獨立憑證 | 最好獨立 OS 使用者或獨立 VPS | 靠 RBAC 冒充租戶隔離 |
生產上還有兩件與「安不安全」綁定、但常被當成維運瑣事的事：日誌裡打出 token，以及外掛熱載入來路不明的套件。前者打開官方的脫敏與輪替；後者把 plugins.allow 寫成明確名單。做完這兩件，再談要不要把 Gateway 從 Linux 值班機遷到另一套控制面。
FAQ
只跑文字通道，不改預設，能撐過公網掃描嗎？
本機安裝 + loopback，公網掃不到 Gateway，這一條預設就成立。撐不住的是「有人已經能私訊你的機器人」之後的工具面。先鎖配對，再談掃連接埠。
Docker 安裝是不是天生更安全？
映像邊界有助於回滾和檔案系統隔離，但官方容器預設暴露綁定，連接埠對應還會繞過主機 INPUT 規則。不配認證、不複測公網，Docker 比本機安裝更危險，不是更安全。
openclaw security audit --fix 能代替手改嗎？
不能。它只做安全範圍內的收口：群組策略改回白名單、權限改回 600/700。不會替你開沙箱、遷 SecretRef、改工作階段可見性。
模型會不會自己把 API Key 讀出來？
只要明文還在 Agent 可讀路徑上，檔案工具或 exec 就能讀。SecretRef 降低落盤面，但不是行程隔離。不信任的內容不要和宿主機 exec 同時開。
金鑰產生放雲端 Mac，閘道繼續留在 Linux
Linux VPS 適合常駐 OpenClaw Gateway：映像標準、systemd 資料齊、按量便宜。但不適合把 SSH 私鑰、模型主金鑰和瀏覽器個人設定檔長期堆在同一套已被 Agent 寫過檔案的工作區裡。Apple Silicon 待機大約 4W，macOS 的 Gatekeeper、SIP 與 FileVault 把惡意軟體面壓得很低，當機率也明顯低於同價位長年開著 Docker 的雲端主機，適合當「操作員側」的值班機：產生金鑰、跑本機隧道用戶端、偶爾做一次需要桌面的驗收。
更穩的拆法是：Linux 雲端主機只跑 Gateway 和遠端 API，雲端 Mac mini 只放你不打算交給 Agent 的憑證與 macOS 工具鏈。Homebrew、SSH、Docker 在 Mac 上開箱即用，也不用為了多一個瀏覽器技能去和日誌碟搶同一套權限模型。
如果你已經按本文把五張檢查單收完，下一步是給金鑰和桌面控制留一台不跟 Agent 搶信任域的機器——VPSSpark 雲端 Mac mini M4 就是這個位置。立即了解方案，按週加一台控制面，比把所有金鑰繼續留在同一台 VPS 上更對得起這 7 天的檢查。