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

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

本章你将学会什么

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

读者前置

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

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

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

传统聊天机器人多数只输出文本。
OpenClaw 这类 Agent 会直接调用工具（读写文件、执行命令、访问网络、操作渠道）。

所以风险模型会从“说错话”升级成“做错事”。

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

建议把权限分三层看：

入口边界：谁能给它发指令（dmPolicy、allowFrom、groupPolicy）。
工具边界：它能调用哪些能力（tools.profile、tools.allow/deny）。
执行边界：调用后在哪跑（host 或 sandbox，是否需要审批）。

只做其中一层远远不够。
例如你只做了 DM allowlist，但放开了 group:runtime，仍可能被提示注入拖进危险命令执行。

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

{
  channels: {
    whatsapp: {
      dmPolicy: "pairing",
      groupPolicy: "allowlist",
    },
  },
  tools: {
    profile: "coding",
    deny: ["group:runtime"],
  },
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "agent",
        workspaceAccess: "none",
      },
    },
  },
}

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

4.2 Key 与凭证管理

4.2.1 三类敏感资产要分开

请把这三类分开管理：

模型 Key（如 ZAI_API_KEY、MOONSHOT_API_KEY）；
OAuth 凭证（存于 ~/.openclaw/credentials/ 与 agent auth store）；
会话与日志数据（~/.openclaw/agents/<agentId>/sessions 与日志目录）。

它们生命周期不同、泄漏后果也不同，不能混在一个地方“图省事”。

4.2.2 新手最容易踩的坑

高频错误：

把 Key 写进 workspace 并提交 Git；
在群聊截图里暴露 token；
多机器共用同一套 Key 却不做轮换。

建议动作：

Key 放环境变量或配置密钥字段，不放业务文档；
配置文件权限至少收紧到 600；
定期执行：

openclaw security audit

4.2.3 泄漏后的最短处置顺序

立刻在供应商后台撤销旧 Key。
生成新 Key 并更新配置。
复查日志与会话是否包含明文敏感信息。
运行：

openclaw security audit --deep

对外部渠道执行一次“可疑请求回溯”（最近 24h）。

4.3 技能来源与供应链风险

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

官方文档明确建议：第三方技能与插件按不可信输入处理。
特别是插件是 in-process 运行，风险等级更高。

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

安装技能或插件前，至少看四件事：

来源是否可信（官方/维护者活跃/最近更新）；
是否请求高风险能力（exec、外网抓取、批量写入）；
是否有清晰 README 与故障处理说明；
版本是否固定（避免直接 latest 漂移）。

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

openclaw plugins install @scope/pkg@1.2.3

4.3.3 启用后再加一道保险

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

{
  tools: {
    deny: ["group:runtime", "group:web"],
  },
}

这样就算技能提示词被污染，也不容易直接外溢成主机破坏动作。

4.4 执行审批与可视化确认

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

exec approvals 是主机执行层面的第二道保险。
建议默认值：

security: allowlist
ask: on-miss
askFallback: deny

这三项组合能显著降低“静默误执行”风险。

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

safeBins 适合放只读、stdin 型工具（如 jq）；
autoAllowSkills 适合你已经明确知道技能依赖哪些 CLI 的团队环境；
对零基础读者，默认先关 autoAllowSkills，手工白名单更稳。

4.4.3 日常核验命令

openclaw approvals get

openclaw sandbox explain

openclaw security audit

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

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

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

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

{
  agents: {
    defaults: {
      model: {
        primary: "moonshot/kimi-k2.5",
        fallbacks: ["zai/glm-5"],
      },
    },
  },
}

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

对会话风暴场景，优先启用队列收紧（collect）与输入去抖，减少同类请求重复计算。
对工具循环，启用 tools.loopDetection 避免无进展空转。

4.5.3 读者可执行的成本巡检

每周至少做一次：

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

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

本章小结

最小权限是 OpenClaw 的第一原则，必须覆盖入口、工具、执行环境三层。
凭证管理要分层，泄漏处置要有固定顺序。
技能与插件都要做供应链检查，不能“安装即信任”。
exec approvals、sandbox explain、security audit 是三件常用安全工具。
成本管理本质是路由管理与循环管理，不只是看账单。