Tenuo 给依赖升级 Agent 分权限，写代码和改测试不再共用一把钥匙
据 Tenuo 工程文章，safe-upgrade 把 Jev 的类型化判断、LangGraph 的流程状态与 Tenuo 的任务授权组合起来，用于依赖升级。
作者：韩启明｜OC 政策与安全编辑
据 Tenuo 工程文章，safe-upgrade 把 Jev 的类型化判断、LangGraph 的流程状态与 Tenuo 的任务授权组合起来，用于依赖升级。
一句话结论：让模型选择下一步之前，可信代码就应划定它有哪些合法选项和执行权限。
此前 OC 在《Jev 不再生成自由文本，类型正确离判断正确还有多远》中讨论过结构正确与语义正确的差别。这次案例新增的是执行层：就算一个动作被模型选中，也不该因此自动拥有全部仓库写权限。
按照 Tenuo 的设计，程序先算出可用动作，Jev 在候选中选择，可信路由再将选择映射到具体工作单元。测试作者、实现者和验证者获得不同的短期授权。文章演示了实现者尝试改写测试时，在真正执行写入之前被拒绝的情况。这是项目展示的实现与测试，不等于已经完成独立安全审计。
这种分工有一个很具体的意义：负责修代码的代理，不能顺手把让自己失败的测试删掉。不过，权限分离并不能证明测试本身足够好；测试作者也可能遗漏重要行为，验证者也可能依赖错误的验收标准。
还要区分工具授权和进程隔离。限制某个受保护写文件工具，并不会天然限制所有安装脚本或子进程。Tenuo 的说明也把操作系统沙箱列为另一层约束。部署方需要确认所有有副作用的入口都经过控制，不能在主工具上加锁，却给辅助 shell 留出绕行通道。
在 CI 中，仓库身份能做什么，与这一次升级任务能做什么，也是两种粒度。把授权绑定到特定包、版本、路径和期限，才能把广泛的账户能力缩小到这次工作所需的范围。
关键事实
- 来源：Tenuo 工程案例，使用 Jev、LangGraph 与 Tenuo。
- 核心设计：先确定合法动作，再分别授予工作单元权限。
- 边界：工具调用授权、操作系统隔离与语义验证各司其职。
OC 判断
有效的权限设计应该能拒绝一个看起来很合理、实际超出职责的动作。团队验收这类系统时，可以主动设计越权场景，观察底层副作用是否确实没有发生，而不仅是检查日志里是否出现了一句拒绝。
为什么重要
- 对开发者：拆分测试、实现、验证和发布的权限。
- 对企业：把账户权限继续收缩到具体任务。
- 对用户：自动化失败时，应有可解释的停止原因。
评论
围绕这篇文章补充信息、提出问题或分享观察。