这是「OpenClaw 教程课程」第 25 课。
从这一课开始，我们进入第六模块：安全与运维。前面我们已经让 OpenClaw 能跨设备、能看图、能听语音、能执行任务。现在要认真回答一个问题：它到底应该被允许做什么？

图：OpenClaw 的权限控制不是一个开关，而是 sandbox、tool policy、elevated、exec approvals 多层共同作用。

很多人刚用 OpenClaw，会先关心：

• 怎么让 Agent 执行命令？
• 怎么让它改文件？
• 怎么让它操作浏览器？
• 怎么让它调用手机摄像头？
• 怎么让它跑在节点机器上？

这些当然重要。

但真正长期使用时，更重要的问题是：

哪些事可以自动做，哪些事必须问我，哪些事永远不该让它做？

OpenClaw 不是只靠“信任模型”来保证安全。

它有几层控制：

1. Sandbox：工具在哪里运行
2. Tool policy：哪些工具能被调用
3. Elevated：sandboxed exec 能不能逃逸到真实主机
4. Exec approvals：真实主机命令怎么审批
5. Node command policy：节点能力能不能调用
6. Channel / sender allowlist：谁能发起敏感操作

这一课先聚焦最核心的三个词：

1

sandbox / tool policy / elevated

顺便把 exec approvals 一起讲清楚。

一、先说结论：这三者不是一回事

OpenClaw 官方文档里有一句很关键的区分：

1. Sandbox decides where tools run.
2. Tool policy decides which tools are available.
3. Elevated is an exec-only escape hatch.

翻译成新手容易懂的话：

• sandbox 管“工具运行在哪里”
• tool policy 管“工具能不能用”
• elevated 管“被关在 sandbox 里的 exec 能不能跑到真实主机上”

它们解决的问题不同。

如果混在一起，就会出现很多误解。

比如：

• “我开了 elevated，为什么还是不能用 browser？”
• “我关了 sandbox，为什么 exec 还是被拒？”
• “我把 /exec host=gateway 发过去，为什么 tool 还是 blocked？”
• “我以为 sandbox 保护了主机，结果 Docker bind 把敏感目录挂进去了？”

所以这一课先把边界讲清楚。

图：sandbox、tool policy、elevated 是三类不同控制：运行位置、工具可用性、exec 逃逸路径。

二、Sandbox：决定工具在哪里运行

Sandbox 的核心作用是：

限制工具执行时能碰到的文件、进程、网络和环境。

如果没有 sandbox，工具通常直接在真实主机上运行。

如果启用 sandbox，OpenClaw 可以把工具放进隔离环境里运行，比如 Docker sandbox、SSH sandbox、OpenShell sandbox。

文档里说，sandboxing 可以限制这些工具：

• exec
• read
• write
• edit
• apply_patch
• process
• 某些媒体读取
• 可选 sandboxed browser

注意：

Gateway 本身不在 sandbox 里。sandbox 主要限制的是工具执行。

Sandbox 的常见模式

配置项是：

1

agents.defaults.sandbox.mode

常见值：

新手最容易踩的是 non-main。

它不是按“是不是主 agent”判断，而是按 session.mainKey 判断。

很多群聊、频道、非主会话会被算作 non-main，于是进入 sandbox。

所以你会看到：

私聊里能执行，群里突然像被关进笼子。

这时不要猜，先查：

1

openclaw sandbox explain

三、用 sandbox explain 看真实状态

排查权限问题时，第一步不是改配置。

而是看 OpenClaw 当前到底怎么理解这个会话。

1
2
3
4

openclaw sandbox explain
openclaw sandbox explain --session agent:main:main
openclaw sandbox explain --agent work
openclaw sandbox explain --json

它会告诉你：

• 当前 sandbox mode
• 当前 session 是否 sandboxed
• workspace access 是 none / ro / rw
• sandbox tool allow / deny 来源
• elevated 是否可用
• 哪些配置 key 可以改

这比凭感觉改配置靠谱得多。

建议记住：

遇到 sandbox jail，先 sandbox explain。

四、Workspace access：sandbox 能不能读写你的工作区

Sandbox 不是只有“开”和“关”。

还要看 workspace access。

常见值：

如果你希望 Agent 在 sandbox 里改项目文件，需要 rw。

如果只想让它看，不想让它改，可以用 ro。

但要注意：

rw 不是没有风险，它意味着 sandbox 内工具可以改工作区。

所以对不熟悉的 agent，建议从 ro 或更小范围开始。

五、Docker binds：sandbox 也可能被你自己打穿

很多人以为：

开了 Docker sandbox 就一定安全。

不完全对。

如果你把宿主机敏感目录 bind mount 到 sandbox 里，它仍然能被看到。

文档里特别提醒：

• docker.binds 会刺穿 sandbox 文件系统边界
• 不写 :ro 时，默认可能是 read-write
• 绑定 /var/run/docker.sock 基本等于把宿主机控制权交给 sandbox

所以建议：

1
2
3

能 ro 就 ro
能不挂载敏感目录就不挂
不要随便挂 Docker socket

坏例子：

1
2
3
4
5
6
7
8
9
10
11

{
  agents: {
    defaults: {
      sandbox: {
        docker: {
          binds: ["/var/run/docker.sock:/var/run/docker.sock"]
        }
      }
    }
  }
}

这不是普通文件挂载。

这是高风险能力。

六、Tool policy：决定哪些工具存在

Sandbox 管“在哪运行”。

Tool policy 管“能不能调用这个工具”。

比如你可以通过 tool policy 控制：

• 是否允许 exec
• 是否允许 browser
• 是否允许 message
• 是否允许 image_generate
• 是否允许 sessions_spawn
• 是否允许 nodes

关键规则：

deny 永远优先。

还有一条：

如果 allow 非空，没写进 allow 的工具都算 blocked。

这很重要。

比如：

1
2
3
4
5

{
  tools: {
    allow: ["read", "write"]
  }
}

这意味着不只是 read/write 被允许。

还意味着：

1

exec、browser、message、nodes 等其他工具都不可用

如果再写：

1
2
3
4
5
6

{
  tools: {
    allow: ["read", "write", "exec"],
    deny: ["exec"]
  }
}

最终 exec 仍然被拒。

因为 deny wins。

图：tool policy 的核心规则是 deny 优先；如果 allow 非空，未列出的工具也会被阻止。

七、Tool profile 和 tool groups

OpenClaw 还支持工具组。

比如：

1
2
3
4
5
6
7
8
9

{
  tools: {
    sandbox: {
      tools: {
        allow: ["group:runtime", "group:fs", "group:web"]
      }
    }
  }
}

常见 group 包括：

工具组适合写配置，但新手要注意：

group 是批量授权，别以为它只开了一个工具。

如果你只需要 read，就不要为了省事开 group:fs。

八、Sandbox tool policy：只在 sandbox 时生效

OpenClaw 有普通 tool policy，也有 sandbox tool policy。

普通 tool policy：

1
2

tools.allow / tools.deny
agents.list[].tools.allow / deny

Sandbox tool policy：

1
2

tools.sandbox.tools.allow / deny
agents.list[].tools.sandbox.tools.*

区别是：

sandbox tool policy 只在当前会话 sandboxed 时生效。

比如你希望：

• host 直连会话可以用更多工具
• sandbox 会话只允许 read/write/web

就可以用 sandbox tool policy。

如果报错：

1

Tool X blocked by sandbox tool policy

你有三种思路：

1. 让该会话不进 sandbox
2. 在 sandbox tool policy 里允许这个工具
3. 换一个不需要该工具的工作流

不要第一反应就关掉全部安全控制。

九、Elevated：只影响 exec，不影响其他工具

Elevated 是最容易被误解的词。

它不是“超级管理员模式”。

它更准确的定义是：

当 agent 已经在 sandbox 里时，让 exec 命令逃逸到真实主机或 node 上执行。

文档里明确说：

• elevated 只影响 exec
• 不会给你额外工具
• 不会覆盖 tool allow / deny
• 不会让 host=auto 变成任意跨主机执行
• 如果当前已经不是 sandboxed，elevated 基本是 no-op

也就是说：

1
2
3

browser 被 tool policy 禁了，/elevated on 也没用
message 被 deny 了，/elevated full 也没用
exec 工具本身被 deny 了，elevated 也没用

一句话：

elevated 不是万能通行证，它只是 exec 的 sandbox escape hatch。

十、Elevated 的几个等级

常见命令：

1
2
3
4

/elevated on
/elevated ask
/elevated full
/elevated off

也可以简写：

1
2
3

/elev on
/elev full
/elev off

含义：

我建议新手记住：

能用 on，就不要用 full。

因为 full 跳过 approvals，风险明显更高。

十一、Elevated 还需要 allowlist

不是每个人都能发 /elevated full。

它需要配置允许。

示例：

1
2
3
4
5
6
7
8
9
10

{
  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        telegram: ["7995226813"]
      }
    }
  }
}

也可以按 agent 进一步限制。

也就是说，elevated 至少有两层 gate：

1. 全局 tools.elevated.enabled
2. sender 是否在 tools.elevated.allowFrom 里

如果 per-agent 也配置了 elevated allowlist，还要同时通过。

这很合理。

因为 elevated 本质上是让 sandbox 里的命令跑到真实主机。

十二、Exec approvals：真实主机命令的最后一道闸

如果 exec 最终跑在真实主机上，比如：

• gateway host
• node host

那就会进入 exec approvals 的世界。

Exec approvals 回答的是：

这条具体命令能不能在真实主机执行？

常见策略：

常见 ask：

检查：

1
2
3

openclaw approvals get
openclaw approvals get --gateway
openclaw approvals get --node <id|name|ip>

注意：

Exec approvals 是执行主机本地的策略。Gateway host 和 node host 各有自己的 approvals。

这也是为什么第 23 课讲 node exec 失败时，要查：

1

openclaw approvals get --node <idOrNameOrIp>

十三、exec host=auto、sandbox、gateway、node 怎么选？

exec 有一个重要参数：

1

host

常见值：

文档里有几个很重要的点：

• auto 不是万能通配
• 有 sandbox runtime 时，auto 会优先 sandbox
• sandboxed session 里，不允许随便从 auto 改成 gateway
• host=node 需要明确 node 目标
• host=auto 不会自己猜应该选哪个 node

所以如果你想在节点上执行命令，要明确设置：

1

/exec host=node security=allowlist node=<id-or-name>

如果你想看当前 exec 默认值：

1

/exec

图：exec host=auto 会根据是否有 sandbox 决定位置；gateway 和 node 是真实主机路径，会继续受 approvals 约束。

十四、/exec 和 /elevated 不一样

/exec 是设置 exec 默认参数。

比如：

1

/exec host=node security=allowlist ask=on-miss node=mac-1

它调整的是：

• host
• security
• ask
• node

但它不等于授权工具访问。

如果 tool policy 禁了 exec，/exec 也不能让它复活。

/elevated 则是控制 sandboxed exec 是否能离开 sandbox。

所以两者关系是：

1
2

/exec 管 exec 默认怎么跑
/elevated 管 sandboxed exec 能不能跑出 sandbox

不要混。

十五、YOLO / full 模式为什么危险？

文档里把 no-approval host exec 称为 YOLO mode。

大概组合是：

1
2
3

tools.exec.security = full
tools.exec.ask = off
host askFallback = full

效果是：

真实主机命令不再需要审批。

这很方便，也很危险。

危险点在于：

• Agent 可能误解你的意图
• prompt injection 可能诱导执行命令
• 一条错误命令可能删除文件
• node host 上可能操作到真实设备
• 你可能忘了当前会话已经 full

所以我建议：

1
2
3

个人测试环境可以短期开 full
长期运行环境不要默认 full
多节点环境更不要默认 full

更稳的策略是：

1
2
3

security=allowlist
ask=on-miss
askFallback=deny

十六、allowlist 应该怎么设计？

allowlist 不是越大越好。

建议从只读、安全命令开始。

比如：

1
2
3

openclaw approvals allowlist add --gateway "/usr/bin/uname"
openclaw approvals allowlist add --gateway "/usr/bin/uptime"
openclaw approvals allowlist add --gateway "/usr/bin/df"

Node 上：

1
2

openclaw approvals allowlist add --node <id|name|ip> "/usr/bin/uname"
openclaw approvals allowlist add --node <id|name|ip> "/usr/bin/sw_vers"

但不要轻易 allowlist：

• bash
• sh
• python3
• node
• ruby
• perl
• curl | sh
• rm
• 包管理器 install 命令

如果必须允许解释器，建议开启：

1

tools.exec.strictInlineEval = true

这样 python -c、node -e 这类 inline eval 仍然需要额外审批。

十七、safeBins 不是通用 allowlist

OpenClaw 里还有 safeBins。

新手不要把它理解成“安全命令白名单”。

文档提醒：

不要把 safeBins 当通用 allowlist，也不要把 python/node/bash 这类解释器放进去。

safeBins 更适合小型、stdin-only 的流处理工具。

如果你只是想允许某个明确命令，用 allowlist 更直观。

十八、一个推荐的新手权限模型

如果你刚开始搭 OpenClaw，我建议这样：

个人私聊主会话

• sandbox：可以 off 或 non-main
• exec：allowlist + on-miss
• elevated：默认 off，需要时 on
• full：只临时打开

群聊 / 公开入口

• sandbox：on
• tool policy：只开放 read/web/有限工具
• exec：deny 或 allowlist + always
• message：谨慎
• nodes：默认不开

多节点环境

• node exec：allowlist
• camera / screen：显式 command allow
• mobile media：手动触发
• autoApproveCidrs：默认不开

长期自动任务

• cron / heartbeat：只给必要工具
• 文件写入限制工作区
• exec 尽量固定脚本和路径
• 危险操作走 ask

一句话：

越是自动化、越是外部入口、越是多节点，权限就应该越紧。

图：不同场景适合不同权限组合：私聊主会话可以更灵活，群聊和自动任务应该更保守，多节点要特别控制 node exec 和媒体能力。

十九、常见问题：我开了 elevated，为什么工具还是 blocked？

因为 elevated 不改变 tool policy。

如果工具被 deny：

1

tools.deny: ["exec"]

或者 sandbox tool policy 禁了它：

1

tools.sandbox.tools.deny: ["exec"]

那 elevated 没用。

排查：

1

openclaw sandbox explain

看看到底是：

• tool policy blocked
• sandbox tool policy blocked
• elevated unavailable
• approvals denied
• host routing不符合预期

二十、常见问题：为什么我在群里不能执行命令？

可能是：

• 群聊 session 被 non-main sandboxed
• sandbox tool policy 不允许 exec
• exec 被 global deny
• /exec 不是 authorized sender
• elevated 没有 allowFrom
• approvals ask 需要 owner 批准

先看：

1

openclaw sandbox explain

再看：

1

openclaw approvals get --gateway

不要直接把 full 打开。

二十一、常见问题：为什么 node 上的 exec 被拒？

可能原因：

• node 没 paired
• node 不 connected
• system.run 没声明或没允许
• exec host 没设置 node
• node approvals 是 deny / allowlist miss
• 命令路径不在 allowlist

检查：

1
2
3

openclaw nodes status
openclaw nodes describe --node <idOrNameOrIp>
openclaw approvals get --node <idOrNameOrIp>

然后再考虑：

1

/exec host=node security=allowlist ask=on-miss node=<id-or-name>

二十二、常见问题：sandbox 里为什么看不到我的文件？

可能原因：

• workspaceAccess 是 none
• workspace 是只读 ro
• backend 是 SSH / OpenShell remote，远端没有同步最新文件
• Docker bind 没配置
• 路径不在有效 workdir boundary

先查：

1

openclaw sandbox explain

再决定是否改成：

1
2
3
4
5
6
7
8
9

{
  agents: {
    defaults: {
      sandbox: {
        workspaceAccess: "rw"
      }
    }
  }
}

但不要为了一个文件，直接把整个 home 目录挂进去。

图：遇到权限问题时，先用 sandbox explain 确认当前会话状态，再依次检查 tool policy、sandbox policy、elevated gate、exec approvals 和 node approvals。

二十三、适合新手的提问模板

1）检查当前权限模型

1

请帮我只读检查当前 OpenClaw 的 sandbox、tool policy、elevated、exec approvals 状态，先运行 sandbox explain 和 approvals get，不要修改配置。

2）解释为什么工具被 blocked

1

刚才工具被 blocked。请帮我判断是 tool policy、sandbox tool policy、sandbox runtime、elevated gate 还是 exec approvals 导致的。

3）设计安全 exec 策略

1

我想让 OpenClaw 可以执行少量只读诊断命令。请帮我设计 allowlist + on-miss 的 exec approvals 策略，不要建议 full。

4）临时使用 elevated

1

我需要临时让 sandboxed exec 在 Gateway 主机上运行。请说明 elevated on 和 elevated full 的区别，并建议更安全的方案。

5）多节点权限设计

1

我有一个 Mac node 和一个树莓派 node。请帮我设计 node exec 权限：只允许只读诊断命令，camera/screen 需要明确触发，不允许自动 full。

6）排查群聊执行失败

1

群聊里 OpenClaw 不能执行命令。请按 non-main sandbox、sandbox tool policy、sender authorization、elevated allowFrom、exec approvals 逐层排查。

二十四、这一课最值得记住的一句话

如果今天只记一句话：

Sandbox 管运行位置，tool policy 管工具可用性，elevated 只管 sandboxed exec 是否能跑到真实主机。

再记一句安全原则：

不要用 full 解决理解不了的问题；先查清是哪一层在拦。

二十五、总结

今天这节课，我们把 OpenClaw 的核心权限模型拆开了：

1. Sandbox 决定工具在哪里运行。
2. Tool policy 决定哪些工具可以被调用。
3. Sandbox tool policy 只在 sandboxed 会话中生效。
4. Deny 永远优先。
5. Allow 非空时，未列出的工具默认 blocked。
6. Elevated 只影响 exec，不影响其他工具。
7. Elevated full 会跳过 approvals，风险更高。
8. Exec approvals 决定真实主机命令如何审批。
9. Gateway host 和 node host 的 approvals 是各自主机本地策略。
10. host=auto 不是万能跨主机通配。
11. safeBins 不是通用 allowlist。
12. 多节点和自动化场景更应该坚持最小权限。

权限控制的目标不是把 OpenClaw 变得难用。

而是让它做到：

1
2
3
4

常见安全操作自动完成
危险操作明确确认
高风险能力默认关闭
出了问题能知道是哪一层拦住了

这才是一个长期可用的个人 AI 系统。

下一课预告

下一课我们会讲：

第 26 课：安全加固——SSH / 防火墙 / 自动更新

会重点讲：

• Gateway 主机的 SSH 基础安全
• 防火墙应该开放什么、不开放什么
• 为什么不要裸露 Gateway 端口
• Tailscale / SSH tunnel 下的安全边界
• 系统自动更新和 OpenClaw 更新策略
• 简单的安全巡检清单

🦞 本文由八条撰写，持续更新中。