智能体权限合规，操作仍可能越界

AI Agent 有权限，也可能把事情做错：用户只让它修改供应商地址，它却为了确认身份，查了发票、读取付款记录，还通知了财务系统。每一步可能都没越过系统授予的权限，却已经超出最初请求的范围。

作者讨论的是这种「计划变了，授权没跟上」的问题。核心建议是：授权判断要跟着实际行动走，不能只在任务开始时检查一次。对正在给 Agent 接工具、数据库和内部系统的开发者，这比单纯讨论权限够不够更有参考价值。

有权限，为什么还会偏离用户要求

原文用的是一个假设场景，并非真实事故复盘。

一个内部采购 Agent 收到任务：修正某家供应商的地址。它最初只打算找到供应商记录，但用用户提供的名称没有查到，于是调整计划：

1. 搜索发票，寻找匹配的公司名称。
2. 读取付款记录，确认供应商身份。
3. 更新供应商资料。
4. 通知财务系统。

这些步骤看起来都有理由，但任务范围已经变了。原先是修改一条供应商记录，现在涉及财务数据读取和另一个系统的写入。

问题在于，Agent 仍处于同一个用户会话里，也仍然持有那组宽泛权限。如果系统只在任务开始时做授权检查，新增行动就会自动继承最初的信任。

系统允许调用某个工具，不等于用户授权了这次调用的全部用途。

这里需要分清两件事：Agent 能访问哪些资源，以及它为了当前任务应该访问哪些资源。原文要补上的，是后一道约束。

哪些计划变化，需要重新检查授权

作者建议，把每次实质性的计划变化视为一次新的授权决策。这里的「实质性」，指会改变风险的变化，并不是措辞调整或普通的执行顺序变化。

平台应检查四个位置：

• 计划转变：是否增加了工具、系统、记录类型或数据类别？
• 范围扩大：是否从一条记录变成多条，或从查询变成导出？
• 副作用变化：是否从读取变成写入、通知、转移或删除？
• 理由变化：Agent 能否解释新增行动为什么是完成用户目标所必需的？

只要变化影响风险，就先暂停该行动，再执行策略检查。判断依据应包括当前计划、操作目标、数据范围、所用工具和预期副作用。

这不要求人类批准每一次工具调用。常规动作可以由策略层重新判断；影响较大的变化，才要求人工批准。

人工审批也不能只显示「Agent 需要更多权限」。审批者需要看到确切的拟执行动作，才能判断它是否符合原任务。例如，读取付款记录与通知财务系统应当被明确呈现，而不能藏在一句笼统的申请里。

审计日志要能还原权限何时失配

原文要求审计链路记录五类信息：原始请求、计划版本、授权决策、计划变化，以及控制结果。

它们需要连起来看。只有一条「权限检查通过」，事后审查者只能知道 Agent 当时拥有权限，却无法判断这份权限何时开始与实际工作不匹配。

计划版本在这里承担的是定位作用：这次授权针对的是哪一个计划？新增步骤出现后，系统有没有重新判断？最后是放行、阻止，还是交给人工批准？

因此，审计记录不只是保存工具调用结果，还应保留行动变化与授权变化之间的对应关系。

我的判断

我认同作者对问题的划分：入口授权解决不了整个执行过程中的范围漂移。相比只给 Agent 配一组长期有效的工具权限，跟随计划变化重新判断，更接近用户对具体任务的授权意图。

但原文没有实验、事故数据或方案对照，采购案例也明确是假设。它提出的是一条合理的设计原则，尚不足以证明某种实现已经有效降低风险。

真正难的部分，作者没有展开：怎样识别「实质性变化」，怎样表达数据范围，以及策略检查失败后如何继续任务。检查过粗会漏掉风险，过细又可能制造大量中断。

还有一个边界需要补充：Agent 能解释理由，只能作为判断材料。解释得通，不代表行动就获得了授权。我的取舍是，把这套机制作为既有工具权限的补充，同时保留资源和操作层面的限制。

能拿来做什么

• 给 Node 服务中的 Agent 工具执行入口增加动作检查，把目标系统、记录范围、操作类型和预期副作用作为判断输入，避免只依赖会话开始时的授权结果。
• 在内部管理系统里，把单条修改变成批量修改、查询变成导出、读取变成通知等变化列为重新检查的触发条件，并明确哪些情况需要人工批准。
• 为审批页面展示具体拟执行动作，同时在日志中关联原始请求、计划版本和授权结果，让审核者与事后排查者都能看懂任务如何扩大。