OpenClaw 安全实战指南：构建个人 AI 助手的信任边界

核心前提：OpenClaw 是个人助手网关，而非多租户安全边界。 警告：如果你的 AI 助手被互不信任的多方使用，他们共享的是同一套权限。若需隔离对抗性用户，请部署独立的网关实例（建议独立 OS 用户或主机）。

随着 AI Agent 能力的爆发，我们将文件读写、命令执行、浏览器控制等高危权限交给了模型。当你的助手被恶意诱导时，后果是什么？本文基于 OpenClaw 的安全模型，为你提供从架构设计到应急响应的全方位防护指南。

1. 核心安全模型：重新定义信任

OpenClaw 的设计哲学建立在单用户信任边界之上。理解这一点是安全部署的基石。

image

2. 60 秒加固基线 (Copy & Paste)

不要从零开始配置。使用以下“最小权限”基线，然后根据需求按需开启特定工具。

{
  gateway: {
    mode: "local",
    bind: "loopback", // 仅本地访问
    auth: { 
      mode: "token", 
      token: "替换为强随机令牌" 
    },
  },
  session: {
    dmScope: "per-channel-peer", // 私信会话隔离
  },
  tools: {
    profile: "messaging",
    // 默认禁用高危组
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },  // 文件操作仅限工作区
    exec: { security: "deny", ask: "always" }, // 执行命令默认拒绝且需确认
    elevated: { enabled: false },  // 禁用提权模式
  },
  channels: {
    whatsapp: { 
      dmPolicy: "pairing",  // 陌生私信需配对
      groups: { "*": { requireMention: true } }  // 📢 群聊必须 @提及
    },
  },
}　　

3. 防御纵深：关键风险控制

私信访问控制 (DM Policy)

防止陌生人通过私信进行提示注入攻击。

• pairing (推荐) ：未知用户发送消息会收到配对码，管理员批准前 Bot 无视其内容。
• allowlist：仅允许白名单用户，其他人直接拦截。
• open ：允许任何人访问（需显式配置 *），高风险，仅限完全受信的公共 Bot。
• disabled：彻底关闭私信。

最佳实践：对于多用户场景，务必设置 session.dmScope: "per-channel-peer"，防止不同用户的上下文泄露。

提示注入 (Prompt Injection)

现状：提示注入目前无法通过系统提示完全解决。 对策：依靠硬性限制而非软性指导。

1. 输入过滤：默认视链接、附件、长文本指令为潜在恶意内容。
2. 沙箱运行：所有敏感工具（Exec, Browser）必须在沙箱中运行。
3. 模型选择：使用最新的强模型（如 GPT-4o, Claude 3.5+），旧模型极易被绕过。
4. 最小权限：不要给处理公共输入的 Agent 赋予 exec 或 fs_write 权限。

沙箱化策略 (Sandboxing)

OpenClaw 提供两层沙箱，强烈建议启用：

1. 容器级：在 Docker 中运行整个网关。
2. 工具级：宿主机网关 + Docker 隔离的工具进程。

工作区访问控制配置：

agents: {
  defaults: {
    sandbox: {
      scope: "agent", // 默认：按 Agent 隔离
      workspaceAccess: "none" // 默认：Agent 无法访问自身工作区外的文件
      // 可选："ro" (只读), "rw" (读写，仅限受信 Agent)
    }
  }
}　　

浏览器控制风险

风险等级：极高。浏览器配置文件包含登录态、Cookie 和密码。

• 专用配置：为 Agent 创建独立的 Chrome/Firefox 配置文件（无个人数据）。
• 禁用同步：在 Agent 配置文件中关闭密码管理器和账号同步。
• 下载隔离：指定独立的下载目录，并定期清理。
• 禁止共用：绝不要让 Agent 使用你日常浏览的个人配置文件。

4. 运维与审计

自动化审计

定期运行内置审计工具，特别是在修改配置或开放网络端口后：

# 基础检查
openclaw security audit

# 深度检查（推荐）
openclaw security audit --deep

# 尝试自动修复常见问题
openclaw security audit --fix

凭证与文件权限

确保配置文件不被其他用户读取：

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.openclaw/secrets.json

关键凭证路径备忘：

• WhatsApp: ~/.openclaw/credentials/whatsapp/<id>/creds.json
• Telegram: channels.telegram.tokenFile
• 模型密钥: ~/.openclaw/agents/<id>/auth-profiles.json

网络暴露原则

• 默认：bind: "loopback" (仅本机)。
• 远程访问：优先使用 Tailscale Serve 或 Cloudflare Tunnel，避免直接绑定 LAN IP 或 0.0.0.0。
• 防火墙：如果必须暴露端口，务必配合严格的 IP 白名单。

5. 事件响应计划 (IRP)

假设最坏的情况发生：AI 被攻破并开始执行恶意操作。

第一阶段：遏制 (Containment)

1. 切断进程：立即终止 openclaw gateway 进程或关闭管理应用。
2. 网络隔离：修改配置为 bind: "loopback"，断开 Tailscale/Funnel 连接。
3. 冻结入口：将 dmPolicy 设为 disabled，移除所有 allowlist 中的 *。

第二阶段：轮换 (Rotation)

假设所有密钥已泄露：

1. 网关认证：更换 gateway.auth.token 并重启。
2. 远程客户端：轮换所有连接该网关的客户端密钥。
3. 第三方凭证：重置 WhatsApp 会话、Telegram Token、LLM API Key 等。

第三阶段：审计 (Audit)

1. 检查日志：/tmp/openclaw/openclaw-*.log。
2. 审查会话：~/.openclaw/agents/*/sessions/*.jsonl。
3. 复盘配置变更历史。

结语：安全是一种权衡

OpenClaw 将强大的模型连接到了真实世界。没有绝对安全的配置，只有深思熟虑的权衡。

请始终遵循 “身份优先 > 范围控制 > 模型信任” 的原则：

1. 谁能和你对话？（严格配对/白名单）
2. 它能做什么？（最小权限/沙箱）
3. 它想做什么？（假设模型可能被操纵）

从最小权限开始，随着信任的建立逐步放开。定期审计，保持警惕。

记住：你的安全边界，取决于你最薄弱的那个配置项。