人类审批是表演？Agent权限治理的盲区

当审批变成了摆设

最近，一篇题为《Keeping a human in the loop is theater. Here is what holds》的文章在开发者社区引发了讨论。作者David Emilio Sierra Puentes（用户名juandelossantos）在文中提出了一个尖锐的观点：在许多AI Agent系统中，所谓的“人类在环”（human-in-the-loop）审批机制，其实只是表演性质的，并不能真正阻止风险发生。

他在后续的跟进说明中进一步解释，经过社区讨论后，他发现问题的核心不在于“审批环节是否薄弱”，而在于“审批环节根本没有被绑定”。

一个根本性的设计漏洞：无绑定的审批

根据原文的后续说明，最尖锐的讨论指出，第一道“门禁”并非不够强，而是处于“未绑定”（unbound）状态。Agent可以自行铸造令牌（mint a token），而系统会直接接受这个令牌。这意味着一项审批操作确实授权了某个动作，但这个动作与最初的审批上下文之间，并没有建立起不可篡改的关联。

这并非一个理论上的缺陷。如果Agent能够生成令牌，并且系统不对令牌的来源和审批链进行验证，那么人类审批就变成了一个可以绕过或伪造的标记。攻击者或失控的Agent只需要在获得一次审批后，就能复用或伪造令牌，执行未经授权的操作。

令牌（Token）与令牌铸造（Minting）

在AI Agent与权限系统的语境中，令牌通常指一种短期凭证，用于证明“某个主体已被授权执行某个操作”。它可以是JWT、OAuth access token、能力令牌（capability token），也可以是内部服务间的签名票据。令牌的核心价值在于：执行端不必每次都回查审批数据库，只需验证令牌的签名与声明即可放行。

“铸造令牌”（mint a token）指的是签发新令牌的动作。在健康的设计里，签发权应仅属于受信任的授权服务，且签发时必须把审批记录、操作主体、目标资源、有效期等上下文写进令牌声明。若Agent自身具备铸造能力，或系统不校验令牌的签发者与审批链，令牌就从“授权凭证”退化为“自我声明”，审批与执行之间的绑定随之断裂。

三个讨论线程如何改变设计

作者提到，社区中的三个讨论线程（threads）促使他重新思考了设计方案，而不仅仅是修改措辞。虽然原文没有详述每个线程的具体内容，但可以推断，这些讨论聚焦于权限模型的根本问题：如何让系统设计真正 enforceable，而不是停留在声明层面。

一个有效的权限治理模型，需要确保每一次敏感操作都绑定到具体的审批记录、执行主体和操作上下文。如果令牌的颁发和验证是脱节的，那么再多的审批界面也只是装饰。

对构建Agent系统的启示

对于正在构建AI Agent应用的团队来说，这篇文章提出了一个值得警惕的模式。许多团队在 demo 阶段会加入“人类确认”按钮，以展示对安全性的重视。但如果后端没有将这次确认与后续执行的权限严格绑定，那么这套机制在真实威胁面前形同虚设。

要避免这种“表演”，需要从系统设计层面入手：令牌的签发必须经过审批流程，且令牌本身应携带审批上下文，并在执行端进行验证。任何由Agent自行生成的令牌都应被默认拒绝。这种设计思路，本质上是对最小权限原则的严格执行。

最小权限原则（Principle of Least Privilege）与能力令牌

最小权限原则要求每个主体只拥有完成当前任务所必需的最小权限，且权限应尽可能短暂、具体、可审计。在Agent系统中落实这一原则，通常采用能力令牌（capability token）模式：令牌不是笼统的“已批准”标记，而是精确描述“允许对资源R执行动作A，有效期至T，关联审批ID为X”的不可伪造凭证。执行端只接受由受信任授权服务签发、且声明与当前请求完全匹配的令牌。

这种模式把审批从“界面上的确认”转化为“密码学上可验证的授权链”，使Agent无法通过自行生成令牌来绕过人类审批。任何来源不明或声明不匹配的令牌都应被默认拒绝，而不是事后补救。

结语

“人类在环”不应只是一个界面上的确认按钮，而应是系统权限链路中不可绕过的一环。这篇文章的价值在于，它用一次具体的讨论提醒开发者：不要用审批的表演，掩盖绑定机制的缺失。