IT 负责人要防止 AI Agent 调用 ERP 时越权，核心做法是：为 Agent 配置独立的最小权限身份，将高危操作转入人工审批节点，并把每一次调用、参数、结果和审批动作写入不可篡改的审计日志。权限边界不应只依赖模型自觉，而要落到系统层、流程层和审计层三层控制上。
为什么 AI Agent 接入 ERP 后，权限问题比想象中更棘手
AI Agent 与普通系统集成最大的区别在于：它不是一个固定调用接口的程序，而是一个会根据目标自行组合工具、动态决定下一步动作的执行体。这让传统的“用户—角色—权限”模型出现裂缝。
一个典型场景是：销售助理 Agent 拥有查询客户资料的权限，但当它被要求“把这条订单改一下”时，它可能尝试直接调用订单修改接口。如果它的底层身份沿用了某个高权限服务账号，系统不会拦截它，因为从 ERP 的视角看，请求是“合法”的。
所以，AI Agent 的权限设计不能继续套用“给一个账号配几个角色”的思路。需要从身份隔离、动作分级、审批分流、全程留痕四个维度重新设计。
适合什么企业先做这件事
不是所有企业都需要立刻为 AI Agent 建立完整权限体系。以下三类企业优先级最高：
- 已经把 Agent 接入 ERP、CRM 或财务系统并跑通 Demo 的企业：即将进入生产环境，必须补上权限与审计这一关。
- 计划让 Agent 执行写操作的企业：不只是查询和生成报告，而是创建订单、修改库存、发起付款申请等。
- 多部门共用一套 Agent 或一个 Agent 串联多个系统：权限边界模糊，越权风险会随系统数量成倍放大。
如果目前只是内部知识库问答、内容生成等只读场景，可以先从轻量审计日志做起，不必一次性建设完整体系。
权限设计怎么做：先分清“身份”和“能力”
为 Agent 建立独立身份，而不是复用员工账号
Agent 应该在 ERP 中拥有独立的服务身份，且一个 Agent 对应一类业务能力，不共用同一个高权限账号。这样做的目的是让每一次系统调用都能追溯到“是哪个 Agent 发起”，而不是混在某个员工的权限里无法区分。
具体做法：
- 一个 Agent 一个服务账号，权限按“任务域”而不是“功能点”划分。
- 默认只授予完成当前任务所必需的最小读写范围。
- 禁止 Agent 使用管理员级账号或全量读写账号。
- 对 Agent 能调用的接口做白名单控制，不在白名单内的接口直接系统级阻断。
将操作分为“可自动执行”和“必须审批”两类
最简单的落地方式是给每个动作分级。建议把 ERP 操作分成三类：
| 级别 | 示例 | 处理方式 | |------|------|----------| | 只读 | 查询客户资料、拉取订单列表 | 在授权范围内自动执行 | | 低风险写操作 | 更新备注、创建内部任务 | 自动执行，但事后审计 | | 高风险写操作 | 修改订单金额、删除主数据、发起付款 | 必须人工审批后执行 |
审批动作不应该完全由 Agent 决定。也就是说，Agent 可以发起一个“申请”，但真正执行审批的必须是人，或是企业已经验证过的规则引擎。Agent 不应有权为自己批准高风险操作。
权限边界要写在流程里，而不是依赖提示词
很多 IT 负责人容易落入的误区是：给 Agent 写一段提示词，告诉它“不要做某类操作”，就认为完成了权限控制。这只是一种软约束，Agent 可能因上下文干扰、指令冲突或任务拆分偏差而绕过限制。
硬控制应该放在三个层面：
- 系统层：ERP 侧的身份权限、接口白名单、数据范围过滤。
- 流程层：高风险操作的中断机制和审批流。
- 审计层：全程操作留痕、异常检测和定期复查。
只有系统层限制不住而流程层可以兜底时，Agent 的越权行为才不会直接导致业务损失。
审计日志要记什么，才能做到可追溯可干预
审计日志的价值不只是“事后查问题”，更是日常运维中的风险预警和合规依据。对 AI Agent 来说，审计日志要覆盖传统系统日志覆盖不到的内容。
必记字段建议
- 时间、Agent 身份、触发者身份
- 原始任务目标
- Agent 的决策步骤和选择调用的接口
- 传入的参数与返回摘要
- 涉及的数据范围
- 是否触发审批、审批人、审批结果
- 是否被系统拦截或人工干预
关键原则：Agent 的“思考过程”也要留痕
普通系统日志记录的是“发生了什么”，但对 Agent 来说，还需要记录“为什么要这么做”。这并不是要记录所有模型内部输出，而是记录 Agent 选择某个工具、改变执行路径的关键理由。这样在审计时，才能区分是模型误判还是规则漏洞。
日志存储与保护
审计日志应该与 Agent 运行环境隔离，不存储在 Agent 可写范围内。日志本身要防篡改，建议采用只追加的存储方式。对于涉及财务、客户数据、个人信息的操作，日志访问权限也应纳入管控，避免日志本身成为新的泄露源。
异常处理要预先设计，而不是等出事再救
AI Agent 接入 ERP 后，越权只是风险之一。更常见的是执行中途遇到异常，比如参数缺失、数据冲突、接口超时、审批人不响应。系统设计时必须回答一个问题：当 Agent 无法继续时，它应该停下来还是换一条路走？
建议的默认策略是：
- 涉及写操作的异常，一律停止并转人工。
- 只读操作的异常，允许有限重试，但记录每次重试原因。
- 越权信号一旦出现，立即冻结该 Agent 的执行能力，不允许自我恢复。
此外，IT 团队需要有一个人工接管机制。接管不是简单地在后台看日志，而是能在 Agent 执行序列中插入暂停点、撤回已提交但未生效的操作、并重新分配任务。
常见误区：权限越紧，项目越难落地
有些 IT 团队为了安全，把 Agent 权限压到几乎只读，结果业务部门觉得“不如自己手动操作”，项目推进不下去。权限设计的目标不是“不让 Agent 做事”，而是“让 Agent 在明确边界内高效做事”。
平衡的方式是把权限设计和业务场景绑定。比如针对“销售订单创建”这个场景，先明确哪些字段可以自动填充、哪些必须人工确认；再针对“库存查询”场景，定义可访问的仓库范围。场景越具体，权限边界越容易达成共识。
智未来 AI 在服务企业落地 AI 应用时，通常会先和企业 IT 团队一起梳理 Agent 的实际任务清单，再据此设计权限矩阵和审批流，而不是先上一套通用权限框架。这样既避免过度设计，也能在生产环境前把高风险点识别出来。相关能力可以参考 AI Agent 与数字员工 的交付范围说明。
交付成果应该有哪些
一个完整的 AI Agent 权限与审计方案，最终应该产出以下交付物：
- Agent 身份与权限矩阵：每个 Agent 对应的服务账号、可调接口、数据范围。
- 操作分级清单：明确哪些动作自动执行、哪些需要审批、哪些禁止执行。
- 审批流配置说明：审批节点、审批人、超时策略、驳回处理方式。
- 审计日志规范：日志字段定义、存储方案、查询权限、保留周期。
- 异常处理手册：常见异常类型、处理流程、人工接管步骤。
- 验收用例：覆盖典型越权场景和审批场景的测试用例集。
这些交付物不是一次性文档，需要在 Agent 每一次能力扩展时同步更新。建议将权限矩阵和操作分级清单纳入变更管理流程，Agent 新增工具或接口时，必须先过权限评估。
如果你所在的企业正准备把 AI Agent 从 Demo 推进到生产环境，可以在 联系智未来 AI 咨询企业 AI 项目 中说明当前系统和 Agent 的接入情况，智未来（上海）智能科技有限公司会基于实际任务场景给出权限与审计的设计建议。
常见问题
1. AI Agent 调用 ERP 时，是不是只要给它一个只读账号就安全了？
不是。只读账号只能防止写操作越权，但如果读权限设计不当，Agent 可能读取到不该读的敏感数据，比如全量客户联系方式、定价策略或员工信息。安全控制要同时覆盖“读”和“写”两个维度。
2. 我们有现成的审批流系统，能不能直接让 Agent 对接使用？
可以，但要确认审批流能否区分“人工发起”和“Agent 发起”，以及审批结果能否回传到 Agent 的执行链路中。直接复用是降本的好办法，前提是审批记录能被审计日志完整捕获。
3. 用什么方式监控 Agent 有没有做越权行为？
主要靠审计日志的定期分析。建议设置几个关键检测规则：Agent 是否调用了权限矩阵外的接口、是否在短时间内高频触发审批、是否出现被系统拦截后的重试。触发规则后由 IT 或安全团队介入。
4. 老板希望快速上线 AI 应用，IT 提这么多权限审批要求，会不会拖慢项目？
短期内会多一些设计工作量，但可以避免上线后出现不可控的业务损失。实际做法是分场景推进：先让低风险场景跑起来，高危写操作走人工审批。这样业务能快速见效，安全也有底线。相比上线后再修权限漏洞，前期设计成本要低得多。
5. AI Agent 的审计日志要保存多久？
没有统一标准，取决于企业所在行业的合规要求和内部审计周期。一般建议不低于普通系统的日志保留期，重点场景可延长保存。关键是日志的可查性和防篡改能力，而不是单纯追求保存时长。