把 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 本机。对「我信任自己」的个人助手，这很顺手；对「通道里会出现链接、附件、转发」的值班机，这等于把提示词注入的终点接到了 root 或部署用户的 shell。
第 1 天的 audit 稳定打出两类信号：工具爆炸半径偏大，以及 security="full" 这一条——官方说它是受信任操作员的默认体验，不是漏洞。我们的取舍是：个人主 Agent 可以暂时保留宿主机执行，但必须同时满足三件事：通道配对、文件工具限工作区、tools.elevated 关掉。家庭或公开入口的第二个 Agent，必须 sandbox.mode: "all"，工作区 ro 或 none，并拒绝 exec / browser / gateway / cron。
目录权限比很多人想的更容易漂。把配置从笔记本 scp 上去、用 Docker 卷映射、或者让 Agent 自己 cp 过 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，而不是只看容器内 ss。最小暴露面、安全组与回环的取舍，可以对照站内这篇 OpenClaw Linux 云主机最小暴露面与 SSH/HTTPS 决策，再回到本文看「跑一周之后有没有被人改成 0.0.0.0」。
节点配对也算 SSH 面。OpenClaw 可以在配对时用操作员 SSH 回读设备身份（sshVerify），这不是「能连上就自动批准」。不要把 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、生成出来的 agents/*/agent/models.json、退休的 auth-profile 归档。提示词注入不需要攻破 SSH，只要模型愿意「把配置读出来发到聊天里」。官方 OpenClaw 密钥管理文档 把迁移完成的标准写得很硬：支持的字段都改成 SecretRef、旧明文被擦掉、openclaw secrets audit --check 干净；剩下不支持 SecretRef 的轮换类凭证，用操作系统用户、容器或外部代理隔开。
Gateway token 要单独看待。能调用 /v1/chat/completions、/tools/invoke 或管理 RPC 的共享密钥，官方直接称为全权操作员密钥。不要把它写进 Agent 工作区，不要塞进技能仓库，不要为了方便分享给第二个机器人。轮换清单很短：生成新 token、重启 Gateway、改远程客户端、确认旧值失效。第 3 天我们把模型 Key 迁到环境变量 SecretRef，把 Gateway token 留在仅 root/部署用户可读的环境文件里，工作区里不再出现 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 远程端口，按「能看见标签页 = 能当这个人」来管。现有会话模式并不更安全，它只是更像你。节点如果跑在另一台有桌面的机器上，节点配对就是管理员权限；Gateway 和节点必须落在同一套私有网络里。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" 让所有人共用一个沙箱容器。DM 如果会进多个人，把 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 天的检查。