ZGI 受控执行：Agent 的权限、审批与运行边界企业 Agent 的权限验收需要同时验证允许、拒绝、审批和撤权四条路

ZGI 的受控执行能力可以把 Agent 使用的知识、数据、Skills、工具和 Workflow 放进明确的运行范围。上线前仍要用普通用户、业务管理员和无权限账号分别执行同一组任务，确认授权动作能够完成，越界请求明确失败，高风险操作进入审批，权限撤销后立即失效。

在 ZGI 的可自托管 Agent Runtime 工作区中，Agent 可以绑定经过批准的知识库和数据库表，Workflow 可以安排审批和后续执行，Runner 与 Sandbox 承接具体任务。一次正常演示只能证明通路可用，验收还需要把这些配置转换成可重复运行的失败样本。

从任务动作反推最小权限

先列出 Agent 在一个场景中会做的真实动作，再为每个动作指定身份、对象和范围。客服资料查询可能只需要读取当前客户的公开订单字段；退款申请需要创建工单；直接退款则会改变资金状态，应进入更严格的审批链。把“可以访问数据库”写成一条权限过于宽泛，验收时也很难判断对错。

每个动作都应同时准备正向样本和负向样本。正向样本验证授权用户能完成任务，负向样本主动请求其他部门资料、未批准工具、超出金额范围的操作或已撤销权限。系统返回失败时，还要确认业务对象没有发生变化，不能只看页面出现了报错。

提示词可以提醒 Agent 遵守规则，却不适合承担最终授权。用户输入、检索资料和工具返回都可能影响模型判断，执行入口仍需根据当前身份和策略检查权限。OWASP 对过度代理能力的建议同样强调最小工具集合、最小功能范围、下游系统授权和高影响动作审批。

审批测试也要检查真实副作用。提交动作后，任务应该停在审批前；拒绝时不应写入业务系统；通过后只执行当前批准的对象和参数。若审批期间订单状态已经变化，恢复执行前还要重新读取状态，避免拿旧参数覆盖新结果。

权限在上线后会持续变化。员工调岗、项目结束、工具替换或临时授权到期，都需要触发撤权。验收时可以在任务执行到一半撤销权限，再观察后续节点是否继续沿用旧凭据；这个样本比单纯退出登录更接近真实运行情况。

日志需要回答谁以什么身份、对哪个对象、申请了什么动作，策略给出怎样的结果，审批由谁处理，最终是否执行。日志里不应完整保存密钥和敏感正文。对外发送、删除、付款和权限修改等动作，还应保留能够定位业务结果的回执。

在 ZGI 中搭建验收集时，可以把普通查询、跨范围读取、高风险写入和撤权后重试分别做成固定任务。每次修改 Agent、Skill、Workflow 或权限策略后重新运行，比较结果是否仍符合预期。权限边界能通过失败样本反复验证，才适合进入真实业务环境。