演示阶段一个账号能跑，上线后就不够了
做原型时，工程师常用自己的账号连接邮箱、文档库和客服系统，几分钟就能演示 Agent 自动找资料、生成回复。业务负责人看完觉得效果不错，下一句往往是“那就给它更多权限，直接上线”。真正的风险也从这里开始。
个人账号一旦离职、改密码或触发二次验证，流程就会中断；管理员账号如果被 Agent 误用，影响范围又太大。企业需要的不是一个永远在线的万能账号，而是一套与具体任务匹配、能停用、能审计的机器凭证管理方式。
先列清 Agent 到底要做哪些动作
不要笼统地问“需要什么权限”，而要把流程拆成动作：读取哪些客户字段，能否下载附件，能否新建工单，能否改价格，能否对外发送，能否删除记录。读取、建议、创建、修改和删除是完全不同的风险等级。
每个动作还要写清对象范围和触发条件。例如客服 Agent 可以读取当前工单相关知识，但不能浏览全部客户合同；可以生成回复草稿，但发送必须由坐席确认；可以给工单加标签，但不能关闭投诉。权限跟着任务走，才能在出现问题时知道该关哪一扇门。
- 按读取、建议、创建、修改、删除拆分动作。
- 限定数据范围、使用场景和有效时间。
- 高风险动作默认保留人工确认。
建立凭证清单，结束共享账号的习惯
凭证清单至少记录系统名称、账号类型、负责人、权限范围、创建日期、有效期、存放方式和撤销入口。密钥不要写在提示词、文档或聊天记录里，也不要因为调试方便长期放在开发者电脑。能使用企业密钥管理或受控环境变量的，应集中管理。
Agent 使用的账号最好与员工账号分开，并能识别到具体流程。这样日志里看到的操作才有意义。一个共享账号同时被五个自动化流程使用，出错时很难判断是哪条流程执行了动作，也无法只暂停其中一个。
最小授权不等于每次都让人点确认
有团队担心权限收紧会把自动化做成“半天弹一次审批”。其实审批应该围绕风险设置，而不是围绕每一步设置。读取公开知识、生成内部摘要可以自动执行；批量发信、修改合同、导出客户数据和删除记录则需要人工确认或双人复核。
成熟流程还会设置额度和频率限制，例如单次最多处理多少条数据、一天最多发送多少封邮件、异常重试几次后自动停止。即使模型判断出错，技术边界也能把损失控制在较小范围。安全不是一句“请谨慎操作”，而是系统层面的限制。
上线当天就要准备撤销和追责
Agent 上线前要演练如何停用账号、撤销密钥、暂停任务和恢复数据。日志需要记录谁发起、Agent 读取了什么、调用了哪个工具、做了什么修改、结果是否成功。发生异常后，团队能够在几分钟内停止，而不是先到群里问“这个账号谁管”。
企业 AI 的价值来自它能进入真实流程，但进入得越深，越不能靠口头约定管理。凭证清单、最小权限、风险审批、日志和撤销机制看起来不如演示精彩，却决定了 Agent 能不能从一次展示变成长期可用的生产工具。每季度再做一次账号复核，清理已经停止的流程和过期权限，避免试点结束后凭证仍长期有效。
要点总结
- 原型验证可以短期受控使用，上线时应尽量改为独立、可识别、可撤销的服务账号或机器身份。
- 对外发送、金额变更、批量导出、删除数据和影响客户权益的动作通常应保留审批。
- 合理设计不会。低风险动作自动执行，高风险动作审批，通常比事后补救更高效。
参考来源说明
本文围绕“企业 Agent 一上线就要更多权限？先做凭证清单和最小授权”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。