OpenClaw 安全指南:别急着公网暴露,先补上这 6 道防线

如果你最近正准备把 OpenClaw 接进飞书、Telegram、Discord，甚至打算再开浏览器、开 exec、顺手暴露个远程入口，那我先给一个不太客气的结论：

OpenClaw 最容易出事的，不是模型不够聪明，而是权限边界没立住。

很多人一上来就会默认：

• 私有部署了，应该挺安全
• 加了沙箱，应该差不多了
• 反正都是自己人用，开放一点也没事

真相通常没这么乐观。

文章有点长，依据 OpenClaw 官方文档做了总结。

如果只看 30 秒，你记住 3 句话就够了：

1. OpenClaw 的默认安全模型是 personal assistant，不是多人对抗场景下的多租户平台。
2. 真正高危的组合，是开放入口 + 高权限工具。
3. 最佳实践不是追求“绝对安全”，而是持续缩小 blast radius。

说白了，别把它配成“谁都能聊、谁都能调工具、还能顺手控制浏览器和文件系统”的公共机器人。那种配置，功能很爽，安全很脆。

一、第一道防线：先搞清楚 OpenClaw 把什么当安全边界

OpenClaw 官方安全文档讲得很直白：它默认假设一个 Gateway 对应一个可信操作边界。

翻成人话就是：

• 一个人，或者同一信任边界内的一组人
• 一个独立的 Gateway
• 一套独立的凭据、会话、工具权限和运行环境

它不是按“多个互不信任的用户，共用一个 Agent / Gateway”这个方向设计的。

这点特别重要。因为很多人最常见的误配就是：

我把 OpenClaw 接进公司群、公开群、多个频道，再给它浏览器、exec、文件系统、第三方 Skill，让大家都能用。

看起来像是在做协作，实际上更像是把“私人助理”硬拽成“多租户控制总线”。

官方文档的意思可以压缩成一句话：

如果多个人能给同一个高权限 Agent 发消息，那这些人本质上共享的是同一套被委托出去的工具能力。

所以第一条规则不是参数，而是架构：

什么情况下应该拆 Gateway / 拆运行环境？

只要满足下面任意一条，我都建议拆：

• 个人和公司场景混用
• 家庭成员、同事、客户共用一个高权限 Agent
• 一个 Agent 既能读私密数据，又能执行工具操作
• 你希望不同人之间形成真正隔离，而不是“礼貌隔离”

更直白一点：

• 个人助理 → 一个独立 Gateway
• 团队业务 Agent → 一个独立 Gateway
• 公开体验型机器人 → 再单独一个最小权限 Gateway

别图省事把三种东西塞进同一个实例里。这个决定，往往比你后面怎么配 token 更重要。

二、第二道防线：网络入口先收口，别一上来就暴露在外面

OpenClaw 官方网络模型的推荐姿势很明确：

• 默认优先 loopback
• Gateway WebSocket 默认走 ws://127.0.0.1:18789
• 一旦不是 loopback bind，就必须配 token / password 这类共享认证

这其实已经是在替你踩刹车。

最推荐的远程访问方式是什么？

官方建议可以概括成这个优先级：

1. loopback + SSH tunnel
2. loopback + Tailscale Serve
3. 真的需要时再直接 bind 到 tailnet
4. 公网暴露是最后手段，不是默认路线

原因很简单：只要 Gateway 不直接裸露在 LAN / 公网上，攻击面就会小很多。

有 3 个点特别值得记住

1）Control UI 能开，不等于应该裸开

OpenClaw 的 Control UI 和 Gateway 走同一端口，而且官方文档明确写了：

• 新浏览器 / 新设备第一次连 Control UI
• 即使你已经在同一个 Tailnet 里
• 也仍然需要一次性设备批准

这其实是好设计。它避免了“进了内网就自动有控制权”这种偷懒式信任。

2）Tailscale Serve 比直接暴露舒服得多

官方推荐的姿势是：

• Gateway 保持 bind: "loopback"
• 用 Tailscale Serve 提供 HTTPS 和访问入口

这样做的现实好处非常多：

• 入口更干净
• 少很多公网暴露的坑
• Control UI / WebSocket 的访问体验也更稳

但这里有一个经常被忽略的前提：

如果网关主机上还跑着你不完全信任的本地代码，就不要过度依赖 tokenless 的 Tailscale 身份信任。

官方文档写得很清楚：这种信任模型默认建立在“网关主机本身可信”的前提上。

3）Funnel 是 break-glass，不是日常模式

Tailscale Funnel 走的是公网 HTTPS。官方要求它必须配 shared password 才能启动，这个约束本身就在提醒你：

这是高风险入口，不是图省事的默认项。

一个很容易被忽略的危险信号

Control UI 在不安全 HTTP 环境下，浏览器会受限。OpenClaw 提供了像 allowInsecureAuth、dangerouslyDisableDeviceAuth 这类兼容 / 应急开关。

注意它们的名字。

字段名里带，通常就不是拿来长期挂着跑生产的。

三、第三道防线：入口控制比模型多聪明更重要

很多人谈 Agent 安全，第一反应都是 prompt injection。

但在真实部署里，更常见的问题其实是：

压根不该让谁都能把话递到它面前。

OpenClaw 在消息入口上其实给了不少硬控制：

• DM policy：pairing / allowlist / open / disabled
• Group policy：allowlist / open / disabled
• mention gating：群里必须 @ 才响应
• sender allowlist：限制群内到底哪些人能触发
• session scope：不同对话是不是共用同一个主会话

这里最重要的不是“会怎么配”，而是“别怎么配”

1）`dmPolicy="pairing"` 才是正常起点

官方 pairing 文档写得很清楚：

• 陌生发信人先拿到一个短码
• 你没批准前，消息不会被处理
• 配对码默认 1 小时过期
• pending 请求还有上限，不会无限堆积

这其实就是把“谁有资格和助理说话”变成了一次显式授权。

2）`groupPolicy="open"` 是高风险配置

这一点，不只是文档提醒，官方审计工具也会直接报警。

我本地跑了 openclaw security audit --json，其中有两类 finding 直接是 critical：

• open groupPolicy + elevated tools
• open groupPolicy + runtime/filesystem tools exposed

这不是小题大做。

因为一旦群是开放触发，而 Agent 又能 exec、读文件、控浏览器、做自动化，你其实就是把高权限入口交给了“任何能说话的人”。

3）多人 DM 场景下，`session.dmScope` 一定要收紧

官方安全文档明确建议：

• 多人都可能 DM 机器人时，优先用 session.dmScope: "per-channel-peer"
• 多账号场景下，再考虑 per-account-channel-peer

为什么？

因为你不想让多个发送者共享同一个主上下文。

隐私只是表层问题，更大的问题是：共享会话会放大误触发、上下文污染和越权风险。

一个简单判断标准

如果你的机器人在群里符合下面任何一种情况，就该立刻收口：

• 不用 @ 就能回
• 群本身没有 allowlist
• 群里任何人都能触发工具
• 共享主会话

这种配置，在功能上很丝滑，在安全上也会很丝滑地出事。

四、第四道防线：真正决定破坏半径的，不是模型，是工具权限

Prompt injection 真正危险，不是因为模型“被骗”了。

而是因为模型一旦被骗，它后面连着什么工具。

OpenClaw 官方安全页有一句话我很认同：

系统提示词只是软约束，真正的硬约束来自 tool policy、exec approvals、sandboxing 和 channel allowlists。

这句话几乎可以当成 OpenClaw 安全设计的总纲。

哪些工具默认就该更谨慎？

官方文档反复点名这些工具风险更高：

• exec
• browser
• web_fetch
• web_search
• 运行时 / 自动化 / 文件系统类工具

最危险的不是单个工具，而是组合：

• 浏览器能访问账号态页面
• 文件系统能读本地敏感文件
• exec 能执行命令
• message/send 又能把结果发出去

这几样一串起来，攻击面的量级就完全不一样了。

一个非常容易误解的坑：`exec` 看起来像沙箱，实际未必

官方安全页特别提醒了一个细节：

• tools.exec.host 看起来默认像是 sandbox
• 但如果 sandbox mode 压根没开，exec 实际就是在 gateway host 上跑

这个坑很隐蔽。

很多人以为“默认就已经很安全”，其实只是默认值看起来安全。

沙箱是能力，不是心理安慰。

多 Agent 不只是方便，更是安全分层

OpenClaw 官方也明确支持 per-agent 的 sandbox + tool policy。

这是我非常推荐的模式：

• 个人主 Agent：高权限，但只在私域使用
• 阅读 / 总结 Agent：只读、少工具
• 公开群 Agent：最小权限，最好没有文件系统 / exec
• 团队 Agent：业务专用账号、业务专用浏览器、业务专用凭据

这样做的核心不是架构优雅，而是：

把一次误操作的影响限制在一个小房间里。

五、第五道防线：密钥、OAuth、凭据，别靠“放在配置里应该没事”这种乐观心态

OpenClaw 的凭据体系，官方文档已经写得很清楚了。

1）长期运行的 Gateway，优先 API Key

官方认证文档的建议很明确：

• 长期在线的 Gateway，优先 API key
• 对 Anthropic，官方文档明确写了：API key 是更稳妥的推荐路径，比 subscription / setup-token 更可预测

这不是道德判断，是运维判断。

因为 always-on 系统最怕的，就是认证状态飘。

2）能不用明文，就别把 secret 直接塞进配置

OpenClaw 支持 SecretRef，而且不是一句“支持外部密钥管理”就草草带过，它把行为边界写得很细：

• 支持 env / file / exec 三种 source
• 启动时对有效 surface 做 eager resolve
• 有效 SecretRef 解析失败会 fail fast
• reload 用 atomic swap：要么全成功，要么保留 last-known-good snapshot

这套设计挺重要，因为它减少了“运行中临时取 secret 导致系统随机炸”的概率。

简单理解：

• env：适合本机或 systemd / launchd 注入
• file：适合本地受控密钥文件
• exec：适合对接 1Password、Vault、sops 这类外部 secret provider

3）OAuth 不是不能用，但要理解它的存储模型

OpenClaw 的 OAuth 文档里有一个很关键的概念：token sink。

它的意思是：

• 运行时尽量统一从 auth-profiles.json 这一套资料里读凭据
• 尽量减少多个工具 / 多个入口互相覆盖 refresh token 的问题

另外，官方还明确建议：

• 如果你真要把“个人”和“工作”完全隔离，优先拆成不同 agent
• 不要把多账号、多身份塞进同一个 agent 里硬路由

我非常赞同这一点。

很多时候，最好的“密钥隔离”不是更复杂的 JSON，而是单独的运行边界。

六、第六道防线：把“不可信内容”当成真正的敌人，而不是把锅都甩给陌生人

OpenClaw 官方安全文档对 prompt injection 的态度非常现实：

它没有说“我们解决了 prompt injection”。

相反，它明确写了：

• prompt injection 没有被解决
• system prompt 只是软约束
• 即使只有你自己能发消息，prompt injection 仍然可能通过网页、邮件、附件、日志、文档、代码片段发生

这才是对的。

真正危险的，不只是“谁在跟它说话”

还有：

• 它读了哪个网页
• 它打开了哪个文档
• 它总结了哪段日志
• 它访问了哪个浏览器页面
• 它装了哪个第三方 Skill

1）外部内容默认就该当成 hostile

官方安全页明确建议：

• 把链接、附件、粘贴的指令都当不可信内容
• hook payload 也算不可信内容
• 除非是紧急调试，否则不要打开 allowUnsafeExternalContent 这类绕过 external-content safety wrapping 的开关

换句话说：

你信任发送者，不代表你就该信任发送者转给你的内容。

2）浏览器控制不是“更方便的爬虫”，而是“接近操作员权限”

OpenClaw 官方文档对 browser control 的风险描述其实挺重，我觉得这很对。

几个重点：

• 对远程 Gateway 来说，browser control 应被视为接近 operator access
• Chrome extension relay 不是更安全，它能接管你现有的 Chrome tab
• 如果那个浏览器 profile 里已经登录了很多账号，那它本质上就能“以你身份行动”

所以浏览器这块的正确思路是：

• 用独立浏览器 profile
• 尽量关掉同步和密码管理器
• 下载目录隔离
• 不需要就把 browser proxy / relay 关闭
• Gateway 和 node 尽量保持 tailnet-only

3）SSRF 不只是后端开发者才关心的词

OpenClaw 官方安全页还提到一个很容易被忽略的点：

浏览器 SSRF policy 在 trusted-network 模型下，默认是允许 private network 的。

也就是：

• browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: true 是默认语义（未显式配置时）

如果你想走严格模式，官方建议：

{  browser: {    ssrfPolicy: {      dangerouslyAllowPrivateNetwork: false,      hostnameAllowlist: ["*.example.com", "example.com"],      allowedHostnames: ["localhost"]    }  }}

这个配置背后的意思很简单：

不要默认让浏览器 / 网络工具去碰内网、私网、特殊地址。需要例外，再白名单开。

4）第三方 Skill 是供应链，不是“装个插件玩玩”

OpenClaw 官方 threat model 已经把 skill 供应链列成重点风险面，里面明确提到：

• 恶意 skill 安装
• skill 更新投毒
• moderation 被绕过
• skill 读取凭据 / 上下文导致数据被偷

官方也在做 GitHub 账号年龄校验、模式匹配、后续 VirusTotal 等机制，但从官方 threat model 的语气看，团队自己都没有把它包装成“这就很安全”。

这反而让我更放心。

因为成熟的安全态度从来不是“我们没问题”，而是“这些地方就是高风险，你别装作看不见”。

所以我对第三方 Skill 的建议很朴素：

• 只装你真的需要的
• 能固定版本就固定版本
• 不要在高权限 Agent 上随便装来源不明的 skill
• 把 skill 当成代码执行边界，而不是 UI 插件

一个够用的安全基线配置（适合大多数个人部署）

下面这份思路，基本就是 OpenClaw 官方 hardened baseline 的方向。我把它翻成了更容易落地的版本：

{  gateway: {    mode: "local",    bind: "loopback",    auth: { mode: "token", token: "replace-with-long-random-token" }  },  session: {    dmScope: "per-channel-peer"  },  tools: {    profile: "messaging",    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],    fs: { workspaceOnly: true },    exec: { security: "deny", ask: "always" },    elevated: { enabled: false }  },  channels: {    whatsapp: {      dmPolicy: "pairing",      groups: {        "*": { requireMention: true }      }    }  }}

它不是万能模板，但至少表达了正确方向：

• 网关不乱暴露
• 身份先认证
• 会话先隔离
• 工具先最小化
• 群聊先 mention gate

等你真的理解每一层风险之后，再逐步放开能力。

最后给你一份真正能执行的清单

如果你今天就要把 OpenClaw 配得更安全一点，我建议按这个顺序来：

P0：先做，不要拖

• [ ] Gateway 先保持 bind: "loopback"
• [ ] 配 token 或 password，不要裸跑
• [ ] 所有 DM 默认走 pairing
• [ ] 所有群默认 allowlist + requireMention
• [ ] 改 session.dmScope: "per-channel-peer"
• [ ] 默认不要给公开 / 群聊 Agent 开 exec、fs、elevated
• [ ] 跑一次 openclaw security audit

P1：很值，尽快做

• [ ] 需要远程访问时，优先 Tailscale Serve 或 SSH tunnel
• [ ] 密钥改成 SecretRef（至少 env）
• [ ] 浏览器改独立 profile
• [ ] 第三方 Skill 做最小安装、尽量固定版本
• [ ] 只把高风险工具给少数可信 Agent

P2：你要长期用，就别省这点力气

• [ ] 个人 / 工作 / 公开机器人拆成不同 Gateway 或不同运行边界
• [ ] 给不可信内容准备专门的 reader agent
• [ ] 把 SSRF policy 改成严格模式，再按需加 allowlist
• [ ] 定期跑 openclaw security audit --deep
• [ ] 了解 --fix 能修什么、不能修什么（它不会替你轮换密钥，也不会替你关掉危险工具）

结尾

我越来越觉得，Agent 安全里最危险的一种幻觉，不是“模型绝对可靠”，而是：

我都私有部署了，应该已经很安全了。

不是。

私有部署只能说明“东西在你手里”，不能说明“权限边界就是对的”。

OpenClaw 在这件事上的态度，其实挺成熟：

• 它没有假装 prompt injection 已经解决
• 它没有假装一个 Gateway 天生适合多人混用
• 它提供了 pairing、allowlist、sandbox、SecretRef、audit、device approval 这些硬机制
• 同时也明确告诉你，哪些 dangerously* 开关只是应急用，不是最佳实践

这才是靠谱系统该有的样子。

安全从来不是“配置完就毕业”。

它更像一个排序问题：

先把最危险的口子堵上，再把高权限能力关进小房间，最后接受一个现实——你不是在追求绝对安全，你是在持续减少一次失误会炸多大。

这就够专业了。