先给结论：企业 Agent 的有效动作权限必须由后端计算：
Agent capability ∩ requester permission ∩ action approval
也就是 Agent 被允许做什么 ∩ 请求人对哪些对象能做什么 ∩ 这一次动作是否获得所需批准。三项少一项都拒绝，默认值必须是“不执行”。
这套设计适合 Agent 已连接 CRM、ERP、财务、项目、消息或账号系统的场景；纯公开信息问答不需要动作审批，但仍要做数据可见范围校验。独立 LLM 范围门禁可以拦截“不属于这个岗位 Agent 的问题”，却不能充当授权系统。
三重校验分别解决什么
| 校验层 | 要回答的问题 | 典型拒绝原因 |
|---|---|---|
| Agent capability | 这个 Agent 的职责是否包含该动作和字段？ | 销售 Agent 没有付款、删客户或提权能力 |
| requester permission | 当前请求人能否操作这个具体对象？ | 销售只能操作本人客户，不能改其他团队订单 |
| action approval | 该动作是否需要本次批准，批准是否仍有效？ | 改价未获销售负责人批准，或批准已过期 |
三层都要细到“动作 + 对象 + 字段”，不能只校验菜单。能读客户名称，不等于能读账期；能追加跟进，不等于能改负责人；能生成对外回复，不等于能发送。
一次动作应怎样判定
假设销售请 Agent 把一条客户跟进写入 CRM：
- 后端先确认该 Agent 的 capability 只允许追加跟进和更新下一步日期，不允许修改客户负责人。
- 再确认销售对这个
customerId具有写权限，联系人也确实属于该客户。 - 最后按动作政策判断：追加普通跟进可免审，批量改日期或修改关键状态需要负责人批准。
- 三项通过后，才生成可执行的动作令牌，绑定请求人、对象、字段、参数摘要、有效期和批准引用。
- 执行前再次校验对象版本和令牌状态；执行后独立回读。
若 Agent 临时发现“顺便改一下负责人更合理”，新动作不在原令牌范围内，必须重新走授权，不能沿用前一次批准。
高权限凭据不是授权
很多连接器为了跨系统执行，会使用服务账号或托管凭据。它可能在技术上能访问全公司数据，但这只是通道能力，不是业务许可。后端必须在调用目标系统前，把请求裁到三重交集内；凭据不能暴露给模型，也不能让 Agent 自由拼接任意接口参数。
同理，读取权限与动作权限要分开：readSummary、readEvidence、prepareAction、executeAction、approveAction、export 应当是不同能力。财务可以让 Agent读取待开票订单，不代表这个人能开票；经理能批准动作，也不代表可以绕过执行岗位直接操作资金。
LLM 门禁能做什么、不能做什么
独立范围门禁适合做前后双闸：提问进入主循环前，判断是否属于岗位范围；草稿生成后，检查是否越过了禁止话题或对外口径。它应使用干净上下文、结构化输出，并在不可用时默认转人工。
但 LLM 的 IN_SCOPE 只说明“可以继续处理”，不说明“可以执行”。模型不能可靠承担员工身份核验、对象归属、审批有效期、字段白名单这些确定性判断，更不能因为“看起来合理”自行扩大权限。
授权审计最少记录 8 项
每次允许或拒绝都应记录：请求人、Agent 版本、动作类型、目标对象、字段范围、三层判定结果、批准引用、最终执行与回读结果。拒绝记录同样重要，它能暴露权限配置错误、反复越权请求和业务流程缺口。
上线前建议用同一组动作让销售、销售经理、财务和管理员分别执行，验证“同一句话、不同身份、不同对象”得到正确结果。可对照AI Agent 权限审计清单和AI Agent 项目验收检查点设计用例；对数据边界要求更高的项目，还应继续看信任与数据安全。
权限设计的目标不是让 Agent 什么都不能做，而是让每次动作都能明确回答：它为什么能做、替谁做、只对哪个对象做、谁批准、结果是否已核实。
