一个能查客户资料、改订单状态、给客户发消息的智能体，如果用的是管理员账号，它就不再是一个工具，而是一个有特权的内部员工。
区别是，员工会离职，账号会回收；智能体的权限如果没人管，可能一直留着。
企业级智能体和普通聊天机器人最大的区别，不是回答得多好，而是它能动多少东西。
权限要分四层
数据权限：能看哪些客户、订单、合同、文档。 操作权限：能查、能改、能提交，还是只能给建议。 角色权限：销售、客服、财务、管理层看到的东西不一样。 时间权限：临时项目结束后，权限能不能自动收回。
很多项目只做了第一层，后三层没做，上线后只能靠人盯着。
最小权限，不是口号
最稳妥的做法是：默认只能读，写操作单独申请。
- 能查报价，不代表能改报价；
- 能看工单，不代表能关闭工单；
- 能给客户发消息，不代表能承诺交期；
- 能提交审批，不代表能审批。
每开放一个写权限，都要问：出错谁负责，能不能回滚，有没有日志。
审计日志要能回答三个问题
- 谁在什么时间，让智能体做了什么？
- 它读了哪些数据，改了什么字段？
- 出问题时，能不能还原到操作前？
如果日志只记录“智能体调用成功”，等于没记录。要记录到具体人、具体动作、具体对象。
三个常见错误
用个人账号跑智能体。 员工离职，账号还在，权限就失控。
把 API Key 写在前端或共享文档里。 谁能拿到 Key，谁就能调用。
上线后再补权限。 权限是架构的一部分，不是上线后的补丁。后补通常意味着重做。
一个简单做法
先画一张表：智能体、数据、动作、审批人、日志位置。
每一行都有人负责，才允许上线。没有负责人的行，先关掉。
企业级智能体的价值，是把重复工作接过去；但前提是，它只能在被允许的范围内动。权限设计不是拖慢项目，是让项目敢用。
权限还要能收回。员工转岗、离职、项目结束，智能体的权限要跟着变。很多系统只做了授权，没做回收，时间一长，账号比人还多。建议每季度做一次权限盘点：谁还在用、能看什么、该不该收回。盘点的结果要有人签字。如果做不到自动回收，至少设一个到期时间，临时权限到期自动失效，比事后追责有用。
权限表最好在上线前就贴到墙上，而不是出事后再找。每一条权限，都要有人能解释为什么给。
权限要能收，也要能查。