OpenClaw Gateway 安全实战：聊天场景、代码场景与最严格限制配置

在 OpenClaw 的安全模型里，核心不是“模型够不够聪明”，而是“访问控制和执行边界是否先定义清楚”。这篇文章基于官方文档，整理最常见且最实用的安全措施，并重点回答三个上线高频问题：

聊天机器人场景，最低要加哪些限制？
代码处理场景，如何把破坏面降到可控？
面向公开或不可信输入时，最严格限制应该怎么配？

如果你刚开始搭建，可以先看专题页 OpenClaw 和 AI，再结合本文落地。

一、先统一一个原则：先做边界，再谈能力

官方文档反复强调一个运营事实：同一个 Gateway 实例内，认证后的操作方属于同一信任边界。也就是说，你不能把它当“强多租户隔离总线”来用。
安全上的正确姿势是：

明确谁能触发机器人（DM 策略、群策略、allowlist）。
明确机器人能调用什么（tools allow/deny、禁用控制面工具）。
明确机器人能接触哪里（sandbox、workspaceAccess、网络暴露、SSRF 策略）。

二、OpenClaw 常见四类安全措施（上线必做）

1) 入口控制：DM + 群聊双层收口

DM 默认建议 pairing，避免陌生人直接触发。
群聊建议全量 requireMention: true，防止“常驻自动响应”。
不建议长期使用 dmPolicy="open" 或 groupPolicy="open"。

2) 会话隔离：避免多人 DM 上下文串线

多人可发私信时，建议：

1
2
3

{
  "session": { "dmScope": "per-channel-peer" }
}

这能降低跨用户上下文泄露风险，但它是“消息上下文隔离”，不是“主机级权限隔离”。

3) 工具最小权限：高危工具默认禁用

至少要限制：

exec, process, browser, web_fetch, web_search
会改持久状态的控制面工具：gateway, cron

官方给了一个直接可用的思路：

{
  "tools": {
    "deny": ["gateway", "cron", "sessions_spawn", "sessions_send"]
  }
}

4) 沙箱与网络暴露：把“能执行”锁进容器

sandbox 是推荐项，不是默认强制项。
若 sandbox 关闭，exec 可能直接落在 gateway host 执行。
gateway.bind 优先 loopback，避免无认证暴露在 0.0.0.0。

三、聊天场景下的安全限制（推荐基线）

聊天型助手（尤其群聊）建议采用“收口 + 最小工具”：

{
  "gateway": {
    "mode": "local",
    "bind": "loopback",
    "auth": { "mode": "token", "token": "your-long-random-token" }
  },
  "channels": {
    "whatsapp": {
      "dmPolicy": "pairing",
      "groups": { "*": { "requireMention": true } }
    }
  },
  "session": { "dmScope": "per-channel-peer" },
  "tools": {
    "profile": "messaging",
    "deny": ["gateway", "cron", "exec", "browser", "web_fetch", "web_search"]
  }
}

同时关闭或仅在受控环境开启 /reasoning、/verbose，因为这类输出可能泄露工具参数、URL 或上下文信息。

四、代码场景下的限制（读多写少，先只读）

如果机器人需要读代码、做分析、给 patch 建议，建议从“只读模式”起步：

{
  "agents": {
    "list": [
      {
        "id": "code-review",
        "sandbox": {
          "mode": "all",
          "scope": "agent",
          "workspaceAccess": "ro"
        },
        "tools": {
          "allow": ["read"],
          "deny": ["write", "edit", "apply_patch", "exec", "process", "browser"]
        }
      }
    ]
  }
}

这个配置适合“先看后改”的团队流程：先让模型做风险识别和方案建议，再由人类执行变更。

五、最严格限制（公开/不可信输入场景）

当代理面向公开入口或频繁读取外部不可信内容（网页、附件、邮件、日志）时，建议叠加最严格策略：

workspaceAccess: "none"，禁用文件系统读写。
禁用 shell/执行链：exec, process, apply_patch 全关。
禁用控制面持久改动：gateway, cron 全关。
浏览器启用 SSRF 严格策略（默认不允许内网目标）：

{
  "browser": {
    "ssrfPolicy": {
      "dangerouslyAllowPrivateNetwork": false,
      "hostnameAllowlist": ["*.example.com", "example.com"],
      "allowedHostnames": ["localhost"]
    }
  }
}

对 URL 输入做 allowlist，减少“读到恶意指令后再调用工具”的注入链。

六、Prompt Injection：为什么聊天和代码都要防

Prompt Injection 不只来自陌生人私信，也可能来自任何外部内容载体（网页、附件、粘贴代码、日志片段）。
工程上不要把“系统提示词”当硬边界，真正有效的是：

通道收口（pairing/allowlist/mention gating）。
工具权限最小化（deny 高危工具）。
沙箱隔离 + 工作区访问限制（ro/none）。
密钥不进 prompt，敏感信息放到主机环境配置中管理。

七、发布前检查清单（60 秒）

上线前至少执行一次：

1	openclaw security audit

变更较多时补充：

1	openclaw security audit --deep

你也可以继续阅读标签页下的安全相关文章，把配置固化为团队基线。

参考来源

OpenClaw 官方文档（Security）：https://docs.openclaw.ai/gateway/security
OpenClaw 官方文档（Sandboxing）：https://docs.openclaw.ai/gateway/sandboxing