为什么人工智能代理的权限应该从零开始？

The New Stack刊登的一项测试显示，赋予人工智能代理超出其所需范围的权限，可能会把一个简单的逻辑错误转化为无法由模型自行停止的重复性财务操作。在一项客户发票测试中，一名支持代理确认支付操作失败、客户资金并未被扣除，但尽管现有数据并不支持退款，它仍执行了退款操作，并将错误重复了五次。

Claude Sonnet 5成功发现了为测试这一缺陷而设计的六种情况，而Claude Haiku 4.5则全部失败。此外，在系统指令中加入一行要求在执行财务操作前验证交易状态的指令，也解决了这一问题。但作者认为，这两种解决方案都很脆弱：机构可能会将模型替换为更便宜的版本，或者在测试期间修改指令，从而使保护机制在没有明显警告的情况下消失。

被拒绝的权限作为安全屏障

经受住这些变化的保护措施，是从一开始就不让代理拥有billing:refund权限。这样一来，无论模型或指令措辞如何，执行都会在权限层失败。这就是人工智能代理架构中最小权限原则的核心：目标不仅是阻止攻击者或保护机密令牌，也是防止一个善意的代理以自动化速度、在没有人工监督的情况下执行错误指令。

代理与执行固定职能的传统服务账户性质不同。支持代理可能在09:00读取工单，在09:04执行退款，并在09:11修改座位数量。因此，它在一周内所有潜在工作所需的权限集合，并不一定反映它在单项任务中所需的权限。

测试测量了什么？

作者构建了一个测试环境，在一个虚构的企业应用程序接口中设置了分布于九个领域的30项权限，包括工单、用户、计费、订阅、文件、消息、审计、管理和搜索。其中13项权限能够修改或提取状态。测试包含20项任务，每项任务都有可由系统自动验证的结果，例如关闭工单或退还发票金额。

测试在Claude Haiku 4.5和Claude Sonnet 5两个模型层级上比较了四种权限模型，共运行160次：

• 宽泛权限：采用包含30项权限的长期授权。
• 固定角色：采用包含17项权限的支持角色，这些权限取自典型职位描述。
• 按任务限制：为每次运行授予所需权限，并在运行结束时撤销。
• 即时启用：从零权限开始，在需要时申请每项权限并说明理由。

按任务限制可缩小损害范围

按任务限制的模型完整完成了所有任务，与宽泛授权相比，使用的权限约为其十五分之一。偶发的拒绝和重试并未导致接口调用次数出现明显增加。

固定角色模型在两个指标上都是最弱的。它授予了17项权限，其中有四项没有任何任务使用，但同时缺少九项基本权限。要扩大该角色以使所有任务成功，需要26项权限，而每项任务所需权限的中位数仅为两项。因此，固定角色会同时过于宽泛且权限不足，因为它依据的是职位名称，而不是实际工作来作出决定。

即时启用模型达到了同样较低的损害范围，但需要增加约80%的接口调用次数。此外，任务模型中的权限拒绝通常针对可选的探索路径，而固定角色模型中的拒绝则是最终性的，因为它阻止了一项基本权限。

这为什么对机构很重要？

结果表明，模型能力和系统指令是可能发生变化的两层防御，而未被授予的权限即使在更换模型或修改prompt后仍然有效。因此，团队应围绕当前任务设计代理权限，并让敏感权限具有临时性且可审计，而不是将其集中在一个永久且宽泛的角色中。

这项测试仍受限于人工环境、20项任务以及两个Claude模型，因此无法证明结果会在每个机构或每种模型中完全一致。但它提供了一个明确的实践信号：如果架构允许代理执行其并不需要的操作，仅测试代理本身是不够的，因为更换模型或修改指令可能改变行为，而造成损害的能力仍然存在。