前言

OpenClaw 的核心价值不在“聊天”，而在“执行”。它是一个本地优先的 Gateway/Agent 平台：你在自己的机器或服务器上运行一个 Gateway，把消息渠道、会话、工具和事件连接起来，让 AI 助手真正去做事。官方文档明确把它描述为“你自己机器上的单一 Gateway 进程”，用于连接 WhatsApp、Telegram、Discord、Slack 等消息入口，并作为长期在线的个人 AI 助手控制面。

也正因为它能执行真实操作，OpenClaw 的安全问题不能按“普通聊天机器人”去理解。官方安全文档强调，它采用的是个人助手信任模型：一个 Gateway 对应一个信任边界，适合单用户或同一信任边界内的协作，不适合作为多方敌对用户共享的“安全隔离总线”。

如果你的目标是“先安全试用，再逐步放权”，这篇文章建议你从四件事入手：

• 最小权限
• skills 白名单
• 隔离运行
• 有节奏的升级与审计

一、先理解 OpenClaw 的安全边界

在讨论配置之前，先把一个前提讲清楚：OpenClaw 不是为敌对多租户场景设计的。

官方安全文档明确写到，推荐的部署方式是“一条信任边界对应一个 Gateway”，更理想的做法是“一个 OS 用户 / 一台主机 / 一个 VPS 对应一个 Gateway”。如果多个互不信任的人共用同一个 tool-enabled agent，那么他们本质上共享的是同一组被委托的工具权限。

这意味着两件事：

• 第一，不要把一个 OpenClaw Gateway 当成多人隔离平台。
• 第二，所有安全措施都应该围绕“收窄权限”而不是“幻想完全隔离”来设计。

官方还提供了内置审计命令 openclaw security audit，用于检查常见配置风险，例如 Gateway 认证暴露、浏览器控制暴露、过宽的 allowlist，以及文件系统权限设置。文档同时强调：不存在“完美安全”的部署，目标是有意识地控制谁能和 bot 对话、bot 能在哪里行动、bot 能接触什么。

二、最小权限：先把能力关小，再逐步放开

2.1 用专用环境和专用工作目录起步

安全试用 OpenClaw 的第一原则，不是“先装起来”，而是“先圈定边界”。

建议的起步方式是：

• 使用专用 OS 账号
• 为 OpenClaw 准备单独的工作目录
• 不与个人浏览器配置、密码管理器、云凭证目录混用

OpenClaw 的配置文档给出的最小配置示例里，agents.defaults.workspace 就是核心字段之一，用来定义默认工作目录。
而官方安全文档在“公司共享 agent”的建议里也明确指出：应运行在专用机器 / VM / 容器中，并使用专用 OS 用户 + 专用浏览器 profile / 账号，不要把个人 Apple/Google 账号或个人浏览器资料混到同一运行时里。

更直白地说：
不要让试用版 OpenClaw 直接碰你的主力开发机身份。

2.2 只开放 workspace，不开放全盘

从文件系统角度看，最小权限最重要的一步就是：只允许 agent 接触它完成任务所需的工作区。

配置上，OpenClaw 支持为 agent 设定默认 workspace。
实践上，你应当把这个 workspace 当成唯一“可活动区域”，避免让 agent 接触以下目录：

• ~/.ssh

• ~/.aws

• 浏览器 profile

• 各类密钥、token、证书目录

• 个人文档、下载目录、桌面等高敏感区域

这里的思路不是“防所有攻击”，而是降低两类常见后果：

• agent 被提示注入或误操作后读取不该读的文件
• 恶意 skill 或漏洞链条导致敏感信息被外带

2.3 高危工具默认关闭，确需时再改成“逐次确认”

OpenClaw 的风险并不主要来自“文本输出”，而是来自“可操作宿主机”。因此，命令执行、浏览器自动化、广域文件读写、对外网络访问，都应视为高危能力。

官方文档在审计建议中提到，openclaw security audit 会专门标记诸如浏览器控制暴露、文件系统权限、过宽 allowlist 这类风险点。
更重要的是，OpenClaw 的安全模型并不把“已认证的控制面访问者”当成敌对租户；一旦配置允许某类工具调用，它就是在该信任边界内真实生效。

因此，试用阶段推荐采用这样的放权顺序：

1. 默认关闭高危工具
2. 必须使用时，先改成逐次确认
3. 再进一步，收敛成allowlist 模式

如果你是为了做 AI Coding 试用，那么很常见的收敛方式就是：
只允许执行少量验收命令，例如 pytest -q、ruff check .、mypy .。
不要一开始就把任意 shell 打开。

三、skills 白名单：把供应链风险当作“一等公民”处理

3.1 为什么 skills 必须白名单化

OpenClaw 的一个重要卖点是 skills 生态，但也是它当前最明显的风险面之一。

近一个月里，公开报道显示 ClawHub 上发现了数百个恶意 skills；这些技能会伪装成生产力工具或加密相关工具，引导用户执行命令，最终窃取 SSH 登录、API 凭证、浏览器密码、钱包密钥等敏感数据。

这类风险的危险之处在于：
skills 往往不需要复杂 exploit，就可以利用“人愿意相信自动化工具”的心理完成攻击。

官方 GitHub 安全策略也说得很直接：一旦你安装或启用某个插件，它就被视为与宿主机上的本地代码同等信任；插件在这个信任边界内读文件、读环境变量、执行主机命令，本身并不被视为漏洞，而是预期行为。

这句话的含义非常重要：

skill 一旦装上，不是“提示词”，而是“你已授权运行的代码能力”。

3.2 白名单的正确打开方式

试用阶段，最安全的顺序是：

第一阶段：不用第三方 skills

先只用 OpenClaw 自带能力，或者只用你能完整审计的本地自写 skills。
这会牺牲一些便捷性，但能最大幅度降低供应链风险。

第二阶段：只引入可审计来源

如果必须用第三方 skill，至少满足下面条件：

• 来源明确
• 能看到完整内容
• 无混淆安装命令
• 无模糊权限声明
• 无“先执行这串命令再说”的社工式步骤

第三阶段：建立固定白名单

把真正验证过、重复使用的 skills 固化成一个极小白名单，而不是“需要什么就现装什么”。

对 OpenClaw 这类平台来说，白名单不是附加项，而是默认策略。

3.3 判断一个 skill 是否高危的实用标准

下面这些信号，出现任意一条都应该高度警惕：

• 要求你执行长串 shell 命令，尤其是下载并直接执行的命令
• 明示或暗示访问钱包、浏览器配置、SSH、云凭证等目录
• 要求下载“补丁”“证书”“安装器”
• 来源不清晰，仓库历史、作者、更新时间都异常
• 解释功能时含糊其辞，但权限要求很大

而以下信号会相对加分：

• 明确声明会访问哪些路径、调用哪些能力
• 提供源码和可审计逻辑
• 权限需求与功能目标相匹配
• 支持最小权限运行

四、隔离：不要在主力环境里“裸跑”

4.1 OpenClaw 适合跑在独立信任边界中

OpenClaw 官方安全文档多次强调：如果你需要把不同信任边界隔开，应使用不同 Gateway、不同凭证，最好不同 OS 用户或不同主机。

因此，从安全试用角度看，比较稳妥的隔离强度排序是：

1. 独立 VPS / 独立主机
2. 本地虚拟机
3. 容器 + 专用用户
4. 仅专用 OS 账号 + 专用 workspace

哪怕你暂时做不到完整隔离，也至少不要把它和你的主力个人环境混在一起。

4.2 为什么“边试用边随便上网”是坏习惯

Oasis Security 在 2026 年 2 月披露的 ClawJacked 漏洞链说明：任意网站都可能通过 localhost WebSocket 路径静默接管 OpenClaw，不需要插件、扩展，甚至不需要用户交互。研究方称 OpenClaw 团队已在 24 小时内发布修复，并建议升级到 2026.2.25 或更高版本。

这件事带来的实际启示是：

• 试用环境不要和日常浏览环境混用
• 不要在 agent 长期开启的同一环境里随意访问不明网页
• 即使已经升级，隔离仍然是必要的，因为漏洞链只会不断变化，不会永久消失

五、升级与审计：把“及时修补”变成固定动作

5.1 版本管理不是可选项

OpenClaw 官方仓库明确区分了 stable、beta 和 dev 三个更新通道，并支持通过 openclaw update --channel stable|beta|dev 切换。stable 对应正式 tagged releases，beta 对应预发布，dev 则更接近主分支前沿。

对于安全试用而言，建议遵循以下原则：

• 默认只用 stable
• 不要为了追新功能长期跑 beta / dev
• 发生高危漏洞披露时，优先确认 stable 是否已有修复，再升级

5.2 每次升级后都做两件事

第一件事：跑内置审计。

官方建议在改配置或暴露新的网络面之后，定期运行：

openclaw security audit
openclaw security audit --deep

这个命令会检查 Gateway 认证暴露、浏览器控制、过宽 allowlist、文件系统权限等问题。

第二件事：跑你自己的验收门禁。

如果你用 OpenClaw 做 AI Coding 或自动化试用，升级后最好把最常用的验收命令重新跑一遍，例如：

pytest -q
ruff check .
mypy .

这样做的目的不是验证 OpenClaw 本身，而是验证你的运行链条和工作流约束仍然有效。

六、通信入口也要收紧：不要让任何人都能给 bot 发指令

OpenClaw 连接的是现实消息渠道，因此入口控制非常关键。

官方仓库说明，默认情况下，Telegram、WhatsApp、Signal、iMessage、Slack、Discord 等渠道使用的是 DM pairing 模式：未知发送者先收到一个短配对码，Bot 不会直接处理其消息；只有执行 openclaw pairing approve … 后，发送者才会进入本地 allowlist。公开 DM 必须显式设置 dmPolicy=“open” 且在 allowFrom 中加入 “*”。官方还建议用 openclaw doctor 检查高风险 DM 策略。

这意味着最安全的入口策略是：

• 保持默认 pairing 模式
• 明确维护 allowFrom
• 除非你真的理解后果，否则不要把 DM 改成 open

如果你在团队里共享一个 agent，官方也强调：共享 agent 只适用于同一信任边界内的协作场景，并应运行在专用机器 / VM / 容器上。

七、一套可以落地的“安全试用基线”

如果你只想记住一套最小可行方案，可以直接照这个基线执行：

环境

• 使用专用机器、VM 或至少专用 OS 账号
• 建立单独 workspace
• 不挂载个人敏感目录

权限

• 默认关闭高危工具

• 命令执行先用逐次确认，再逐步收敛为 allowlist

• 只允许 agent 访问 workspace

skills

• 先不用第三方 skills
• 确需使用时，只引入可审计、来源清晰、权限声明明确的 skills
• 固化白名单，不做“现用现装”

通信

• 保持默认 DM pairing
• 明确 allowFrom
• 不轻易改成 open

维护

• 只跑 stable 通道
• 关注高危安全公告
• 升级后运行 openclaw security audit
• 对自己的关键工作流重新跑一遍验收命令

结语

安全试用 OpenClaw 的核心，不是追求“绝对安全”，而是把它放在一个你能理解、能收敛、能快速丢弃和重建的边界里。官方安全文档已经把前提讲得很清楚：它适合个人助手模型，不适合敌对多租户；一旦你安装了插件，它就属于与你本地代码同等级别的信任；如果你让不受控的人接触同一个 tool-enabled agent，他们共享的其实是同一组委托权限。

结合近一个月披露的 skills 供应链问题和 ClawJacked 漏洞链，比较稳妥的态度应该是：

先缩权限，再谈体验；先做隔离，再谈自动化；先能审计，再谈扩展。