安全第一：权限边界、技能检查与成本控制

💡 读完本章，你就能给 Agent 上一把”智能锁”——既不让它变成脱缰野马，也不把它捆成粽子。

很多新手会把”安全”理解成”把 Key 藏好就行”。在 OpenClaw 里这远远不够。真正要防的是：谁能下指令、它能做什么、做错了最多会错到哪。

简单说：安全不是一次性的”装好就完事”，而是要给 Agent 画好三条线——谁可以叫它、它能干什么、它在哪干活。

本章你将学会什么

用最小权限思路给 Agent 设边界，而不是”先全开再补洞”。
把 API Key、OAuth 凭证、会话数据分开管理。
建立技能与插件的供应链检查流程。
用 exec approvals + 沙箱 + allowlist 管住高风险动作。
给模型调用和工具执行设置成本上限，避免”跑飞”。

读者前置

你已经能运行 openclaw onboard 并完成基础对话。
你知道配置文件路径：~/.openclaw/openclaw.json。
你愿意接受一个工程现实：默认”严格”，比默认”宽松”更省事故成本。

4.1 为什么 Agent 更需要最小权限

4.1.1 Agent 的风险不是”会聊天”，而是”会执行”

传统的聊天机器人（比如你跟 Siri 聊聊天）大多数情况下只输出文本——它说错了话，你最多翻个白眼。

但 OpenClaw 这类 Agent 不一样。它会直接调用工具：读写文件、执行系统命令、访问网络、操作各种渠道。

这就意味着风险从”说错话”升级成”做错事”。

举个例子：

普通聊天机器人说”我帮你删了文件”，其实它只是说说
Agent 说”我帮你删了文件”，它可能真的去执行了 rm -rf /

所以安全思路必须从”它会说什么”变成”它会做什么”。

4.1.2 三层边界：入口、工具、执行环境

建议把权限分三层来看，每一层都相当于一道门：

第一层：入口边界——谁能给它发指令？ 通过这些配置控制：

dmPolicy：谁可以私聊 Agent
allowFrom：允许哪些来源
groupPolicy：谁可以在群聊里调用它

第二层：工具边界——它能调用哪些能力？

tools.profile：Agent 擅长什么（coding、general 等）
tools.allow/deny：明确允许或禁止哪些工具

第三层：执行边界——调用后在哪跑？

host 模式：直接在服务器上执行
sandbox 模式：在隔离环境里跑
是否需要审批才能执行

⚠️ 只做其中一层远远不够！

举个例子：你只做了 DM allowlist（入口管住了），但放开了 group:runtime（工具没管），那攻击者可能通过群聊诱导 Agent 执行危险命令。

4.1.3 一份可直接抄的最小安全基线

下面这份配置可以直接复制到你的 ~/.openclaw/openclaw.json 里：

{
  channels: {
    whatsapp: {
      // 私聊需要配对确认
      dmPolicy: "pairing",
      // 群聊只允许白名单里的人
      groupPolicy: "allowlist",
    },
  },
  tools: {
    // Agent 技能配置为 coding 模式
    profile: "coding",
    // 禁止执行任何 runtime 相关命令
    deny: ["group:runtime"],
  },
  agents: {
    defaults: {
      sandbox: {
        // 所有工具都走沙箱
        mode: "all",
        // 隔离范围是 agent 级别
        scope: "agent",
        // 不允许访问主机文件系统
        workspaceAccess: "none",
      },
    },
  },
}

这份配置的核心目标不是”最省事”，而是**“先保证出错时损失可控”**。

就像开车先系安全带——不是盼着出事，而是出事时能保命。

4.2 Key 与凭证管理

4.2.1 三类敏感资产要分开

请把下面三类分开管理，它们不是一回事：

类型	包含内容	存放位置
模型 Key	ZAI_API_KEY、MOONSHOT_API_KEY 等	环境变量或配置文件的密钥字段
OAuth 凭证	第三方平台授权信息	`~/.openclaw/credentials/` 目录
会话与日志数据	对话历史、调试日志	`~/.openclaw/agents/<agentId>/sessions`

为什么分开？

它们生命周期不同（模型 Key 可能每月换，OAuth 可能几年换一次）
泄漏后果不同（模型 Key 被偷 = 钱被盗刷，OAuth 被偷 = 账号被劫持）
放一起”图省事” = 一次泄漏全部完蛋

4.2.2 新手最容易踩的坑

以下是高频错误，你最好别踩：

❌ 坑1：把 Key 写进 workspace 并提交 Git

# 千万别这样做！
echo "ZAI_API_KEY=xxx" > config.txt
git add .
git commit -m "add config"
# 然后你的 Key 就全网直播了

❌ 坑2：在群聊截图里暴露 token 发截图前检查一下有没有敏感信息，Ctrl+Shift 遮一下很难吗？

❌ 坑3：多机器共用同一套 Key 却不做轮换 一台机器被黑 = 所有机器都危险。

✅ 建议动作：

Key 放环境变量或配置文件的密钥字段，绝对不要放业务文档
配置文件权限至少收紧到 600：
Terminal window
```
chmod 600 ~/.openclaw/openclaw.json
```
定期执行安全审计：
Terminal window
```
openclaw security audit
```

4.2.3 泄漏后的最短处置顺序

如果真的发现 Key 泄漏了，按这个顺序来，慢了可能钱就没了：

立刻去供应商后台撤销旧 Key（别犹豫，立即马上）
生成新 Key 并更新配置（改环境变量或配置文件）
复查日志与会话是否包含明文敏感信息
运行深度审计：
Terminal window
```
openclaw security audit --deep
```
对外部渠道执行可疑请求回溯（查最近 24 小时有没有异常调用）

⏰ 记住：Key 泄漏后的黄金处理时间是发现后的前 5 分钟。

4.3 技能来源与供应链风险

4.3.1 技能与插件都应视为”可执行代码”

官方文档明确说了：第三方技能与插件要按不可信输入处理。

特别是插件，它是 in-process 运行（也就是说和 Agent 跑在同一个进程里），一旦插件有问题，Agent 也会被拖下水。

这就像你请了个家政服务员，你以为她只负责打扫，但她可能偷偷翻你抽屉。

4.3.2 安装前检查清单（最小版）

安装任何技能或插件前，至少检查这四件事：

检查项	看什么	建议
来源可信度	官方还是第三方？维护者活跃吗？最近更新了吗？	优先选官方或活跃社区
能力风险	有没有请求 `exec`（执行命令）、外网抓取、批量写入？	高风险能力要警惕
文档质量	有没有清晰 README？故障处理说明呢？	没文档的别用
版本固定	是不是用了 `latest`？	固定版本号，避免自动升级踩坑

插件安装建议用固定版本：

# 好例子：指定版本
openclaw plugins install @scope/pkg@1.2.3

# ⚠️ 坏例子：latest 可能随时变
openclaw plugins install @scope/pkg@latest

4.3.3 启用后再加一道保险

就算来源可信，也建议默认关闭高风险工具组：

{
  tools: {
    // 禁止执行任何 runtime 命令
    deny: ["group:runtime"],
    // 禁止访问网络
    deny: ["group:web"],
  },
}

这样就算技能提示词被污染（被恶意输入干扰），也不容易直接外溢成主机破坏动作。

相当于请了家政服务员，但还是把贵重物品锁进抽屉——防的不是好人，是万一出问题。

4.4 执行审批与可视化确认

4.4.1 高风险命令必须”审批后执行”

exec approvals 是主机执行层面的第二道保险。

建议默认值这样配：

{
  security: {
    // 只有白名单里的命令才能执行
    execApprovals: "allowlist",
    // 白名单里没有的命令要询问
    ask: "on-miss",
    // 询问后用户没反应 = 拒绝
    askFallback: "deny",
  },
}

这三项组合起来，效果是这样的：

白名单里的命令 → 直接执行（快）
不在白名单 → 弹窗问你”要执行这个吗？“（等确认）
你没来得及确认 → 默认拒绝（安全）

4.4.2 `safeBins` 与 `autoAllowSkills` 怎么取舍

这两个配置有点容易混，简单解释：

配置	适合谁	什么意思
`safeBins`	零基础读者	只放只读、stdin 型工具（比如 `jq` 用来处理 JSON）
`autoAllowSkills`	有经验的团队	你明确知道技能依赖哪些 CLI，才开这个

给零基础读者的建议：默认先关 autoAllowSkills，手工白名单更稳。

就像学游泳先在浅水区扑腾，别一上来就往深水区跳。

4.4.3 日常核验命令

下面三条命令如果你都能读懂结果，你的安全可控性就已经超过大多数”只会跑 demo”的部署了：

# 1. 查看当前审批策略
openclaw approvals get

# 2. 解释沙箱配置在干什么
openclaw sandbox explain

# 3. 运行安全审计
openclaw security audit

建议每星期跑一次 openclaw security audit，就当是给系统做体检。

4.5 成本控制（费用/速率/上下文）

4.5.1 成本控制从路由开始，不是从报销开始

很多新手以为成本控制就是”月底看账单”，其实那时候钱已经花出去了。

正确姿势：从请求路由开始就控制。

建议先定主模型与回退模型，不要所有请求都打最贵模型：

{
  agents: {
    defaults: {
      model: {
        // 主模型用 Kimi
        primary: "moonshot/kimi-k2.5",
        // 如果 Kimi 挂了或超时，自动切到 GLM-5
        fallbacks: ["zai/glm-5"],
      },
    },
  },
}

这样既保证了能力（优先用好的），又控制了成本（贵的挂了还有便宜的兜底）。

4.5.2 把”重复消耗”挡在入口

两种常见浪费场景：

场景1：会话风暴 一堆人同时问同样的问题，Agent 重复计算。

解决：启用队列收紧（collect）与输入去抖，类似快餐店”合并订单”。

场景2：工具循环 Agent 陷入”做无用功-重试-再做无用功”的死循环。

解决：启用 tools.loopDetection，类似自动贩卖机卡住后自动退币。

4.5.3 读者可执行的成本巡检

每周至少做一次，检查这三项：

查看模型调用异常（超时、限流、失败重试）
核对是否存在”长时间无结果仍持续调用”的会话
检查高风险工具是否被意外放开

成本控制不是”省钱小技巧”，而是系统稳定性的组成部分。

钱烧得太快，系统可能先扛不住。

本章小结

最小权限是 OpenClaw 的第一原则，必须覆盖入口、工具、执行环境三层。
凭证管理要分层，泄漏处置要有固定顺序（先撤销、再换新、查日志、深度审计、回溯排查）。
技能与插件都要做供应链检查，不能”安装即信任”——来源、能力、文档、版本都要看。
exec approvals、sandbox explain、security audit 是三件常用安全工具，建议每周跑一次。
成本管理本质是路由管理和循环管理，不只是看账单。

🎯 下一步做什么？

把 4.1.3 的配置复制到你的 ~/.openclaw/openclaw.json

运行 chmod 600 收紧配置文件权限

运行 openclaw security audit 看看有没有现成问题

做完这三条，你的 Agent 安全基线就已经比 80% 的”跑起来就行”部署靠谱了。