按操作影响设计 AI 智能体审批规则

AI Agent 执行命令前弹出一个「确认」按钮，并不等于用户真的掌握了风险。如果看不清它要改哪里、会产生什么影响，这个按钮很容易变成机械点击。

作者给出的判断是：审批边界应该围绕环境、数据、权限和可恢复性来划，而不是看命令长短。这篇短文没有提供可直接套用的命令黑名单，但提出了一组适合拿来检查 Agent 权限设计的问题。

哪些操作需要审批，不能只看命令长相

一条很长的查询，可能只是读取本地测试表；一条很短的命令，却可能修改生产环境的权限。用命令的长度或表面复杂程度判断风险，很容易分错类。

「只读」也不是天然安全。作者举的例子是：读取凭证文件，再把内容发送到其他地方。原文件没有发生变化，秘密却已经泄露。

审批要检查完整动作，包括读取什么、发往哪里，以及最终影响什么。

因此，作者建议从五个问题开始设计审批规则：

• 操作会影响哪个环境？
• 能否通过常规、经过验证的流程撤销？
• 是否可能暴露机密数据？
• 是否改变访问权限、计费、可用性或持久化记录？
• 操作目标是否有明确边界，还是可能意外扩大？

这里的「可撤销」不只是理论上能修回来，还要有实际验证过的恢复路径。「目标有边界」则是在问：Agent 执行的范围，是否可能超出人最初审查的范围。

这组问题的价值，是把笼统的「危险命令」拆成可以检查的条件。同一种操作，换了环境、数据或目标范围，审批要求就可能不同。

确认请求必须让人看得懂，也必须限制得住

作者给出了一个审批请求的示例：把已经审查过的配置变更应用到 staging 服务，说明要修改的两个值，并指出回滚使用哪份旧配置。

这个请求交代了目标、变更内容和恢复办法，用户才有条件作出判断。相比之下，在大量终端输出后面只问一句「继续吗？」，更像是在考验用户的耐心。

不过，信息清楚还不够。

一次批准，只应该授权当时审查过的那个动作。

如果执行目标、提交内容或所需权限发生变化，旧批准就不能继续充当通行证。否则，用户同意的是一项具体修改，系统拿到的却可能是一份范围不断扩大的授权。

作者提到，OWASP 的 AI Agent Security 指南讨论了限定工具范围和人工监督。但文章关注的难点，是如何把原则变成系统实际执行的权限限制。写在提示词里的要求，与执行时真正拦得住操作，是两件需要分别解决的事。

我的判断

我认同作者把重点放在「批准什么」上。相比单纯维护命令黑名单，这套思路更能覆盖只读数据外传、目标范围扩大等风险；相比每一步都弹确认，它也更重视审批信息是否足够。

但它仍然是一份设计讨论。作者明确说明，文中的策略是示意，并非已经部署的访问控制系统记录，也没有给出对照数据证明它能减少多少误操作，或者增加多少审批成本。

还有一处材料缺口：原文提到一张建议决策表，但提供的正文里没有表格内容。因此，无法据此列出作者规定的「必须审批命令清单」。

一般团队落地时，还得回答谁维护规则、系统如何识别环境、如何判断动作发生变化。这些实现细节原文没有说清。它适合用来审视现有方案，距离可直接采用的权限标准还有一步。

能拿来做什么

• 给日常 AI 编程工具梳理操作边界时，逐项检查目标环境、机密数据、权限变化和影响范围，不要只按命令名称分组。
• 让 Agent 修改配置前，在确认界面展示具体服务、变更值和回滚配置，使审批人能够核对实际影响。
• 为批准记录绑定明确的目标、变更内容和权限需求；执行前发现这些条件变化时，重新请求审批。
• 检查工具的只读能力是否同时允许向外发送内容，尤其关注凭证文件读取与网络发送组合起来的路径。