s02 让 Agent 能读写文件、编辑内容和运行命令。能力越多，宿主越不能把模型生成的参数直接交给执行器。Permission 层在副作用发生前回答：这次调用应拒绝、自动允许，还是由用户确认？
tool_use → 明确拒绝规则 → 可信允许规则 → 无法确定则确认 → handler三种结论，而不是一个布尔值
deny：明确禁止，不能靠随手确认绕过；allow：命中可信、范围明确的规则；confirm：风险取决于上下文，把决定交给用户。
当前教学代码在 deny 与询问规则都未命中时会默认允许，工作区外文件访问也可以经用户确认后继续。这正是需要明确标注的简化边界：真实系统更稳妥的默认值通常是未知即确认，异步场景无法确认时拒绝。
检查必须发生在执行之前
正确顺序是先解析工具名称和参数，再做权限判断，最后调用 handler。若先执行再审计，拒绝信息只能记录已经发生的副作用。
被拒绝的调用仍要返回正常 tool_result，说明原因。模型可以改用只读工具、缩小范围或请求明确授权，而不会因协议缺口卡住。
文件权限基于规范化路径
仅检查字符串是否以工作区路径开头并不可靠。..、符号链接、相似前缀目录和绝对路径都会制造绕过空间。路径判断应先规范化，再验证目标是否位于允许根目录内，并分别考虑读取、创建和覆盖。
即便检查通过，工作区也不是沙箱：Shell 可以切换目录，程序可以跟随符号链接，子进程还可能访问网络或系统资源。
Shell 规则只是教学近似
上游示例用命令规则和拒绝列表解释权限路径，但 denylist 无法穷举 Shell 组合语法、解释器嵌套、重定向和编码变体。真实系统应优先采用专用工具、参数化执行、操作系统隔离、最小权限账户和资源限制。
用户确认要提供足够上下文
确认提示至少包含工具、目标、风险和即将发生的动作。一次确认也不应自动升级成无限期、全项目授权，除非产品清楚展示授权范围。
Permission 是政策层，Sandbox 是强制执行层。两者应组合使用，不能互相替代。
建议覆盖的测试
- 拒绝规则优先于允许规则；
- 工作区外读写进入拒绝或确认路径；
..、符号链接和相似前缀不能绕过；- 未知工具默认不自动执行；
- 拒绝结果保持调用 ID 对应；
- 后台轮次无法确认时安全失败。
小结
Permission 的核心不是危险词表，而是执行前的授权决策。路径和 Shell 规则只提供教学级边界，真实安全仍依赖能力收窄、隔离、审计与安全默认值。