官方资料给出的边界
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 执行审批教程
这次练习只让 Agent 查询当前目录：先拒绝，再重新请求并单次允许。你最后应能用工具记录证明两次结果的差别，而不是仅凭 Agent 说“已经执行”。
**验证范围：**已在 macOS / Node 24.15.0 的独立配置目录运行 v2026.9.2 CLI，验证 exec-policy set 和 show 返回的有效策略。真实模型发起请求、UI 拒绝和单次放行尚未完成端到端实测。先执行 openclaw --version；旧版缺少命令时应使用对应版本帮助。练习面向 macOS/Linux 测试主机。
查看本站 CLI 验证记录。记录中临时目录已替换为 <isolated-lab>，没有加入模型调用结果。
1. 先确认是哪一种授权
| 现象 | 检查入口 | 不代表什么 |
|---|---|---|
| Telegram 私聊提示配对码 | 渠道 pairing | 远程电脑已经接入 |
| 新电脑连接被拒绝 | devices 配对与连接认证 | 该设备所有命令都获准 |
| Agent 运行命令出现批准卡片 | exec approvals | 所有文件操作都会弹窗 |
| 摄像头或屏幕不可用 | 系统权限、声明能力、调用策略 | 批准一条 shell 命令即可解决 |
本页只处理第三行。执行审批也不等于文件系统隔离；命令获准后仍使用执行账号的权限。
2. 找对执行机器并记录原状态
打开 Gateway 所在机器的终端。CLI、Gateway 和 Node 可能是三台设备；本练习要求 CLI 与测试 Gateway 同机，避免把本地策略误应用到远程主机。
openclaw --version
openclaw exec-policy show
openclaw approvals get --gateway记录原 host、security、ask、askFallback 和 Agent 范围，保存在私人笔记中。不要分享带 token 的完整配置。exec-policy show 不包含会话内覆盖；在测试会话发送 /exec 查看当前会话设置。
若执行目标是 Node，本页的本地快捷设置不适用。应通过 openclaw approvals get --node "节点ID" 查询目标主机，不要为走完练习改变生产任务的主机。
3. 在测试环境要求每次询问
openclaw exec-policy set --host gateway --security allowlist --ask always --ask-fallback deny
openclaw exec-policy show
openclaw approvals get --gatewayset 会修改本地配置和本地主机审批策略，不能直接在有生产自动任务的 Gateway 上试验。这组设置选择 Gateway、使用允许列表约束、每次询问，并在无法确认时拒绝。检查输出的有效策略；若 Agent 有自己的覆盖，还要核对该范围。
UI 可查看 Nodes → Exec approvals，选择 Gateway 和正确的 Defaults/Agent，核对并保存。某些主机使用原生审批格式，遇到只读界面时按对应主机文档处理，不要强行套用其他平台的 JSON。
4. 发起只读请求，先拒绝
在测试会话粘贴：
这是一次执行审批练习。
请通过 exec 工具在 Gateway 主机只执行 pwd，输出当前工作目录。
不要读文件正文，不要改文件，不要安装软件，不要改权限策略。
如果执行被拒绝，请报告拒绝，不要换工具、改命令或自动重试。提示词表达任务，策略才控制执行。如果只有文字回答而没有工具调用，练习还没有开始。
出现卡片后核对完整命令、工作目录、主机和 Agent。练习不应包含安装、网络下载或附加命令。选择 拒绝。也可在 Gateway 终端运行：
openclaw approvals pending找到这次请求，复制完整 ID/token。下例 REQUEST_ID 必须替换，不能原样粘贴，也不能使用别的会话的 ID：
openclaw approvals resolve "REQUEST_ID" deny**拒绝验收：**工具记录显示拒绝或未获授权，没有这次命令的成功输出。Agent 根据历史上下文猜出目录不能算执行成功。记录请求 ID、决定和工具结果。
5. 重新请求，只允许这一次
让 Agent 再执行同一个练习，等待新的请求。上一条已拒绝的 ID 不能作为未处理请求批准。
确认仍是 pwd，选择 Allow Once，或运行：
openclaw approvals resolve "NEW_REQUEST_ID" allow-once**放行验收：**工具返回实际目录路径，最终回答与工具结果一致。路径应属于 Gateway 主机，而不是浏览器所在的另一台电脑。
先不用 allow-always。长期授权有自己的命令、目录或任务范围；ask=always 仍可能要求确认。单次放行也只允许尝试执行，不能保证命令最终成功。
6. 按症状排查
| 症状 | 先核对 | 不要直接做 |
|---|---|---|
| 没有卡片 | 有无 exec 调用、执行主机、有效 ask、会话覆盖 | 改成 full |
| 直接拒绝 | deny 策略、UI 是否在线、请求是否过期 | 反复批准旧 ID |
| 多条 pending | 命令、Agent、时间和目录是否匹配 | 全部允许 |
| 批准后仍失败 | 工具返回的运行时、目录或策略错误 | 把批准当成成功 |
| Node 不受设置影响 | approvals get --node 的目标策略 | 只改 CLI 本机 |
没有弹窗不一定异常：请求可能已被工具策略拒绝，或根本没走主机 exec。先找工具记录，再决定修改哪一层。
7. 保存验收记录并结束练习
下载审批验收记录模板。填写两次请求的实际结果，再确认是否保留测试策略。如果需要恢复，按第 2 步记录恢复原字段，重新运行 exec-policy show 核对。
没有一条通用的“恢复默认”命令可以代替你的原配置，尤其不要把 preset yolo 当成清理步骤。一次性测试环境可以保留严格策略并停止该测试 Gateway。
OpenClaw 安全事故演练
先分级，不要一开始就全站停机
OpenClaw 常见安全事件可以分三档：
| 级别 | 典型信号 | 第一动作 |
|---|---|---|
| P3 轻微异常 | 单次误触发、低风险消息发送失败、测试 channel 噪声 | 暂停相关自动化，记录原因 |
| P2 可疑访问 | pairing 记录异常、陌生联系人触发、审批链绕过 | 暂停入口，导出日志，通知 owner |
| P1 高风险泄露 | token 外泄、生产账号被误用、越权操作已发生 | 立即止损、轮换凭据、保留证据、启动复盘 |
不要因为一个测试群误触发就把所有服务下线，也不要把 token 泄露当成普通告警。分级的目的，是让团队在压力下仍然能做正确动作。
前 15 分钟怎么处理
1. 暂停最可能造成继续损失的入口
优先暂停能继续触发动作的入口，而不是随手改一堆无关配置：
- 可疑 channel：先禁用 bot、移除 pairing 或暂时关闭 route。
- 可疑 webhook：先暂停接收端或轮换 webhook secret。
- Browser 登录态异常：先退出相关 session 或停用自动登录流程。
- 高风险 Skill / Plugin：先移出共享路径或禁用调用入口。
暂停动作要记录时间和执行人。不要在没有记录的情况下连续改配置，否则后面很难复盘。
2. 保留证据
事故现场最怕被自己清掉。建议先保存：
事故证据最小包：
- 事故开始时间与发现时间
- 触发 channel / gateway route / webhook
- 最近 30-60 分钟关键日志
- Control UI 中的会话、审批、执行记录
- 最近一次配置、Skill、Plugin、token 变更
- 已知影响范围和已执行动作如果日志里包含敏感信息，不要直接发到大群；先放到受控位置，再给必要人员访问。
3. 确认是否有凭据风险
出现 token 泄露、截图泄露、仓库提交、issue 贴出或聊天记录误发时，默认当作已暴露处理。删除消息只能减少后续传播，不能证明 token 没被复制。
三类常见事故处理流程
Pairing 异常
常见信号：
- 出现不认识的 pairing 记录。
- 群聊里陌生成员能触发 OpenClaw。
- 某个 channel 在没有审批的情况下开始执行动作。
处理顺序：
- 暂停该 channel 或限制触发条件。
- 导出 pairing、channel 和最近触发日志。
- 确认是误配置、成员变更、token 泄露还是授权绕过。
- 回收异常 pairing，重新设置 allowlist 或 mention 策略。
- 更新团队 playbook：谁能配对、谁能批准、多久复查一次。
不要只删除异常 pairing 就结束。必须解释它为什么出现。
Token 泄露
常见信号：
- token 被发进聊天、截图、日志、文档或仓库。
- 某个 channel 出现未知调用。
- webhook secret、API Key 或 session 被复制到不受控位置。
处理顺序：
- 立即轮换泄露 token 或 secret。
- 检查旧 token 在泄露后是否仍有调用记录。
- 找到泄露来源：截图、日志、CI、Markdown、聊天记录或本地配置。
- 清理公开残留，但不要把清理等同于修复。
- 修改流程：禁止在群里贴 token，截图前先打码，日志脱敏。
如果泄露的是生产凭据，恢复服务前应确认旧凭据已经失效。
越权访问或越权动作
常见信号：
- 低权限用户触发了高风险动作。
- Skill / Plugin 访问了不该访问的文件、网页或系统。
- Browser 登录态被用于错误账号或错误环境。
处理顺序：
- 暂停相关动作入口，不要立即清空所有记录。
- 确认影响范围：改了什么、发了什么、删了什么、谁看到了什么。
- 回滚可回滚动作，例如撤销配置、关闭工单、恢复文档版本。
- 收紧权限：审批边界、运行用户、Skill 权限、channel allowlist。
- 把事故写入复盘模板，明确防复发动作和责任人。
恢复服务前的检查
不要在“看起来没事了”时直接恢复。至少确认：
- 可疑入口已经暂停、修复或重建。
- 泄露或可疑 token 已轮换，旧 token 已失效。
- Control UI、gateway logs、channel logs 已保留关键证据。
- 受影响用户、客户或团队成员已经得到必要通知。
- 高风险 Skills / Plugins 已重新审查。
- playbook 已更新，避免同类事故重复发生。
复盘模板
OpenClaw 事故复盘
1. 事故摘要：
2. 发现时间 / 开始时间：
3. 影响入口：channel / gateway / browser / webhook / skill
4. 影响范围：
5. 第一止损动作：
6. 根因：
7. 修复动作：
8. 防复发动作：
9. owner：
10. 下次检查日期：复盘不是为了追责，而是为了让默认策略变得更稳。没有进入 playbook 的复盘，下一次大概率还会重演。
常见误区
一上来重装
重装可能破坏现场，也不一定回收 token、pairing 或外部授权。先止损和保留证据，再决定是否重建环境。
只处理技术入口，不通知业务方
如果事故影响了客户消息、内部审批、工单或账号行为，业务 owner 必须知道影响范围和恢复时间。
只轮换 token，不修流程
token 轮换只能解决当前泄露。导致泄露的截图、日志、仓库提交或群聊习惯不改，事故还会重复。
OpenClaw 团队落地手册
团队化和个人使用的差别
个人使用时，你可以接受临时配置、手动排错和口头记忆。团队使用时，这些都会变成风险：
| 个人使用 | 团队使用 |
|---|---|
| 自己知道 token 放在哪里 | 必须登记凭据用途、owner 和轮换方式 |
| 自己判断哪些动作能执行 | 必须定义高风险动作和审批人 |
| Skills 放在个人目录 | 需要共享库、版本说明和回滚路径 |
| 出问题自己重启 | 需要止损、排查、复盘和通知机制 |
| 渠道只服务自己 | 群聊、客户、同事都可能触发流程 |
因此团队落地的第一步不是“培训大家怎么安装”，而是先写出默认边界。
先定义 5 个角色
小团队不需要复杂组织架构，但至少要明确下面 5 个责任：
| 角色 | 主要职责 | 可以兼任吗 |
|---|---|---|
| Platform owner | 维护 OpenClaw 运行环境、Gateway、部署和升级 | 可以 |
| Security owner | 管入口策略、token、审批和事故响应 | 可以，但不要长期缺位 |
| Skill maintainer | 维护共享 Skills / Plugins，记录版本和变更 | 可以多人 |
| Channel owner | 负责 Telegram / WhatsApp / webhook 等入口策略 | 可以按渠道拆分 |
| Business approver | 判断真实业务动作能否执行 | 最好来自业务侧 |
角色不是为了增加流程，而是为了避免事故时没人知道“该找谁”。
团队 playbook 应该包含什么
1. 入口策略
把所有入口列成表，而不是藏在某个人的配置里：
入口策略模板：
- 入口名称：Telegram 客服群
- 触发方式：mention + 固定命令前缀
- 可触发人：客服组成员
- 高风险动作：外发客户回复、修改工单状态
- 审批人：当班主管
- 暂停方式：禁用 bot / 移除 pairing / 关闭 gateway route入口策略要比“安装教程”更靠前。否则每新增一个 channel，都会让权限边界更模糊。
2. 审批边界
审批边界建议分三档：
| 级别 | 示例 | 默认动作 |
|---|---|---|
| 低风险 | 总结公开文档、整理会议纪要、生成草稿 | 可自动执行，保留日志 |
| 中风险 | 修改内部文档、创建工单、给同事发送提醒 | 可执行，但需要可回滚 |
| 高风险 | 外发客户消息、登录账号、修改配置、删除资源 | 必须人工确认 |
不要把审批做成形式主义。真正有用的审批，是让高风险动作在执行前停住，并让审批人能看到上下文。
3. 共享 Skills 规则
团队共享 Skills 时，不要只看“能不能跑”。建议每个共享 Skill 都有一张维护卡：
Skill 维护卡：
- 名称：weekly-support-summary
- 场景：汇总本周客服渠道问题
- 输入：Telegram 群消息、工单导出
- 输出：Notion 草稿，不自动外发
- 权限：只读消息与工单导出
- owner：Support Ops
- 更新节奏：双周检查
- 回滚方式：保留上一版 Skill如果 Skill 会访问生产数据、客户信息、浏览器登录态或外部系统，必须先走审查，再进入共享库。
4. 凭据和环境分层
团队最容易犯的错误，是把“能跑通”的个人配置直接复制给别人。更稳的做法是分层：
- 个人实验环境：允许快速试错，但不能接生产 token。
- 团队测试环境：可以接测试 channel、测试 webhook、测试账号。
- 生产环境：只允许 owner 变更，凭据进入专门存储和轮换流程。
共享 Skills 不等于共享凭据。一个 Skill 可以被团队复用，但它使用的 token、session、API Key 仍应按环境和角色分开。
5. 复盘节奏
团队落地的早期，每周或每两周做一次轻量复盘：
- 哪些 channel 触发噪声最多。
- 哪些审批经常被拒绝，说明默认策略可能不清晰。
- 哪些 Skills 被频繁复制粘贴，值得沉淀成共享版本。
- 哪些日志缺失，导致问题发生后难以追踪。
- 哪些 token、session 或 webhook secret 需要轮换。
复盘结果要回到 playbook，而不是留在会议纪要里。
30 天 rollout 路线
第 1 周：只做边界和试点
- 选 1 个低风险团队场景，不要全公司铺开。
- 写入口策略、审批边界和临时停用方式。
- 只接测试 channel 或内部小群。
- 选出 platform owner、security owner 和 channel owner。
第 2 周：沉淀可复用流程
- 把重复 prompt 改成 Skill 或模板。
- 为每个 Skill 写维护卡和风险级别。
- 开始记录常见失败、误触发和审批拒绝原因。
第 3 周：接近真实业务
- 引入更接近生产的数据，但仍避免自动外发。
- 验证 Control UI、logs、审批记录是否足够支撑复盘。
- 明确高风险动作必须由谁确认。
第 4 周：准备长期运行
- 把凭据登记、轮换周期和事故预案补齐。
- 把稳定 Skills 放入共享库，不稳定的继续留在实验区。
- 决定是否扩大到更多 channel 或团队。
团队完成检查
- 每个入口都能说清触发人、触发条件、审批边界和暂停方式。
- 共享 Skills 有 owner、版本记录、权限说明和回滚方式。
- 生产 token 没有散落在群聊、截图、Markdown 或个人配置里。
- 高风险动作不会在无人确认的情况下直接执行。
- 每次事故或误触发都会回到 playbook 修订，而不是只在群里讨论。
什么时候不适合团队推广
如果你还处在下面状态，先不要扩大使用范围：
- 只有一个人知道怎么恢复服务。
- channel 和 gateway 配置没有文档。
- Skills 没有 owner，只靠“谁写的谁知道”。
- 生产 token 和测试 token 混用。
- 审批边界无法解释给非技术同事。
这些问题不解决，推广越快，后续清理成本越高。