OpenClaw 安全模型与部署加固指南

iX.
12 3月, 2026
,

Image

本文介绍 OpenClaw 的安全设计思路，以及如何通过三层控制策略对自托管部署进行加固。适合正在使用或评估 OpenClaw 的开发者参考。

为什么要认真对待 OpenClaw 的安全配置

OpenClaw 是一个 Agentic AI 框架，支持将 AI Agent 接入 Telegram、WhatsApp、Lark/飞书、Discord 等消息渠道，并赋予 agent 直接操作 shell、文件系统、浏览器的能力。它设计为 7×24 小时自主运行，这意味着：开放的工具越多，出了问题破坏性越大。

主要风险来源：

  • 提示词注入 — 消息或文件中的恶意内容引导 agent 执行非预期操作
  • 访问控制失误 — 错误的用户触达了有工具权限的 agent
  • 模型错误 — 模型在真实环境中做出错误判断

OpenClaw 的安全策略核心：从最小权限开始，按需逐步放开。

信任模型：先搞清楚边界

OpenClaw 设计为个人助手模式 — 一个 gateway = 一个信任边界。

几个关键点：

  • 如果多人可以给 bot 发消息，他们实际上共享同一套工具权限
  • 需要按用户隔离时，运行独立的 gateway（独立 OS 用户/主机）
  • sessionKey 是路由键，不是认证令牌

三层安全控制

第一层：谁能和 bot 说话（入站访问控制）

配置项推荐值说明
channels.telegram.dmPolicypairing每个用户需显式审批
channels.whatsapp.dmPolicyallowlist明确的手机号白名单
channels.discord.dmPolicyallowlist明确的用户 ID 白名单
channels.feishu.dmPolicypairing每个用户需显式审批
channels.*.groupPolicyallowlist 或 disabledallowlist 配合 groupAllowFrom 指定群 ID；不需要群聊时直接 disabled
session.dmScopeper-channel-peer按用户隔离会话

⚠️ 有工具权限的 agent 绝不能使用 dmPolicy: "open"。

第二层：bot 能做什么（工具策略）

三个子层按顺序生效：

① 工具 Profile（基础白名单）

Profile包含工具典型用途
minimal仅 session_status不受信任场景，安全默认值
messaging消息工具 + 部分 session 工具纯对话 bot、客服 bot
coding文件系统 + 运行时 + 会话 + 内存开发 / 工作 agent，需要操作文件和执行命令
full无限制完全信任的个人主用 agent

实际配置中，通常设置全局默认为 messaging，再对需要更高权限的特定 agent 单独提升（如工作 agent 设为 coding）。

② Allow / Deny（追加/覆盖）

{
  "tools": {
    "deny": ["group:automation", "group:runtime", "browser"]
  }
}

deny 永远优先于 allow，无法被覆盖。

③ Elevated exec（宿主机执行，慎用）

{
  "tools": {
    "elevated": { "enabled": false }
  }
}

Elevated exec 是逃逸到宿主机的后门，除非明确需要，否则禁用。如果启用，通过 allowFrom 限制到特定用户 ID。

第三层：工具在哪里运行（沙箱）

Docker 沙箱在模型出错时限制文件系统和进程访问范围：

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "non-main",
        "scope": "session",
        "workspaceAccess": "rw"
      }
    }
  }
}
Mode行为
off不沙箱化
non-main沙箱化群组/频道会话，主会话不沙箱化
all全部沙箱化

注意：沙箱需要 Docker。未安装 Docker 时，沙箱实际为 off，工具策略（deny 列表）是主要的爆炸半径控制手段。

典型部署安全状态参考

以下是一个典型个人自托管部署的安全状态评估示例：

项目示例配置风险评估
Gateway 绑定loopback✅ 未对外暴露
Gateway 认证token✅ 需要 token
Dashboard 访问仅 SSH tunnel✅ 未公开
Telegram dmPolicypairing✅ 显式审批
Telegram groupPolicydisabled✅ 不需要群聊时直接关闭
WhatsApp dmPolicyallowlist✅ 明确白名单
Discord dmPolicyallowlist✅ 仅指定用户 ID
Lark/飞书 dmPolicypairing✅ 显式审批
Lark/飞书 groupPolicyallowlist + groupAllowFrom✅ 仅允许指定群
tools.elevatedenabled: true，allowFrom: ["*"]⚠️ 任意已配对用户可执行宿主机命令，建议限制为特定用户 ID
exec（全局）security: full, ask: off⚠️ agent 可执行任意命令且无需审批；因 MCP 调用链依赖 exec，通常需要放开，但应配合严格的入站控制
沙箱关闭（无 Docker）⚠️ 工具直接在宿主机运行，用 deny 列表控制爆炸半径
session.dmScopeper-channel-peer✅ 按用户隔离会话

加固基线配置

从这个基线开始，按需为每个 agent 逐步开放工具权限：

{
  "gateway": {
    "bind": "loopback",
    "auth": { "mode": "token", "token": "<长随机 token>" }
  },
  "session": { "dmScope": "per-channel-peer" },
  "tools": {
    "profile": "messaging",
    "deny": ["group:automation", "group:runtime", "group:fs", "sessions_spawn"],
    "exec": { "security": "deny", "ask": "always" },
    "elevated": { "enabled": false }
  },
  "channels": {
    "telegram": { "dmPolicy": "pairing", "groupPolicy": "disabled" },
    "discord": { "dmPolicy": "allowlist" },
    "feishu": { "dmPolicy": "pairing", "groupPolicy": "allowlist" },
    "whatsapp": { "dmPolicy": "allowlist" }
  }
}

主要风险点与缓解措施

exec 权限与 MCP 工具的依赖关系

OpenClaw 调用 MCP 工具的链路是：

agent → exec(mcporter call ...) → MCP Server → 外部服务

这意味着 MCP 工具调用依赖 exec 权限。如果 agent 需要使用 MCP 工具（如 Blogger、Linear、Notion 等），exec 通常需要设置为 security: full。这是一个重要的权衡点：放开 exec 才能用 MCP，但 exec 一旦放开，agent 就可以执行任意 shell 命令。

补偿措施：

  • 通过严格的入站访问控制（dmPolicy/allowlist）限制谁能触发 agent 行为
  • 在 AGENTS.md / SOUL.md 中明确 agent 的行为约束
  • 群聊保持 requireMention: true，减少提示词注入面

identityLinks 跨渠道 session 串联

identityLinks 会将不同渠道的同一用户合并到同一个 session。如果多个渠道的 binding 指向不同 agent，可能导致消息被路由到非预期的 agent，或共享了本不该共享的上下文。

缓解措施：

  • 谨慎配置 identityLinks，只合并确实需要共享 session 的渠道
  • 权限差异较大的渠道（如对外的客服渠道 vs 个人主渠道）不要加入同一个 identityLinks 组

群聊提示词注入

群消息中的未知成员内容可能注入指令。缓解措施：

  • 保持 groupPolicy: allowlist 并填写明确的群 ID；不需要群聊时直接设为 disabled
  • 对群回复启用 requireMention: true
  • 对群可访问的 agent 禁用 group:runtime 和 group:fs

Elevated exec 权限过宽

如果配置了 allowFrom: ["*"]，任意已配对用户均可触发宿主机 exec。有多个已配对用户时，务必限制为特定用户 ID：

{
  "tools": {
    "elevated": {
      "enabled": true,
      "allowFrom": { "telegram": ["<your_user_id>"] }
    }
  }
}

无沙箱时的补偿措施

没有 Docker 时，所有工具执行直接在 gateway 宿主机上运行。可通过以下方式限制影响范围：

{ "tools": { "fs": { "workspaceOnly": true } } }

进阶方案：Docker 沙箱 vs Firecracker microVM

对于需要更强隔离的场景，有两个进阶路线：

Docker 沙箱

OpenClaw 内置 Docker 沙箱支持，在容器层面限制文件系统和进程访问范围。无 VM 开销，适合 agent 不需要运行时安装工具的场景。

openclaw-firecracker：VM 级别多租户隔离

openclaw-firecracker 是基于 AWS Firecracker microVM 的 OpenClaw 多租户隔离部署方案。每个租户（即每个 OpenClaw 实例）运行在独立的 microVM 中，拥有独立内核、系统盘、数据盘和网络，租户间完全隔离、互不可见。

核心功能：

  • 租户管理 — 通过 API 创建/删除/查询租户，每个租户是一个独立 Firecracker microVM
  • 安全隔离 — 独立内核 + 独立网络，每个租户 /24 子网，互不可见
  • 自动调度 — 创建租户时自动选择有空闲资源的宿主机，资源不足时自动扩容
  • 自动缩容 — 空闲宿主机超时后自动回收，节省成本
  • 健康检查 — 每分钟探活所有 VM，连续失败自动重启

部署架构（简化）：

用户/管理员
    │
    ▼
API Gateway (HTTPS, x-api-key)
    │
    ▼
Lambda + DynamoDB ──→ SSM Run Command ──→ EC2 Host
                                           ├── microVM 01 (独立内核/网络)
                                           ├── microVM 02
                                           └── ...
ASG 自动扩缩宿主机，EventBridge 健康检查 + 空闲回收

三种方案对比

安全层无沙箱（直接在宿主机）Docker 沙箱Firecracker microVM
工具执行隔离无容器（共享内核）每个 VM 独立内核
爆炸半径整个 EC2 实例容器文件系统单个 microVM
凭证泄露范围整个宿主机宿主机挂载路径仅该 VM 内
失控 agent 恢复手动介入重启容器API 一键 reset
部署复杂度无需要 Docker需要 c8i/m8i/r8i EC2 + CDK

选型建议：

  • 单用户个人部署：工具 deny 列表 + dmPolicy 控制即可
  • 多人共用 / 接触不可信内容：启用 Docker 沙箱
  • 多用户 / 高安全要求 / SaaS 场景：openclaw-firecracker，VM 级别完整隔离

Firecracker 前置条件：需要支持嵌套虚拟化的 EC2 实例（c8i/m8i/r8i 系列）。

安全审计

配置变更后定期运行：

openclaw security audit
openclaw security audit --fix   # 自动修复安全问题

参考链接

Previous Post
No Comment
Add Comment
comment url