先用官方安全能力守住边界，再谈能力放大

OpenClaw 的安全入口覆盖安装、配置、分享和对外开放前的检查。官方能力可以降低风险，但不会代替人工阅读第三方代码、组织权限设计或实际环境验证。

四个官方安全入口

安全审计：openclaw security audit

审计配置与供应链风险，检查项包括 plugins.*、skills.* 等前缀。配置变更后运行基础审计；准备对外开放网络前再使用在线探测：

openclaw security audit
openclaw security audit --deep

--fix 会修改状态，不能当作第一条诊断命令；需要自动处理前先备份并阅读将要修复的范围。

本地安装门禁：security.installPolicy

在配置中指定本地策略命令，让每次安装继续前返回 allow、warn 或 block。它覆盖 ClawHub、上传、Git、本地、更新与依赖安装等来源；策略命令不能返回有效结果时按失败处理。

安装与更新过程不会自动替你判断本地危险代码，这道门禁需要由使用者配置和维护。

Skill 信任校验：openclaw skills verify

安装前向 ClawHub 校验信任封套并输出 Skill Card：

openclaw skills verify @owner/<slug>
openclaw skills verify @owner/<slug> --card

信任封套和 Skill Card 是证据，不是“绝对安全”结论。仍要核对发布者、文件、脚本、依赖、网络和权限。

ClawHub 注册表扫描

ClawHub 对已发布版本执行自动检查，详情可包含 VirusTotal、ClawScan 与静态分析结果；被封锁版本会从公共目录与安装入口下架。扫描通过不能代替阅读版本内容。

推荐安全流程

1. 安装前在 ClawHub 详情页查看扫描状态，并运行 skills verify --card。
2. 安装时用 security.installPolicy 对来源和内容做本地门禁。
3. 安装或配置变更后运行 openclaw security audit。
4. 对外开放前运行 openclaw security audit --deep 探测 Gateway。
5. 试点中限制范围、记录日志，并给外发、写入、删除和公开分享等动作保留人工确认。

2026.9.2 起：共享 Gateway 的跨 Agent 默认值变宽

9.2 是一次需要共享环境主动复核权限的版本；9.3 仍沿用这条行为基线。官方升级说明明确：当对应配置完全省略时，默认值是：

tools.sessions.visibility = all
tools.agentToAgent.enabled = true

这意味着，在其他策略允许的前提下，拥有 Session tools 的 Agent 可能列出、读取、搜索、发消息或检查其他 Agent 的 Session，其中也可能包含其他用户的 transcript。

这不是“所有人自动拥有管理员权限”，但它确实比 8.2 / 9.1 阶段常见的默认边界更宽。共享 Gateway 不应继续依赖默认值。

想保持保守边界：显式配置

例如希望 Session tools 只留在同 Agent，并关闭跨 Agent 调用：

{
  "tools": {
    "sessions": {
      "visibility": "agent"
    },
    "agentToAgent": {
      "enabled": false
    }
  }
}

如果要求当前 Session 严格隔离，用：

tools.sessions.visibility = self

如果只允许特定 Agent 互通，使用明确的 tools.agentToAgent.allow，不要靠默认全开。

agent 不是多租户隔离

visibility = agent 只是限制在同一个 Agent 下。如果多个人共享同一个 Agent，仍可能访问其他用户在这个 Agent 下的 Session。

因此真正互不信任的用户、客户或租户，不应该只依赖 Session visibility。官方建议这类隔离使用独立 Gateway，把进程、状态、凭据和网络边界一起拆开。

Personal model accounts 也需要真实用户身份

9.2 允许共享 Gateway 的登录用户连接个人 OpenAI、Anthropic、Grok/xAI 等模型账号；9.3 又增加单个账号健康状态、优先级与 targeted logout 控制。

这可以减少共享 provider credential，但只有共享密码或简单设备 pairing 时，仍不等于已经建立可靠的成员身份。模型账号隔离、Session visibility、agent-to-agent policy 和 Gateway 身份验证必须一起设计。

2026.9.3：可撤销聊天链接仍然是真正的公开分享

9.3 新增 public read-only conversation link。Session creator 或 Gateway admin 可以发布链接，让任何持有链接的人读取这个 conversation 的现有和后续新增文本，直到访问被撤销。

公开页面会排除 tools、reasoning、files、images 和 executable widgets，但这不意味着对话整体就是安全可公开的。

三个必须写清楚的边界

1. 只读不等于私密。 链接可以被复制和转发。
2. 撤销不能召回副本。 对方已经截图、复制或保存的内容无法被远程收回。
3. 未来文本也会继续公开。 分享的是持续 conversation，不只是发布按钮按下那一刻的静态快照。

因此在分享前，应先检查是否包含：

• 客户或员工信息；
• 内部代码、业务规则和未公开计划；
• token、cookie、URL 参数、路径或其他凭据线索；
• 模型输出中带出的私有上下文；
• 以后继续在同一 Session 中讨论时可能出现的敏感内容。

普通 private-session preview 与 public transcript sharing 是两条不同路径。前者仍要求正常认证，不要因为两个链接都能预览页面就把权限语义混在一起。

2026.9.3：Skill Workshop ownership 也要当安全边界检查

9.3 让每个 Agent 的 Skill Workshop 跨 workspace 持久化。Startup / Doctor 会迁移 ownership 能够明确判断的 legacy skills，模糊或冲突副本保留 review。

这解决了长期 Agent 在 workspace 之间搬动 Skill collection 的问题，但也意味着升级后要确认“能力最终属于谁”。

成熟多 workspace 环境至少检查：

• Skill 是否落在预期 Agent；
• Suggestions target 是否仍在允许的 Agent directory；
• review 的 instruction diff 是否完整；
• 旧 Skill 是否出现重复、冲突或意外扩大权限。

详细流程见Skill 安装与验证。

七类常见误区

权限过宽

不要一开始就给管理员账号、整网读写或全量业务数据。按动作最小授权：先只读、后写入，能用低权限账号就不用管理员；每次配置变化后重新审计。

外部内容污染

网页、邮件附件和 Issue 正文只能作为数据，不应自动变成可执行指令。把读取与执行拆开，对带链接、附件和高风险工具的任务保留人工确认。

第三方 Skill

官方明确建议把第三方 Skill 当作不受信代码。市场收录、精选列表和扫描通过都不是直接安装到真实工作区的理由。先核对来源与权限，再在隔离环境试用。

凭证泄露

不要把 token、密码、私钥写进提示词、日志或仓库。凭证放受控环境变量或专用存储，限制 Agent 可访问的文件范围；已经暴露的凭证立即轮换。

自动写操作

第一轮只做问答、摘要、分类或建议。对 CRM、工单、财务与审批系统的写入先从“生成草稿、人工提交”开始，再逐步放宽。

没有回滚

写操作前保留日志、输入输出、备份与撤回路径。9.3 的 update rehearsal / recovery 会降低失败升级的破坏面，但它不是业务状态备份。不能追踪、不能停用或不能撤回时，不应接入真实流程。

没有人工确认

对外发消息、流程提交、配置修改、删除和公开分享保留审核节点。确认成本低、影响小的动作可以先自动化，高影响动作放到最后。

四条试点原则

• 先辅助，再自动化： 先帮助人判断和整理，再逐步开放执行。
• 先单点，再联动： 先跑通一条闭环，再串联多个系统。
• 先可解释，再追求快： 能说明输入、工具和结果比速度更重要。
• 先治理，再放大： 权限、日志、责任和回滚没有准备好时不要扩大范围。

准备接入前继续完成安全检查清单；第三方扩展按Skill 安装核验指南逐项检查；9.3 更新边界看版本解读；已经出现异常时按故障排查中心的只读顺序定位。