搜索这篇的人通常遇到什么问题
用户搜索 OpenClaw 安全、OpenClaw gateway security 或 OpenClaw allowlist 时，往往已经不满足于“跑起来”。他们准备把 OpenClaw 放进真实渠道、Browser 登录、webhook 自动化或团队环境里，担心的是：谁能连进来、哪些动作会被自动执行、token 泄露后怎么止损、扩展能力会不会越权。
这篇的目标不是制造恐惧，也不是把所有能力都关掉，而是给你一套能落地的默认基线。安全加固做得好，OpenClaw 仍然可以自动化；只是每个入口、权限和高风险动作都有明确边界。
官方资料给出的边界
OpenClaw 官方资料把安全拆在 CLI security、Gateway security、Control UI 和 Skills 等页面里。把这些页面放在一起看，可以得到几个稳定结论：
| 能力面 | 安全含义 | 加固目标 |
|---|---|---|
| CLI / 本地环境 | API Key、配置、运行用户、日志目录 | 不把敏感配置暴露给错误用户或仓库 |
| Gateway / channels | 远程入口、pairing、channel 访问范围 | 默认拒绝陌生入口，明确谁可以触发 |
| Control UI | 状态、审批、会话和可观测入口 | 高风险动作必须可确认、可追踪 |
| Skills / Plugins | 把操作流程变成可复用能力 | 上线前审查权限、输入、输出和变更责任 |
风险边界也要说清楚：AgentClaw 不是官方安全公告，也不能替代你的安全审计。生产环境里的网络暴露、身份系统、密钥存储、审计留存和合规要求，仍应以官方文档、你的基础设施和团队安全策略为准。
上线前先做 5 件事
1. 先画入口图，不要先调参数
先列出 OpenClaw 当前能被谁触发：
入口清单：
- 本机 CLI
- Gateway 暴露地址
- Telegram / WhatsApp / 其他 channel
- Browser 登录流程
- webhook / automation hooks
- Control UI 管理入口每个入口都要回答三个问题：谁可以触发、触发后能做什么、出问题时如何暂停。回答不出来的入口，不应该进入长期运行。
2. Gateway 默认收紧
Gateway 是安全加固的核心，不是普通“连接件”。它把外部消息、授权、工具能力和本地执行环境连接起来，所以默认策略应该偏保守：
- 新 channel 先走 pairing 或 allowlist，不要默认开放给所有联系人或群组。
- 群聊场景默认要求 mention、固定命令前缀或明确授权人，避免旁路触发。
- 面向公网的 gateway 要有反向代理、TLS、访问控制和日志留存方案。
- 临时测试 token、一次性 webhook secret 和旧 channel 配置要有清理时间。
如果你还没有把 gateway 放到公网，只做本地或内网测试，也不代表可以跳过这一步。越早建立入口清单，后面迁移到云端越不容易漏。
3. 把高风险动作放进审批
审批不是所有动作都点一次确认，而是把真正有损失的动作拦下来。建议先把下面几类动作列为高风险：
| 动作类型 | 为什么高风险 | 建议策略 |
|---|---|---|
| 登录、授权、支付、提交表单 | 会影响真实账号或资金 | 必须人工确认 |
| 修改配置、轮换凭据、删除资源 | 影响运行稳定性 | 至少二次确认并记录原因 |
| 外发消息、群公告、客户回复 | 会影响外部关系 | 测试环境先 dry run |
| 安装 Skills / Plugins | 会扩大能力面 | 先审查，再加入共享库 |
审批边界要写在 playbook 里，不要只靠“大家都知道”。如果一个动作是否需要审批要靠现场争论，说明边界还没定义好。
4. 凭据只给最小范围
OpenClaw 真正进入工作流后，会接触 API Key、channel token、browser session、webhook secret 或云端部署密钥。最小权限的做法不是“少配几个变量”，而是把每个凭据的用途、归属和轮换方式写清楚。
凭据登记表建议字段：
- 名称：TELEGRAM_BOT_TOKEN
- 用途：只用于 Telegram channel
- 保存位置：本机环境变量 / Secret manager
- 可访问者：owner + backup owner
- 轮换周期：30-90 天或事故后立即轮换
- 下线条件：channel 停用、owner 离职、异常触发不要把生产 token 放进教程截图、Markdown、issue、聊天记录或共享 prompt。尤其是团队内推广时，最容易出现“为了方便排错，先把 token 发群里”的低级事故。
5. 扩展能力先审查再复用
Skills 和 Plugins 的问题不在于它们危险，而在于它们会把一次操作变成长期可重复动作。安全审查至少要看四件事：
- 输入：是否会接收用户消息、文件、网页内容或外部 webhook。
- 权限：是否需要文件系统、网络、浏览器登录或生产系统访问。
- 输出：是否会自动外发消息、提交表单、创建工单或改配置。
- 维护：谁负责更新，什么时候回滚，失败后通知谁。
如果一个 Skill 只是个人实验，可以放在个人目录；如果要共享给团队，就应该进入审查清单和版本记录。
可执行安全基线
把下面清单作为第一次加固的完成标准：
- Gateway 暴露地址、channel、pairing 策略已经记录。
- 每个 channel 都有 allowlist、mention 或授权人策略。
- Control UI 或等价管理入口能查看关键状态、审批和历史记录。
- 高风险动作列表已经写入团队 playbook。
- 生产 token 不存在于仓库、截图、聊天记录和公共文档。
- Skills / Plugins 有审查人、测试环境和回滚方案。
- 事故时知道先暂停哪些入口，后续按事故预案处理。
常见误区
误区一：只要不放公网就安全
内网或本地环境仍然会有 token 泄露、错误 channel、扩展越权和团队误用。公网暴露只是其中一种风险。
误区二：只做 allowlist 就够了
allowlist 解决“谁能进来”，不能解决“进来后能做什么”和“出了事如何回溯”。审批、日志和凭据轮换要一起做。
误区三：把审批做成所有动作都点确认
过度审批会让团队绕过流程。更实际的做法是：低风险动作快速通过，高风险动作明确拦截。
误区四：先推广，出事再补
OpenClaw 一旦进入真实工作流，后补安全会牵涉已安装扩展、已有 token、已接 channel 和用户习惯，成本会高很多。
下一步怎么走
如果你已经完成安全基线，下一篇建议读 OpenClaw 安全事故演练，把止损、排查、轮换和复盘流程写出来。准备团队化推广时，再读 OpenClaw 团队落地手册。如果你还没有定义审批入口，先补 OpenClaw Dashboard 审批流。