夜雨聆风THE SIGNAL REVIEW
深度分析
2026 年 4 月 2 日 · 星期四
大龙虾也是个人 · 长文拆解
ANALYSIS · 深读
OpenClaw 安全机制与配置实战
很多人第一次装 OpenClaw，注意力都放在“它能做多少事”上，却很少先问一句：它的权限边界在哪里？ 真正能上线的 Agent，不是能力最猛的那个，而是边界最清楚的那个。这篇就从风险面、默认护栏、高风险配置、推荐配置和自检清单五个层面，把 OpenClaw 的安全机制讲透。
OpenClaw 安全机制与配置实战
很多人第一次装 OpenClaw，注意力都放在“它能做多少事”上，却很少先问一句：它的权限边界在哪里？ 真正能上线的 Agent，不是能力最猛的那个，而是边界最清楚的那个。这篇就从风险面、默认护栏、高风险配置、推荐配置和自检清单五个层面，把 OpenClaw 的安全机制讲透。
一、OpenClaw 的风险，不只是“聊天回复错了”
很多人会把 OpenClaw 理解成聊天机器人外壳，但它本质上更像一个 Agent Gateway。它负责接入多渠道消息，把消息路由到对应 agent，再让 agent 调用本地工具、浏览器、文件系统、节点设备和外部服务。所以它的风险不是单点的，而是贯穿消息入口、工具权限、主机执行、记忆边界、设备能力的整条链路。
OpenClaw 的安全，不是一个单独开关，而是一套分层护栏。真正的问题从来不是“能不能干”，而是“谁能触发、在哪干、能干到哪一步”。
二、OpenClaw 默认有哪些安全护栏
1）Gateway 作为统一控制面
OpenClaw 推荐每台主机以一个长期运行的 Gateway 为控制面，统一管理渠道连接、会话、路由和配置状态。这样权限、日志、审计和排障都能回到同一个地方，不会散落在一堆脚本和临时服务里。
2）群聊不是天然开放环境
官方文档把群聊和私聊分得很清楚：DM 访问靠 allowFrom，群组访问靠 groupPolicy 与 allowlist，是否必须 @ 提及靠 requireMention。 这套设计本质上就是在控制“谁能把 agent 拉进场”。
3）沙箱隔离
OpenClaw 可以把 exec、read、write、edit、process 等工具放进 Docker 沙箱，而不是直接在宿主机运行。它不是绝对安全边界，但足够显著地缩小模型误操作的影响面。
4）执行审批
这套机制是 OpenClaw 很实用的一层护栏：当 agent 想在 gateway 或 node 主机上执行命令时，可以要求经过 allowlist、ask 策略甚至人工审批，而不是一句话就直通主机。
三、最危险的配置，往往都很“省事”
1）群策略直接开成 open
一旦 groupPolicy = "open"，就意味着群成员只要满足触发条件，就可以把 agent 拉起来干活。如果这个 agent 同时还具备 runtime、filesystem 甚至 elevated 工具，就不是“群里有机器人”，而是群里有一扇通向你主机能力的门。
json
{ "channels": { "feishu": { "groupPolicy": "open" } }, "tools": { "elevated": { "enabled": true } } }这种配置危险，不是因为它“看起来复杂”，恰恰是因为它足够省事、足够方便，所以特别容易被图快的人直接配上。
2）关闭设备身份校验
如果控制台设备身份校验被显式关闭，比如启用 dangerouslyDisableDeviceAuth=true，那就是在主动拆掉 Control UI 的关键护栏。这类问题在安全审计里通常会被标成 CRITICAL。
3）沙箱关了，工具还全开
如果 sandbox.mode = "off"，同时 agent 还能 exec / process / read / write / edit，那本质上就是让模型直接在主机环境里活动。对个人私聊场景都要谨慎，对群环境更不该这么配。
四、最值得优先配好的 5 个安全点
1）先收紧触发面
最小原则是：私聊白名单 + 群聊 allowlist + 默认 requireMention。 先控制谁能触发你，再去谈它能做什么。
json5
{ "channels": { "feishu": { "allowFrom": [ "user-or-openid-A", "user-or-openid-B" ], "groupPolicy": "allowlist", "groupAllowFrom": [ "user-or-openid-A" ], "groups": { "*": { "requireMention": true } } } } }公开群不是可信环境。先限制群，再限制人，再限制触发方式。这是所有 agent 安全里性价比最高的一步。
2）把非主会话塞进沙箱
对大多数个人用户来说，sandbox.mode = "non-main" 通常是可用性和安全性的平衡点：主私聊保留较强能力，群组/频道/非主会话默认进入沙箱。
json5
{ "agents": { "defaults": { "sandbox": { "mode": "non-main", "scope": "session", "workspaceAccess": "none" } } } }3）执行审批至少用 allowlist + on-miss
如果真的要让 agent 执行命令，不要一上来就 full。更稳的思路是：已知安全命令自动放行，新命令先问，UI 不可达时默认拒绝。
json5
{ "security": "allowlist", "ask": "on-miss", "askFallback": "deny" }4）公开场景单独做低权限 agent
如果一个 agent 要出现在公开群或半公开群，建议把它单独拆成一个 workspace，工具权限做减法，只保留消息型能力，不让它直接碰 runtime、filesystem 或 nodes。
5）把 MEMORY.md 当敏感资产管理
MEMORY.md 是长期记忆，不是普通聊天缓存。它应该只留在主私人 agent 里使用，不要和公开 agent 共用同一工作区。
五、一套能直接抄的安全配置骨架
如果你是个人或小团队，这套思路足够作为第一版安全基线：私聊高权限、群聊 allowlist、群组默认 @ 提及、非主会话进沙箱、公开 agent 单独拆开。
json5
{ "agents": { "defaults": { "workspace": "~/.openclaw/workspace", "sandbox": { "mode": "non-main", "scope": "session", "workspaceAccess": "none" } }, "list": [ { "id": "main", "workspace": "~/.openclaw/workspace", "groupChat": { "mentionPatterns": [ "@openclaw", "openclaw" ] } }, { "id": "public", "workspace": "~/.openclaw/workspace-public", "sandbox": { "mode": "all", "scope": "agent", "workspaceAccess": "none" }, "tools": { "deny": [ "exec", "write", "edit", "browser", "canvas", "nodes" ] } } ] }, "channels": { "feishu": { "groupPolicy": "allowlist", "groupAllowFrom": [ "your-open-id" ], "groups": { "*": { "requireMention": true } } } } }六、上线前，至少做一轮自检
最直接的方式不是猜，而是跑官方诊断：openclaw status、openclaw status --all、openclaw gateway probe、openclaw doctor。如果 Gateway 可达，再继续看 openclaw status --deep 和安全审计。
bash
openclaw status openclaw status --all openclaw gateway probe openclaw doctor openclaw status --deep openclaw security audit 真正能上线的 Agent，不是能力最强的那个，而是能力边界最清楚的那个。
企业化Agent落地加V（aoxueluoluo）领取方案
THE SIGNAL REVIEW · 深度分析
by 大龙虾也是个人
