智能体权限管理中的核心问题，不是“有没有权限”，而是“权限代表谁、因何任务、在何种边界内生效”。身份传递机制正是连接用户意图与工具执行的控制链：员工发起任务，智能体携带与该员工绑定的身份凭证访问工具，工具再依据凭证校验操作范围并记录责任主体。若智能体长期使用共享服务账号，系统只能知道“某个智能体”执行了操作，无法可靠区分具体操作者，也难以将权限限制在用户原有范围内。
从用户身份到任务身份
身份传递不应等同于简单转发登录凭证。更稳妥的设计，是在用户身份之上叠加任务约束：凭证不仅关联员工，还应限定本次任务能够访问的资源、允许调用的工具和操作等级。例如，员工要求查询本周订单数据时，智能体只获得订单数据的只读权限，并限制在当前周次，不应因此获得客户手机号、支付信息或其他业务数据。
这意味着授权对象要从静态角色转向“用户身份加任务上下文”。同一名员工在不同任务中，智能体可以拥有不同的临时权限；任务完成后，相关凭证自动失效。权限系统因此必须同时判断请求者是谁、任务是什么、目标资源是什么，以及操作是否具有副作用。
传递链条必须可验证
在支持 OAuth 的工具中，典型链条是“员工登录—获取令牌—智能体携带令牌执行操作—工具验证令牌并记录”。对于 Shell 工具或本地脚本，则应使用与特定用户绑定、且仅允许限定操作的模拟令牌或范围受限 API 密钥。关键不在凭证形式，而在于身份不可伪造、权限不可任意扩大、操作能够追溯到具体人员。
多租户环境还必须在网关层进行二次校验。每次请求都应同时核对租户身份与令牌作用域，不能完全信任智能体自行声明的租户或资源范围。这样才能避免一个租户的智能体访问另一个租户的数据。
高风险操作不能只靠身份传递
身份传递解决的是“谁在操作”，并不自动解决“操作是否应当执行”。删除、批量修改、资金操作、信息导出和权限变更等高风险动作，仍应由安全网关拦截并等待人工确认。与此同时，动作日志、权限决策日志和原始请求响应应分别留存，且决策日志由独立审计服务生成。
成熟的身份传递机制，最终应形成三层约束：用户身份限定责任主体，任务身份限定授权范围，安全策略限定执行条件。只有三者同时成立，智能体才不会从“代表用户办事”滑向“借用户身份扩大权限”。