blast-radius-permission

name	blast-radius-permission
description	面向 OpenClaw 的风险半径权限设计技能。用于设计或审计删除、执行 shell、改配置、外部发送、子 agent 派生等高风险动作的权限与确认逻辑。

风险半径权限系统

这是什么

权限不是简单的 allow / deny。真正该问的是：

1. 这件事影响谁
2. 影响范围有多大
3. 结果能不能回滚
4. 谁来承担后果

这个 skill 就是把权限设计成“按风险半径管理”，而不是只按工具名称管理。

在 OpenClaw 里何时使用

1. 审计删除操作
2. 审计 shell 执行权限
3. 审计 message / 对外发送行为
4. 审计 gateway config 变更
5. 审计 sessions_spawn 是否过宽
6. 设计自动模式边界

核心原则

1. 先问风险，再问技术上能不能执行。
2. 可恢复操作和不可恢复操作不能同等对待。
3. 本地读操作、写操作、删除操作、对外动作应分层。
4. 危险的 broad allow 规则要特别警惕。
5. 自动模式不能绕过关键安全闸门。

OpenClaw 的风险分层建议

低风险

1. read
2. web_fetch
3. 只读类查询
4. 本地非破坏性枚举

中风险

1. write
2. edit
3. 常规 exec（非删除、非系统配置）
4. 本地文件改写

高风险

1. 删除文件或目录
2. gateway 配置变更或更新
3. 对外发送消息
4. 用户身份发送 Feishu 消息
5. 大范围 shell 操作
6. 生成或派生高权限子 agent

实战判断框架

执行前先判断：

1. 影响范围是单文件、单目录、整个项目，还是对外世界
2. 是否可回滚
3. 是否会改变共享状态
4. 是否会代表用户发声
5. 是否可能扩大后续权限

在 OpenClaw 里的典型约束

1. 删除类操作前走确认工具。
2. 外部发送前确认对象和内容。
3. 改配置前先读 schema，再决定字段。
4. 子 agent 默认不继承不必要的写权限和外发权限。
5. broad shell allow 不能被默认视为无害。

常见失败模式

1. 觉得“只是 Bash”所以风险不高。
2. 自动模式里保留了太宽的 allow，实际等于裸奔。
3. 临时授权和持久授权混在一起。
4. 用户以为只是改一个文件，实际影响了整套配置。
5. UI 上说需要确认，后端却偷偷放行。

OpenClaw 审计清单

1. 哪些工具可以直接执行
2. 哪些工具需要额外确认
3. 哪些工具在当前会话不该开放
4. 是否存在过宽的 exec / spawn / external-send 能力
5. 是否区分“临时允许一次”和“以后都允许”

你可以产出的东西

1. 一份 OpenClaw 风险分级表
2. 一份“动作 → 风险半径 → 是否需确认”的矩阵
3. 一份自动模式安全边界清单