AI Agent 一旦从“回答问题”进入业务系统，就不应继续沿用管理员身份运行。它可能读取客户资料、生成项目任务、调用知识库，甚至写回业务记录；任何权限过宽、身份混用或日志缺失，都会把一次模型误判放大为数据泄露或错误操作。服务账号隔离的核心，不是多创建几个账号，而是让每个 Agent 的身份、数据范围和操作能力都与具体任务绑定。

按任务拆分身份与权限

不同 Agent 不应共享同一个密钥。负责生成项目周报的服务账号，只需要读取项目进度和任务数据，并将结果写入待确认记录；负责知识库问答的服务账号，只应访问被授权的文档和检索接口；涉及客户、合同或财务资料的流程，则必须使用更严格的数据边界。服务账号的权限应明显窄于普通管理员，尤其不能默认拥有删除、批量修改或管理成员的能力。

权限设计至少要同时限制三件事：能读取哪些资源，能修改哪些字段，以及能在什么流程状态下执行。比如，Agent 可以创建“待确认任务”，但不能直接把任务标记为正式承诺；可以生成报价建议，但不能发布给客户。把高风险写操作放在人工确认之后，往往比单纯提高模型准确率更有效。

隔离密钥、数据和执行记录

每个服务账号都应使用独立凭据，并将密钥保存在服务端的安全配置中，不能写入前端代码、提示模板或共享文档。账号停用、权限调整和密钥更换，都应能够单独完成，避免一个 Agent 出现问题时牵连整套系统。

审计记录不能只保留“某个服务账号调用过接口”。至少要关联操作者或服务账号、操作时间、对象、操作类型、关联任务、流程版本、执行结果和失败原因。对于生成内容，还应保留原始输入、检索来源和人工确认记录。这样才能区分问题究竟来自数据、提示模板、模型判断还是权限配置。

服务账号隔离也不等于完全自建。更稳妥的做法是把核心业务数据、权限和审计放在可控边界内，对外部模型仅发送完成任务所需的数据，并在流程层隔离模型供应商。上线前逐项检查：每个 Agent 是否有独立身份，权限是否遵循最小化原则，高风险操作是否需要批准，日志是否可追溯，服务账号是否能够随时暂停。能被清晰限制、观察和撤销的 Agent，才适合进入真实业务流程。