只要 OpenClaw 不再是你本机里临时开一下的命令行工具，而是一个长期在线、能接消息渠道、能跑工具、能访问工作目录的 Gateway，安全就必须从“以后再说”变成“先设计好边界再开放能力”。官方文档在很多地方都体现了同一个思路：默认 loopback、默认审批、默认最小授权。
为什么长期在线系统一定要把安全放前面
长期在线的 OpenClaw 至少会面对三类风险：
- 谁能连接进来
- 连进来后能触发什么能力
- 真正执行时最多能做到什么程度
这三层风险不能靠同一种机制一次性解决。你需要分别处理：
- 网络可达性
- 渠道与身份边界
- 工具与执行权限
只要其中一层过宽，系统整体就会变得脆弱。
第一层边界：谁能访问 Gateway
官方推荐的默认做法非常保守：
- Gateway 尽量只监听本地地址
- Dashboard 优先通过 SSH 隧道或私有网络访问
- 真正需要公网 webhook 的场景，只单独暴露必要路径
这就是为什么前面的教程里一直建议：
- Dashboard 先不要裸露到公网
- Google Chat 只暴露
/googlechat - Tailscale 或反向代理只转发必要端点
你可以把这一层理解成“谁有机会敲你的门”。
第二层边界：谁被允许真正和智能体对话
哪怕 Gateway 本身可达，也不等于所有人都能随便对话。官方在渠道侧大量使用了这类机制：
pairingallowlistrequireMention- 私聊 / 群组不同策略
例如：
- Telegram、飞书、Google Chat 私聊都可以先要求配对
- 群组默认要求
@提及 - 某些空间、群、频道可以只允许特定成员使用
这一层解决的是“门开了以后，谁被允许真的进来”。
第三层边界：工具到底能做到什么
哪怕用户已经通过了配对，真正高风险的还是工具执行层。OpenClaw 的能力可能包括：
- 执行 shell
- 访问文件
- 读写工作目录
- 访问网页
- 调系统能力
这时就不能只靠“系统提示词里写一句谨慎一点”来兜底。更可靠的做法是：
- 默认审批
- 默认最小权限
- 只给需要的工作目录
- 对危险工具保留人工确认
默认保守意味着什么
在真实部署里，默认保守通常意味着：
- Dashboard 不直接开公网
- 第一个渠道先用配对模式
- 群组默认
requireMention - 没有明确需求时，不开放高风险执行工具
- 不把整台主机的所有目录都交给智能体
很多人会觉得这让体验“没那么爽”，但长期使用后你会发现，这才是能稳定扩展的基础。
批准、审批和沙箱为什么是三回事
这三个词经常被混用，但其实可以分开理解：
- 批准：允许某个用户、设备或会话开始交互
- 审批：允许某次高风险动作继续执行
- 沙箱：即使执行了，操作范围仍然受限
这三层各自承担不同责任：
- 配对解决“谁是可信用户”
- 审批解决“这次动作要不要放行”
- 沙箱解决“放行后最多能做到什么”
只有三层都存在，长期在线系统才真的稳。
什么时候最容易出事故
最危险的组合通常是下面这种：
- Gateway 长期在线
- 控制台可从公网直接打开
- 机器人在多个群里都能自动回复
- 工具执行不需要审批
- 工作目录权限过大
这几件事单看任何一件都未必立刻出问题，但一旦叠在一起，风险会明显放大。
推荐的上线节奏
如果你准备把 OpenClaw 用到长期环境里，我建议按这个顺序慢慢放开：
- 先让 Gateway 只在本地或私有网络可达
- 第一个渠道先开
pairing - 群组默认保留
requireMention - 工具执行先启用审批
- 确认日志、状态和回滚路径都可用后，再逐步开放更多能力
这样做的好处是，一旦某一层边界放得太宽，你能立刻定位是哪一层，而不是全系统都处在不确定状态。
最常见的误区
误区 1：只有团队或公司才需要安全策略
个人用户同样需要。只要你的 OpenClaw 能执行真实动作、能长期开着、能从外部渠道被触发，安全就已经是日常问题。
误区 2：把所有风险都交给系统提示词
系统提示词只能影响行为倾向，不能替代真正的权限控制和审批。
误区 3：先全开，用的时候再慢慢关
实际经验通常相反。长期系统更适合“先保守，再逐步开放”。
一条最实用的原则
把 OpenClaw 当成一个会长期在线、能接收外部输入、能触发真实动作的系统，而不是一个临时脚本。只要你按这个视角去设计，就会自然做出更稳妥的决策：
- 先缩小访问面
- 再限制可交互对象
- 最后才讨论工具能做到什么
这三层边界一旦清楚，OpenClaw 才适合长期托管关键工作流。