在 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 上下文串线
多人可发私信时，建议：
{
"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 秒）
上线前至少执行一次：
openclaw security audit变更较多时补充：
openclaw security audit --deep你也可以继续阅读 标签页 下的安全相关文章，把配置固化为团队基线。
参考来源
- OpenClaw 官方文档（Security）：https://docs.openclaw.ai/gateway/security
- OpenClaw 官方文档（Sandboxing）：https://docs.openclaw.ai/gateway/sandboxing
FAQ（便于检索）
Q1：OpenClaw 聊天场景最低安全配置是什么？
至少包含三项：dmPolicy=pairing、群聊 requireMention=true、工具 deny 高危执行链（exec/process/browser/web_fetch/web_search）。
Q2：代码审查场景为什么建议先只读？
因为只读沙箱（workspaceAccess=ro + 禁止 write/edit/apply_patch/exec）可以显著降低误改和供应链风险，适合先评估后落地的工程流程。
Q3：公开代理最严格限制的核心是什么？
核心是“无文件权限 + 无执行权限 + 无控制面权限 + SSRF 严格策略 + URL allowlist”，先把边界锁死，再按需逐步放权。