Agent 借用用户令牌为何会绕过审批

一个合法的请求，也可能被 AI Agent 执行成一次越权操作。原文讨论的风险很具体：Agent 借用请求者的身份调用业务系统，系统便难以区分哪些动作是人决定的，哪些是 Agent 自己推导出来的。

作者的主张是保留两种身份：人负责说明任务从哪里来，Agent 用独立身份接受授权和审计。对正在给内部系统接入 AI 工具调用的团队，这比再加一层登录校验更值得检查。不过，文章给出的是安全设计原则，没有实测数据，也没有完整实现。

用户能访问系统，不代表 Agent 能替他执行所有操作

作者用一个假设场景说明问题：员工要求内部 Agent 准备一笔供应商付款。员工可以查看供应商资料，但释放付款需要第二次审批。

Agent 随后拿员工的 access token 调用财务系统。按照作者的设定，系统识别到了合法用户，却无法判断这次调用来自员工点击，还是自主运行的 Agent，于是接受了操作，绕过付款控制。

这里有两个不同的问题：员工想让系统做什么，以及 Agent 获准做到哪一步。

「准备付款」提供了任务意图，却不能自动授予「释放付款」的权限。Agent 在理解请求、选择工具时产生的推断，也不能替代业务审批。

请求者身份说明任务来源，Agent 身份说明实际执行者。

两者合并后，问题会沿着整条执行链扩散：

• 访问日志只记员工，无法直接识别 Agent 的操作。
• 审批规则可能只检查请求者，忽略具体动作。
• 撤销 Agent 权限可能牵连员工的正常访问。
• 调查时难以拆开人的决定与自主执行步骤。

因此，独立身份的价值不只是让日志多一个名字，而是让权限、撤销和追责都能针对实际执行过程。

授权要在调用工具时检查，不能只在对话开始时检查

作者提出，应当沿执行路径同时保留请求者和 Agent 的身份。下游系统根据 Agent 获得的委托权限判断操作能否执行，同时把请求者保留为上下文。

所谓委托权限，就是给 Agent 执行任务所需的权限范围，而不是让它直接继承员工身份下的全部能力。

授权问题也要变得更具体：

「这个 Agent 能否在这些条件下，为这位请求者，对这个资源执行这项操作？」

这里同时涉及执行者、请求者、资源、操作和条件。只问「这个员工有没有访问权限」，覆盖不了这些关系。

检查时机同样关键。Agent 开始时可能只需要读取资料，拿到新信息后才决定调用敏感工具。对话入口的一次校验，无法代替后续每次实际动作的授权。

入口校验只能覆盖当时已知的请求，敏感操作仍需在执行时接受授权检查。

文章还给出了一条审计标准：能否从记录中区分「人提出了什么」「Agent 推断了什么」「系统允许了什么」。如果三者混在一起，即便登录和身份认证都正常，Agent 的责任链仍然不清楚。

我的判断

作者抓住了一个很实用的问题：把用户 token 交给 Agent，接入往往更省事，但执行者身份也更容易被隐藏。对于能够修改业务数据、触发审批或付款的 Agent，保留双重身份有明确价值。

不过，付款例子有一个重要前提：下游系统确实把合法用户身份当成了足够的操作依据。如果财务系统始终强制检查第二次审批，Agent 借用员工 token 也不应直接绕过它。身份混用会削弱控制，但文中的越权结果还依赖授权或审批实现存在缺口。

独立 Agent 身份也不会自动解决问题。权限给得过宽、敏感动作没有审批、下游只记录身份却不执行策略，仍然可能出事。它应当与操作级授权、业务审批配合使用。

原文没有提供实现代码、对照数据或部署结果；其中「平台团队应检查每次动作携带哪些信息」的清单，实际只列出了 requested operation，即请求执行的操作，细节并不完整。文末对 AXEC 的推广也没有补充技术证据。因此，适合把它当成架构评审问题清单，不能当成已经验证的产品方案。

能拿来做什么

• 检查内部 Agent 的工具调用链，确认下游能同时识别请求者与实际执行的 Agent，并明确区分两者的权限用途。
• 在 Node 工具调用服务中，把授权检查放到具体操作执行之前；对于读取后再决定写入的流程，重新检查即将执行的动作。
• 审查前端审批交互与后端接口的对应关系，确保「准备付款」和「释放付款」分别受到业务规则约束，后端能够验证所需审批。
• 抽查一次完整执行记录，尝试还原用户请求、Agent 推断、系统授权结果，并确认能单独撤销 Agent 权限。