如何保护你的 OpenClaw Agent
一篇实用硬化指南：讲清楚 OpenClaw 的信任边界、`openclaw security audit`、sandbox、secrets 管理，以及最危险的配置项到底有哪些。
如何保护你的 OpenClaw Agent
OpenClaw 的安全，不是靠一个开关解决的。
官方文档把信任模型写得非常明确：OpenClaw 默认是“个人助手”模式，也就是每个 gateway 只服务一个可信操作者边界。它不是为“多个互相不信任的用户共用一个高权限 agent”这种场景设计的。
这句话比任何后面的配置都重要。因为只要信任边界设错，后面的所有硬化其实都建立在错误前提上。
第一条安全原则：先把信任边界分开
官方文档说得很直白：
- 一个 gateway 对应一个可信操作者边界
- 一个共享 gateway 不是给互相对抗的用户当隔离边界用的
- 如果有混合信任或对抗用户，应该拆成不同 gateway、不同凭证，最好连 OS 用户或主机都拆开
落到实际部署里，就是：
- 你自己的个人 OpenClaw，跑在自己机器或 VPS 上，没问题
- 一家人共用一个低权限助手，风险已经上来了
- 多个互不信任的人共用一个高权限 agent，这是设计方向就错了
如果几个人都能给同一个工具型 agent 发消息，那本质上他们都在共享同一套委托权限。
最快的第一步：跑 openclaw security audit
官方直接推荐你定期跑：
openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json
什么时候该跑：
- 你改了配置之后
- 你暴露了新的网络入口之后
- 你新接了一个消息渠道之后
- 你配了新的浏览器控制或 node host 之后
- 你放宽了 agent 权限之后
文档里说明它会检查的高风险点包括：
- gateway 鉴权暴露
- 浏览器控制暴露
- 过宽 allowlist
- 危险配置开关
- 文件系统权限
- 过松的 exec 审批
--fix 可以帮你自动修掉一部分常见脚枪，但不要把它理解成“一键加固完成”。
最危险的错误，通常不是没加密，而是权限给太大
很多 OpenClaw 安全事故，问题不在加密算法，而在边界控制。
如果你的 agent 能：
- 读邮件
- 控浏览器
- 执行 shell
- 访问文件系统
- 响应公开消息渠道
那你真正该做的事，就是限制：
- 谁能和它说话
- 它能在哪些地方行动
- 它到底能碰哪些工具
一个很实用的基线：
| 表面能力 | 更安全的默认做法 |
|---|---|
| 邮件 | 先只给读和摘要，不急着给发送 |
| 浏览器 | 只放在可信机器或 node host 上 |
| Exec | 尽量限制在工作区，不要大范围放开 |
| Secrets | 用 SecretRefs，不要放明文 |
| 共享 agent | 除非同属一个信任边界，否则不要共用 |
把危险的外部内容绕过开关保持关闭
官方安全文档把这些 bypass flag 单独点名了：
hooks.mappings[].allowUnsafeExternalContenthooks.gmail.allowUnsafeExternalContent- cron payload 里的
allowUnsafeExternalContent
给出的建议非常明确：
- 生产环境里保持 unset 或
false - 只有做非常窄的调试时才短暂开启
- 一旦开启，就要把这个 agent 单独隔离，并把工具权限压到最小
这个警告很重要，因为 webhook、邮件、外部文档这些输入，就算来自你熟悉的系统，也依然可能带提示词注入。
Sandbox 一定要看“实际生效的”，不要只看配置文件
OpenClaw 有独立的 sandbox CLI，不是摆设。
先用：
openclaw sandbox explain
openclaw sandbox explain --agent work
openclaw sandbox list
openclaw sandbox recreate --all
根据官方文档，sandbox explain 会直接告诉你：
- 当前 sandbox mode
- scope 和 workspace 访问范围
- 工具策略
- 提权闸口
- 对应的修复配置路径
这比你去翻配置文件靠谱，因为它回答的是：这个 agent 现在实际上能碰什么。
另外文档也强调了一个容易被忽略的问题：你改完 sandbox 配置，旧 runtime 不一定马上跟着变。所以配置变更后，要用 openclaw sandbox recreate 强制重建。
Secrets：先审计，再迁移，再 reload
OpenClaw 的 secrets CLI 比很多人想象得更成熟。官方给的推荐流程是：
openclaw secrets audit --check
openclaw secrets configure
openclaw secrets apply --from /tmp/openclaw-secrets-plan.json --dry-run
openclaw secrets apply --from /tmp/openclaw-secrets-plan.json
openclaw secrets audit --check
openclaw secrets reload
为什么这很重要？因为官方文档明确提醒：~/.openclaw/ 下可能包含很多敏感东西，比如：
- 配置和 provider 设置
- 渠道凭证
- agent 的 auth profile
- 可选的文件型 secrets
- session transcript 和工具输出
如果你真的在做生产级部署，明文凭证就应该被视为技术债，而不是“以后再说”。
主机和文件系统的基本硬化，依然不能跳过
官方安全文档还强调了一个现实：host 和 config boundary 默认就是受信任的。
也就是说，只要有人能改 ~/.openclaw/，他本质上就已经是可信操作者了。
所以基础设施层面的基线应该至少包括：
- 如果主机共享，就给 OpenClaw 单独的 OS 用户
- OpenClaw 状态目录权限收紧
- 主机开启全盘加密
- 不要在同一台机器上随便给别人 shell
这些都很无聊，但不做的话，前面的 agent 权限控制也会失去很多意义。
浏览器控制和远程节点，默认当成高危能力看
官方文档专门把 browser control 和 node host pairing 当成高信任桥接来讲。也就是说，如果你的 gateway 在一台机器上，浏览器跑在另一台机器上，这不是“小功能”，而是一条高权限控制通道。
更安全的模式：
- gateway 和 node host 放在同一个私有网络或 tailnet
- 明确配对，不做模糊暴露
- 不要把 relay / control 端口直接暴露到公网上
更危险的模式：
- 把浏览器控制当成一个普通插件来随便开
最值得优先做的 5 个加固动作
如果你现在只能先做几件事，那就做这 5 个：
- 先把信任边界拆对
- 跑
openclaw security audit --deep - 用
openclaw sandbox explain看清楚实际沙箱策略 - 用
openclaw secrets把明文凭证迁掉 - 把高风险工具只留给真正需要的少数 agent
这比一句“注意权限安全”有用得多。
最常见的 5 个安全错误
1. 把一个 gateway 当成多租户隔离边界
官方文档已经明确说了，这不是推荐模型。
2. 让几个人共同驱动一个高权限 agent
只要他们都能发消息，本质上就是在共享同一套委托权限。
3. 长期开着外部内容绕过开关
这些 flag 是给窄范围调试用的，不是生产默认项。
4. 觉得“反正本地，所以明文也没关系”
本地明文，仍然是明文。
5. 从不检查 live sandbox
只看配置文件，不看实际 runtime，迟早会踩坑。
更合理的生产心态
OpenClaw 不是“装完就安全”。它只会在你足够有纪律的时候变得相对安全。
你真正要持续管理的是：
- 谁能和 agent 对话
- agent 能碰什么
- 哪些外部内容必须默认不信任
- secrets 存在什么形态
- 出问题时能多快审计和收权
这也是为什么官方文档把 trust boundary 和 audit 命令放得这么靠前。它在提醒你：最难的不是写配置，而是操作纪律。
快速检查清单
- 这是不是一个“单 gateway 单信任边界”的部署？
- 我有没有跑
openclaw security audit --deep？ - 外部内容绕过开关是不是都还关着？
- 我有没有用
openclaw sandbox explain检查实际生效策略？ - Secrets 是不是已经进入
openclaw secrets audit --check的管理流程？ - 高风险工具是不是只给了真正需要的少数 agent？