Agent权限为何要按任务授权

Agent 的权限设计，正在从“给账号配权限”转向“给任务配权限”。传统业务系统里，权限通常绑定在角色和菜单上，调用路径相对固定，某个角色能访问哪些接口、参数范围如何，基本是写死的。Agent 完全不同，它把自然语言意图翻译成工具调用，同一句用户请求，今天可能只查一条记录，明天就可能连带改配置、发通知、拉一批业务资料。路径不固定，爆炸半径就不固定，这正是按任务授权而非按身份授权的根本原因。

如果把 Agent 当成挂在生产环境里的万能服务账号，风险会迅速累积。最小权限在这里必须下沉到每一次工具调用，而不是停留在“给不给管理员权限”的争论上。设计时要拆开看三个维度：它代表谁在做事、当前任务需要哪类能力、数据范围有没有按会话和租户切开。身份、能力和数据范围分开管理，比笼统地讨论角色权限更接近真实风险。同一个身份如果既能读生产数据，又能写生产数据，还能跨系统编排，一次误判或一次提示词层面的干扰，影响面就会从“答错一句话”变成“动了真实业务”。正确的做法是默认拒绝，只为当前任务打开必要能力，并让这些能力可过期、可撤销、可审计。

实现上不必追求一套完美的零信任蓝图，先把 Agent 会碰到的调用链画清楚，再按风险收权更落地。第一步是盘点它被允许使用的工具和下游系统，按只读查询、有限写入、不可逆变更、跨系统编排给动作分级。只读和写入不要绑在同一套凭据上，能用任务级、会话级的短时授权，就不要发放长期高权限令牌。权限应跟着任务走，而不是跟着部署单元走。第二步是把身份从“Agent 这个进程”里拆出来，一次调用至少要能回答发起人是谁、代表哪个租户或业务、当前会话是哪一次。同一个 Agent 服务处理不同用户请求时，不能共享一份过宽的访问凭证，否则最小权限只写在文档里，运行时仍然是一把总钥匙。

高风险动作要单独设闸。删除、批量导出、资金类操作、权限变更、对外发信，不应只靠模型自己判断该不该做。可以要求二次确认、双人复核，或把动作降级为生成草稿、等人审批。最小权限不是把 Agent 锁死，而是把不可逆后果从自动路径里拿掉。同时必须有回收机制，任务结束、会话超时、策略变更时，临时授权必须失效；定期查看 Agent 实际用到了哪些能力，把长期不用的权限收回去，这和给人做权限复核是同一件事，只是对象从员工变成了会自己选工具的程序。

审计日志同样要按任务链路设计。Agent 一次回答背后可能有多轮工具调用，只记下某接口返回成功，调查时仍然是断的。能用的审计记录要把这些维度串起来：谁发起了任务、哪个 Agent 身份在执行、对应哪次会话、调用了什么工具、作用在哪类资源上、策略是放行还是拒绝、执行结果如何、发生在什么时间，并且需要一个贯穿多跳调用的关联标识，否则对话、工具调用和下游系统日志会碎成三段，对不上。字段设计上有两个常见坑：一是把完整提示词和完整业务数据原样写入日志，审计要的是可追溯，不是再造一份敏感数据副本，证件号、密钥、客户隐私应脱敏或做不可逆处理；二是只记成功、不记拒绝，被策略挡住的调用往往更有调查价值，漏记等于给试探和绕过留盲区。

上线前值得过一遍的检查点包括：Agent 能接触的数据是否仍按既有分类分级来控，而不是因为“模型需要上下文”就把整库内容灌进去；跨部门、跨租户的数据在会话之间有没有隔离；能否说清某个 Agent 当前拥有哪些能力、停用后授权是否失效；审计记录能否支撑一次完整的事件还原，从用户一句话到中间每一次工具调用再到下游系统的结果。责任边界也要能落到人，Agent 出了错，调查时应能定位到发起人、审批人和当时生效的策略版本，而不是只看到一个共享服务账号。最小授权和审计日志不是给 Agent 加两道装饰性控件，而是在承认它会自己选动作的前提下，把爆炸半径和事后可追溯性先做进架构——权限能收多紧、日志能还原多完整，往往比争论模型换哪一家，更能决定这套 Agent 能不能进生产。