| name | blast-radius-permission |
| description | 面向 OpenClaw 的风险半径权限设计技能。用于设计或审计删除、执行 shell、改配置、外部发送、子 agent 派生等高风险动作的权限与确认逻辑。 |
风险半径权限系统
这是什么
权限不是简单的 allow / deny。真正该问的是:
- 这件事影响谁
- 影响范围有多大
- 结果能不能回滚
- 谁来承担后果
这个 skill 就是把权限设计成“按风险半径管理”,而不是只按工具名称管理。
在 OpenClaw 里何时使用
- 审计删除操作
- 审计 shell 执行权限
- 审计 message / 对外发送行为
- 审计 gateway config 变更
- 审计 sessions_spawn 是否过宽
- 设计自动模式边界
核心原则
- 先问风险,再问技术上能不能执行。
- 可恢复操作和不可恢复操作不能同等对待。
- 本地读操作、写操作、删除操作、对外动作应分层。
- 危险的 broad allow 规则要特别警惕。
- 自动模式不能绕过关键安全闸门。
OpenClaw 的风险分层建议
低风险
read
web_fetch
- 只读类查询
- 本地非破坏性枚举
中风险
write
edit
- 常规
exec(非删除、非系统配置)
- 本地文件改写
高风险
- 删除文件或目录
gateway 配置变更或更新
- 对外发送消息
- 用户身份发送 Feishu 消息
- 大范围 shell 操作
- 生成或派生高权限子 agent
实战判断框架
执行前先判断:
- 影响范围是单文件、单目录、整个项目,还是对外世界
- 是否可回滚
- 是否会改变共享状态
- 是否会代表用户发声
- 是否可能扩大后续权限
在 OpenClaw 里的典型约束
- 删除类操作前走确认工具。
- 外部发送前确认对象和内容。
- 改配置前先读 schema,再决定字段。
- 子 agent 默认不继承不必要的写权限和外发权限。
- broad shell allow 不能被默认视为无害。
常见失败模式
- 觉得“只是 Bash”所以风险不高。
- 自动模式里保留了太宽的 allow,实际等于裸奔。
- 临时授权和持久授权混在一起。
- 用户以为只是改一个文件,实际影响了整套配置。
- UI 上说需要确认,后端却偷偷放行。
OpenClaw 审计清单
- 哪些工具可以直接执行
- 哪些工具需要额外确认
- 哪些工具在当前会话不该开放
- 是否存在过宽的 exec / spawn / external-send 能力
- 是否区分“临时允许一次”和“以后都允许”
你可以产出的东西
- 一份 OpenClaw 风险分级表
- 一份“动作 → 风险半径 → 是否需确认”的矩阵
- 一份自动模式安全边界清单