委任链如何避免权限越权?

委任链的风险，不在于链条有多少层，而在于权限是否在传递过程中被“顺手放大”。当员工请求经由业务 Agent、工具 Agent，最终到达目标系统时，每一层都可能改变执行主体、数据范围或操作类型。若目标系统只看到一个高权限技术账号，就无法判断这次操作是否符合发起人的权限，也无法追溯是哪一层作出了越权决定。

避免越权，首先要把三类身份分开：请求发起人、实际运行的 Agent 实例，以及被调用的工具或目标系统。Agent 不应简单继承当前用户的全部登录权限，也不应长期使用无法区分来源的共享高权限账号。授权判断必须同时验证“用户是否有权要求该动作”和“当前 Agent 是否被允许执行该动作”，不能让 Agent 的较高权限替代用户原有边界。

让权限沿委任链收缩

每次委任都应明确限定数据范围、动作类型、执行对象和有效期限。查询工单状态的 Agent，可以只读取指定项目的数据，不应因此获得批量修改、删除或导出权限；能够调用某个系统，也不等于可以调用其中所有接口。权限最好绑定具体任务或会话，任务完成后及时回收，而不是保留长期有效的静态授权。

高影响操作应设置独立控制。删除、批量更新、权限修改和外部发送，可以由 Agent 准备参数、生成待执行任务或提交审批，但不应因为链条中某一层拥有权限，就自动获得直接执行资格。审批、二次确认、工单关联和时间限制，都是将“可以申请”与“可以落地”分开的手段。

让每一次委任可被还原

审计日志不能只记录最终系统中的“调用成功”。至少应关联用户身份、Agent 身份、实例或版本标识、任务标识、父调用标识、工具或 API、目标资源、实际授权范围、匹配的授权规则、审批依据和最终结果。多 Agent 协作时，还要保存用户到 Agent、Agent 到其他 Agent、Agent 到工具的传递关系。

日志的价值在于还原责任链，而不是保存模型的全部内部推理。更新或删除操作应保留必要的变更前后信息或可核验摘要；敏感数据则应脱敏、摘要化并限制日志访问。结构化日志、统一关联标识和防篡改存储，能让安全团队判断权限是否被扩大、结果是否超出任务范围，以及问题究竟发生在哪一层。

真正稳健的委任链，应满足一个原则：权限只能因明确的业务目的而被授予，不能因链条延伸而自然升级；每次动作都必须能回答谁发起、谁授权、谁执行、作用于什么资源，以及为何允许执行。