关键判断
- 最小权限的核心粒度不是“接了哪个系统”，而是“允许对什么对象做什么动作”。
- 读、写、外发、删除、高权限执行，不该混在同一默认能力包里。
- 对象范围不清晰时，即使动作类型本身不高危，也可能越界影响不相关资料或会话。
- 浏览器 profile、临时目录、任务级子代理、一次性 token 这些隔离手段，本质上都是在压缩失误半径。
- 结果验证不是补丁，而是权限设计的一部分；没有回读校验，用户确认的往往只是“意图”，不是“实际结果”。
很多人说最小权限，脑子里想到的还是老一套：scope 少一点、角色低一点、授权项少一点。这当然没错，但放到 agent 工具链里，只说到这里远远不够。因为 agent 的风险，常常不是“有没有权限”这么简单，而是它到底能对什么对象做什么动作、在什么上下文里做、做完之后有没有被验证。
这也是我今天越来越想把“最小权限”重新讲清楚的原因。一个系统拿到了 OAuth、能调浏览器、能写文档、能发消息，并不自动意味着这些能力应该被打包成默认能力。授权只说明“能做”，不说明“应该默认全做”。如果动作边界没有拆开，读、写、外发、删除、高权限执行混在一起；如果对象范围没有钉死，当前任务和无关资料共处一个上下文；如果会话隔离做得很松，长期登录态、全局工作目录、共享浏览器 profile 被反复复用；那所谓最小权限，最后往往只剩一个好听的名字。
对 agent 来说，我更愿意把最小权限拆成四层。第一层是动作边界：读、搜、起草可以更自动，外发、删除、改权限和高权限执行必须更克制。第二层是对象范围：不是“可以改文档”，而是“只能改这份文档”；不是“可以写文件”，而是“只能写这个目录”。第三层是会话隔离：浏览器 profile、临时目录、任务级子代理、一次性 token，这些不是工程洁癖，而是在限制污染半径。第四层是结果验证：很多系统把审批做到执行前，却没有把验证做到执行后，最后用户确认的只是动作描述，不是实际结果。
最近几天从 browser boundary、授权确认、agent workflow 到今天的 least privilege 笔记，材料其实都在收敛到同一个结论：最小权限不是权限小一点，而是默认只给当前任务所需、只对当前对象生效、只在当前会话内成立，并且执行后能被快速回读验证。少一层，风险就会从“能力很强”慢慢滑成“边界很糊”。
如果你在做个人自动化或小团队 agent workflow，最稳的默认值不是追求一个长期全能代理，而是把能力压到任务级：对象明确、写入少量、会话隔离、结果回显。真正成熟的 agent，不只是会做事，而是知道自己这次到底被允许碰什么。