AI CRM最小权限怎么落地？把查询、建议与写入拆成三道授权门

AI助手能“帮我查客户”与能“替我批量改客户”不是同一种权限。若模型直接复用管理员账号，一句含糊指令就可能变成越权查询、错误写入或外发。AI CRM的权限设计应从具体工具和业务动作出发，把查询、建议、写入分别设门，并让最终结果可回读、可审计、可撤销。

先质疑一个常见假设：模型不是新的超级用户

NIST对最小权限的定义是：用户或代表用户运行的进程，只获得完成指定任务所必需的授权与资源。AI助手正是“代表用户运行的进程”，因此它不应拥有比当前用户更大的数据范围，也不应因为接入多个工具而自动获得这些工具权限的并集。

OWASP把过度代理能力归因于功能过多、权限过大和自主性过强，并建议限制可调用扩展、缩小功能范围、使用最低权限身份，以及对高影响动作进行独立验证和批准。CRM落地时要把这些原则转成工具白名单、字段范围、动作风险级别和确认规则。

三道授权门对应三种不同证据

查询层也不是零风险。客户列表、联系方式、报价、合同金额和跟进备注应按对象、字段与行级范围授权；汇总答案不得通过统计或错误提示泄露无权查看的客户存在。建议层要显示使用了哪些记录，不能把推测包装成CRM事实。写入层必须展示对象、字段、旧值、新值和影响范围，批量动作还要显示预计条数。

授权还要绑定时间与场景。销售在“拜访准备”场景只需读取本人客户、近期跟进和在途商机，不需要合同附件导出；主管在“团队预测”场景可以看到汇总与所辖商机，但不应自动获得联系人私密字段。临时项目授权设置开始、截止和复核人，到期后自动回收。员工调岗或离职时，先停用代理会话和工具令牌，再交接业务对象，历史审计中的原操作者不得被接任者覆盖。

工具权限要比页面菜单更细

为每个AI工具建立清单：工具名、业务目的、可读对象、可写对象、字段、最大批量、可调用时段、是否允许外发、调用身份和回滚方式。将“客户管理”拆成查客户、建客户、改归属、导出、合并、删除等不同能力；将“发送消息”拆成生成草稿与实际发送。删除、批量改归属、导出敏感字段和对外发送应默认不提供给自动执行链。

确认卡必须在动作发生前出现

高影响动作的确认不能写成“是否继续”。确认卡应列出将调用的工具、目标记录、变化字段、外部接收方、不可逆影响和撤销方式。一次确认只授权当前明确动作，不能演变成整个会话永久授权。低风险、可逆、单记录的写入可在企业策略下简化，但仍需结果读回；批量、跨客户、跨系统或含敏感字段的动作应提升审批级别。

工具超时和部分成功必须按业务结果处理。例如创建任务成功、发送提醒失败时，系统不能整体重试并再次创建任务；应先回读任务ID，再只补偿失败的提醒。模型输出的“已完成”不构成证据，只有下游系统返回结果且CRM读回字段一致，才向用户显示完成。无法确定结果时标记“待核对”，禁止用乐观状态掩盖不确定性。

审计要能重放业务链，而不是只存聊天记录

NIST AI RMF强调在AI生命周期内识别、衡量、管理和治理风险。对应到CRM，审计记录至少包含操作者、代理身份、模型/提示版本、工具与参数摘要、授权依据、读取对象、确认卡、调用结果、业务记录ID、失败与补偿。为保护隐私，日志不必复制全部客户数据，但要保留能证明“谁基于什么权限对什么对象做了什么”的最小证据。

上线验收应建立红队与日常用例：越权查询、间接提示注入、重复提交、工具超时、部分成功、撤回确认、人员离职、临时权限到期、模型输出与实际写入不一致。结合CRM数据权限设计、CRM审计日志验收、AI客户作战简报与AI创建客户确认闭环检查真实边界。

主要信息来源

• NIST SP 800-53 Rev.5：安全与隐私控制
• NIST：Least Privilege术语
• NIST AI RMF 1.0
• OWASP：Excessive Agency

准备启用CRM AI助手时，先从一项只读查询和一项单记录写入做权限验收。可通过网站现有咨询入口沟通工具边界、确认规则与审计证据。