智能体的身份:智能体调用工具时,请求上挂的是"谁"?
"智能体干的"不是你审计日志能给出的答案。每一次工具调用都以某个主体的身份离开你的系统——一个服务账号、一段委派的用户令牌,或者一条混合记录——而把这个选择搞错会悄无声息地腐化授权决策,让下游所有审计都失灵。本文讲三种模式、各自的权衡、审计后果,以及一种把整套栈悄悄毁掉的反模式——共享的"机器人用户"账号。
三种模式,回答的是不同的问题。
当智能体调用一个工具——比如"退款一笔"——出去的那个请求上可能挂着三种身份之一,而这个选择决定了下游系统会怎么做每一个授权判断:
- 服务账号(智能体自己的身份)。智能体以自己作为主体认证;下游工具看到的请求是"来自智能体"。授权按智能体的权限来判,而非用户的权限。模型最简单;完全失去按用户分级。
- On-behalf-of(OBO,用一段委派令牌代表用户)。智能体用一段从用户会话派生出来的令牌行动——通常短期、范围窄、绑定受众。下游工具看到的请求是"来自这个用户,经由这个智能体"。按用户的授权得以保留。
- 混合(传输上挂智能体身份、审计元数据里同时记录两个主体)。传输层的凭证是智能体的;请求上携带智能体与人类用户两套声明。授权可以配置为同时要求两边都通过("智能体被授权调用这个工具且用户被授权访问这块数据");审计日志总是把两边都记下来。
没有哪种是放之四海皆准的。选择是这样一个函数:到底谁理应被授权做什么,以及一旦智能体被攻陷你能承受多大的爆炸半径。
权衡,并排来看。
每种模式护住一项性质、又把另一项暴露出来。诚实地把这笔账算清楚:
- 服务账号——实现最简单、运维最容易。代价:每个用户事实上获得了智能体权限的并集;一个本来无权删除记录的用户,正在和一个有权删除记录的智能体说话。智能体凭证被攻陷意味着按它的范围全面失守,没有按用户做的防火墙。
- OBO——保留按用户的授权,把最小权限留在了人这一边。代价:智能体必须被信任去保管这些事实上是用户级凭证的委派令牌;一个被提示词注入的智能体,现在是一个串行挥舞着多个用户权限的被注入主体。令牌寿命和范围,是注入与一次大规模冒充事件之间唯一站着的东西。
- 混合——审计性质最好;支持"智能体可以调用这个工具,且只能在用户对目标资源也被授权时调用"这种策略。实现与运维的部件更多;下游工具得知道怎么读两个主体。
经验法则:低风险、纯内部、不需要按用户分级 → 服务账号。要求按用户授权、智能体足够可信 → 配合激进令牌卫生的 OBO。受管制或高风险、审计义务沉重、多主体策略现实可行 → 混合。
审计后果:把这件事搞错,日志就回答不了"是谁干的"。
审计后果不是抽象的。audit-trails 那篇要求系统能重建任何决策;身份是这条轨迹里那块——少了它,"是谁"这个问题就没法回答。把它简化成纯服务账号模型,你交换出去的具体失败模式:
- 归因塌缩。日志里每一次工具调用都"来自智能体"。被问到哪个用户导致了哪个副作用,你只能通过 run-id 回关到那条提示——而且要看你的追踪流水线在异步扇出之后还把这条关联保住没有。
- 授权判断瞎掉。下游系统是按智能体的权限做的授权判断,不是按用户的。半年后一次隐私复审来问"用户 X 当时是否有权看 Y",只凭审计日志答不上来。
- 监管暴露。金融、医疗与法律——也就是它们各自实战手册里覆盖的那些用例——通常背着对"可追溯、按用户的归因"的法律义务。一份纯服务账号设计上线进去这些领域,是带着一个监管方迟早会找到的审计缺口上线。
实践中可行的实现模式。
混合模式在严肃部署里比教科书上常见得多,部分原因是它把服务账号传输的简洁,与 OBO 审计的完整组合在了一起。站得住脚的实现原语:
- 短寿命 OBO 令牌。用 OBO 时,那段委派令牌的寿命按分钟计、范围按动作切、每次工具调用都重新派生而非每次会话一次。这种模式建在一层夹在智能体与工具之间的授权层之上,而不是建在智能体内部。
- 按动作做委派。用户不把"你能做的一切"委派给智能体;用户授权一类具体动作("对你下过的订单,最多 50 美元的退款"),OBO 令牌的范围正好对应那一类。
- 审计元数据始终带双主体。即便用纯服务账号模型,审计记录也把智能体身份(谁做的)与人类用户(替谁做的)作为分开的字段一起写下。在你还没改授权模型之前,就把这条审计轨迹对未来的监管问题做了未雨绸缪。
- 与轨迹可关联。每次工具调用上记录的身份,按 run-id 与 tracing-and-observability 里的轨迹可关联;审计的答案和行为的答案出自同一条记录。
反模式:给智能体配一个真实的人类账号当"机器人用户"。
诱人的捷径——尤其在限期之下——是开一个名叫 agent-bot 的真实用户账号,让智能体像人一样用它登录下游系统。它在 demo 里能跑,在生产里会炸。它造成的损害:
- 审计日志在撒谎。每一次下游动作都被归到一个不是人的用户身上;日志里没有任何信息说明智能体当时实际是在为哪一个人类用户行动。
- 权限蔓延。那个机器人用户慢慢累积起每一个曾经有人想让智能体用的权限的并集;它成了系统里权限最高的账号,而没有一个具体的人为它负责。
- 凭证散落得太多。
agent-bot的口令或令牌成了一份住在每个智能体 worker、每个 staging 环境、每个开发者机器上的秘密。其中任何一处被攻陷,等于全部被攻陷。 - 合规失败。多数受管制领域明确禁止这件事:一个"用户账号"必须对应一个自然人,共享用户账号违反 HIPAA、PCI-DSS、SOC 2 与多数内控框架里关于身份管理的要求。
永远不要让人和智能体共享一个真实的用户账号。如果你的工具只支持人类用户,那这个工具不适合做智能体集成;建一个服务账号、一条 OBO 流,或者一种混合模型,让审计日志在"是谁干的"这个问题上有一个站得住脚的答案。下一篇关于范围受限凭证的文章是依附在这之上的下一层。