夜雨聆风如果你最近正准备把 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 上跑
这个坑很隐蔽。
很多人以为“默认就已经很安全”，其实只是默认值看起来安全。
沙箱是能力，不是心理安慰。
推荐的最小权限思路
如果你想把 OpenClaw 配成“不太容易失控”，我建议按官方 hardened baseline 的思路来：
• 默认 tools.profile: "messaging"• 默认禁掉 automation、runtime、fs、sessions_spawn、sessions_send• fs.workspaceOnly: true• exec.ask: "always"• exec.security: "deny"或至少尽量严• elevated.enabled: false
然后只给极少数可信 Agent单独开更高权限。
不是每个 Agent 都有资格活成 root 用户。
多 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*开关只是应急用，不是最佳实践
这才是靠谱系统该有的样子。
安全从来不是“配置完就毕业”。
它更像一个排序问题：
先把最危险的口子堵上，再把高权限能力关进小房间，最后接受一个现实——你不是在追求绝对安全，你是在持续减少一次失误会炸多大。
这就够专业了。
