智能体借用员工账号办事，**条审计线已经断了

员工把自己的账号或 API 密钥交给智能体，往往是试点最快的接法：日历能读了，文件能改了，工单也能提交。可一旦动作真正发生，业务系统只看见“这个员工做了什么”，看不见是谁提出目标、哪个智能体执行、它为何获得这项权利，也无法区分人的直接操作与机器代办。借用人的身份，首先丢掉的不是登录便利，而是责任边界。

NIST 在 2026 年 8 月 27 日发布的文章中指出，共享个人或企业凭据会制造问责缺口；代理应被视为独立实体，拥有自己的标识、凭据和权限，并与委托它的用户或系统绑定。文章同时提醒，长期 API 密钥、宽泛授权和过度依赖人工确认，都是既有身份治理问题在智能体规模下的放大。智能体上线前，身份设计要先于工具接入。

真正需要解决的不是“给不给智能体账号”，而是如何同时说明四件事：谁提出任务、谁执行任务、这次允许做什么、何时必须停止。任何一项缺失，日志都只能记录动作，不能证明授权。

人的身份、智能体身份和具体任务必须同时存在。员工负责表达意图，智能体负责执行，任务则限定这次行动的目标与边界。三者合并成一个登录账号，审计记录就无法还原真实调用关系。

企业可以为每个生产智能体建立注册记录，写明业务所有者、技术负责人、运行环境、模型与版本、可用工具、风险等级、数据范围和停止方式。注册表不是静态名单，它要跟随部署、版本变更、人员离岗和流程下线同步更新。一个代理身份不能代表所有业务场景。同一套智能体在整理会议纪要和提交付款草稿时，应使用不同的任务身份与授权策略。

执行时，令牌和日志至少要同时携带委托人、代理身份、任务编号和策略版本。人的离岗不应留下仍可工作的“孤儿代理”，代理升级也不应沿用旧版本的全部信任。身份生命周期必须覆盖创建、变更、暂停、撤销和归档。

这不等于从头发明一套协议。NIST 提到 OAuth、OIDC、SPIFFE 等现有机制可作为起点，SCIM 可支持身份创建、更新和撤销。企业真正要补的是任务上下文：这次授权服务于哪个目的、面向哪个资源、允许什么动作、由谁承担结果。成熟协议解决“怎样传递身份”，业务策略负责回答“这次为何允许”。

长期 API 密钥上线方便，却不能证明实际持有者是谁；任何拿到密钥的人或服务都可能调用接口。密钥若出现在配置、日志、Markdown 文档或调试记录中，风险还会随智能体跨工具传递而扩大。短命任务配长期凭据，是典型的生命周期错配。

更合理的做法是按任务签发短期、受众受限、范围受限的凭据。例如，只允许读取指定客户目录，只能在十分钟内创建采购草稿，不能发布、删除或访问相邻项目。授权应描述动作、对象和条件，而不只是“财务人员”“项目成员”这样的宽泛角色。任务结束、人员离岗或风险升高时，凭据必须立即失效。

企业还要把撤销当成一次可测试的业务动作，而不是后台配置。可以在试点中途主动收回令牌，检查代理是否停止、已排队任务是否取消、下游工具是否继续接受旧会话、异常是否进入人工接管。若凭据已泄漏，只改变主系统密码却没有清理配置、缓存和日志，风险仍会存在。安全的凭据不是“足够复杂”，而是作用范围小、寿命短、随时可撤。

对于高风险接口，还可采用发送方约束或持有证明等机制，降低令牌被复制后直接使用的可能。技术选型可以不同，但验收问题应一致：这个凭据只能由谁使用、只能向谁使用、只在何时有效。用三个具体答案替代一把长期万能钥匙。

现实中的智能体很少只调用一个系统。员工提出“整理续约风险”，代理可能先读取客户资料，再调用分析工具，最后让另一个代理生成工单。每一跳单独看都可能拥有合法身份，但组合起来可能偏离最初意图。身份可识别，不代表整条执行链仍在原授权范围内。

因此，授权上下文必须沿调用链传递，并在下游继续收窄。上游拥有“查看全部客户”的权限，不代表下游代理也应得到同样范围；它或许只需要三家即将续约客户的指定字段。任务从分析转向写入时，还应重新评估风险，而不是沿用读取阶段的许可。委托越深，剩余权限应越少，新增动作应重新过闸。

工程上可以把任务目标、资源清单、允许动作、截止时间和禁止项写成可机器判断的授权上下文，并为每次下游调用记录父任务。若代理更换工具、改变对象或请求更高权限，策略系统应拒绝、缩小范围或要求一次有信息量的人工确认。调用链控制的核心不是多记日志，而是阻止权限在传递中悄悄变大。

把所有危险动作都弹给员工确认，看似稳妥，实际可能造成“连续点同意”。如果确认框没有显示对象、金额、数据范围、后果和不可逆性，人只是在替系统完成形式批准。NIST 把这种现象与授权疲劳联系起来：确认过于频繁，用户会被训练成下意识放行。有效确认必须让人看见即将发生的具体变化。

可以把动作分为只读、可撤回写入、高影响写入和禁止四档。查询库存可自动执行；创建采购草稿可完成后等待复核；付款、删除和外发数据需要强确认；与业务目的无关的工具调用直接拒绝。审批要落在风险跃迁点，而不是平均撒在每一步。

确认界面还应展示“谁委托、哪个代理、改什么、影响谁、能否撤回”，并把人的决定写回同一任务链。对于重复、低风险动作，可事先批准一份范围清楚的执行计划；一旦对象、金额或工具越界，再触发确认。人工不是替系统兜底，而是对关键变化作出可追溯决定。

一条可用的记录至少回答：谁发起、哪个代理版本执行、收到什么任务、用了哪些数据和工具、每次授权依据是什么、何处经过人工确认、最终改变了什么。日志的主键应是任务与代理，而不只是员工账号。

日志还要关联当时的授权快照、策略版本和关键输入输出摘要。若只保存结果，不保存当时可见的对象和规则，事后就无法判断动作是合法委托、配置错误、提示注入还是权限漂移。回放必须复原当时看见的对象、规则和决定。

生产试点可先选一条低风险流程，建立独立代理身份、短期令牌、分级动作和撤权演练，再统计越权拦截、人工确认、令牌失效、异常接管和回放完整率。团队还应主动测试错误目标、被污染文档、孤儿凭据、下游越权和撤权后的失败方式。安全边界要通过反向测试证明，而不是靠流程图宣称。

企业不必等所有新标准成熟才行动。**步清理共享账号和散落密钥；第二步为生产代理建立注册表；第三步把委托人、任务、资源和时限写入授权；第四步让高影响动作经过清楚的确认与回退。自治程度越高，身份和授权越不能模糊。没有独立身份、最小权限和完整回放的流程，应停在受控试点。真正的生产能力不是代理可以做多少，而是组织能准确说明它为何被允许这样做，并在授权消失时让它安全停下。