Agent 人工审批门设计：从确认弹窗到可审计的授权契约

当 Agent 准备删除资源、发送邮件、创建付费任务或修改生产配置时，产品常见的处理方式是弹出一个“确认执行”按钮。这个界面能降低误操作，却不等于真正的授权设计。若确认记录没有绑定具体动作、操作者、资源范围和有效期，攻击者或错误重试都可能把一次同意复用到另一项操作。

把审批看成一份短生命周期的授权契约更合适。模型提出计划，确定性服务把计划归一化为可审计的动作，再由具备权限的人签发一次性确认。确认只证明“此人同意这一份内容摘要在这一段时间内执行”，不证明模型此后可以自由执行类似动作。

审批对象必须是规范化动作

不要让前端直接展示模型自然语言然后把“已确认”传回服务端。服务端应先生成稳定的 approvalPayload：工具名、目标资源 ID、字段差异、预计费用、依赖条件、请求版本和哈希。比如“删除旧数据”太宽泛；“删除项目 p_42 中 2024-01 前 18 个草稿，预计不可恢复”才是可以判断的动作。

一个简化的审批记录可以包含如下字段：

{
  "approvalId": "apr_01J...",
  "runId": "run_01J...",
  "actionHash": "sha256:...",
  "actorId": "user_42",
  "requiredScope": "project.records.delete",
  "expiresAt": "2026-07-18T12:10:00Z",
  "singleUse": true
}

actionHash 的输入必须来自服务端的规范化结构，而不是前端传来的任意 JSON。执行器收到确认后重新计算哈希，确认资源版本、目标租户和工具参数仍然一致；任何一处变化都要使旧确认失效并要求重新审批。

审批前后都要做权限检查

一个常被忽略的风险是“审批时有权限，执行时权限已经变化”。例如员工在确认后被移出项目，或管理员撤销了高风险 scope。执行前必须重新加载当前身份和资源权限，审批记录不能绕过实时授权。审批只是必要条件，不是唯一条件。

这也解释了为什么审批人和执行人不一定相同。某些流程允许业务负责人确认、后台 worker 执行，但 worker 仍然以受限服务身份运行，并把 approvedBy、executedBy 分别记录。对于跨租户支持操作，还应记录工单号或理由，避免“管理员确认”变成无限制通行证。

把风险分级写进执行策略

不是所有工具都需要相同强度的确认。可以按副作用划分策略：纯读取无需审批；可逆低风险修改需要单人确认；不可逆、跨系统或高金额操作需要二次确认、延迟窗口或双人批准。重点是策略由工具元数据和业务规则决定，而不是由模型自己说“这不危险”。

确认页面应显示模型之外的事实：目标系统、资源数量、影响范围、费用上限、是否可撤销、过期时间和执行后可看到的结果。不要用长篇解释掩盖关键差异；如果计划会影响一千条记录，数字必须比自然语言更醒目。

处理重复点击、过期和撤销

审批 token 应是一次性的。第一次被消费后，后续相同请求返回已消费状态，而不是再次写入。用户取消、权限变化、计划重算、资源版本变化和超时都应显式撤销审批。若工具是异步任务，消费审批和创建任务应在同一个事务边界内，避免“确认已用但任务没有创建”的灰色状态。

上线验证可以用四个场景：篡改一个参数后旧确认必须失败；同一确认重复提交只产生一次操作；审批过期后请求被拒绝；审批后撤销用户权限，执行器仍拒绝。四个场景都通过，说明确认从 UI 交互变成了真正的授权契约。

审批策略本身也要可追溯

工具的风险级别和审批规则会变化。今天允许单人确认的导出动作，明天可能因为数据分级调整而需要双人审批。不要只保存最终的 approvalId，还要保存当时命中的策略版本、阈值和风险标签。否则事后无法回答“为什么这一次只需要单人确认”，也无法安全重放历史任务。

策略变更后，尚未消费的审批应根据变化类型处理：若只是展示文案更新，可以保留；若 scope、金额上限、资源范围或审批人数变化，则应撤销旧确认并要求重新签发。将这一判断放在策略引擎里，而不是让前端根据页面刷新时间猜测。这样审批系统既能保护一次操作，也能在规则演进时保持证据完整。

延伸阅读

• MCP Server 认证边界
• MCP 多租户隔离
• 提示词注入防御