AI 代理安全：访问权限、密钥与 human-in-the-loop
AI 代理可以搜索 CRM、写邮件、执行命令、更新任务，并调用外部 API。正因为如此，AI 代理安全 必须在上线前设计，而不是等到第一次事故之后再补救。最常见的问题是权限过宽、密钥出现在提示词和日志里，以及缺少 human-in-the-loop，导致代理可以在没有人工确认的情况下直接行动。
- 访问权限 - 代理只能看到它真正需要的系统和字段
- 密钥 - API key、token 和密码不应出现在提示词、git 或普通日志中
- Human-in-the-loop - 关键操作应由人工确认
- 核心原则 - 不是“先给最大权限以防万一”，而是只给最小必要权限
- 实际收益 - 降低数据泄露、误操作和高成本回滚的风险
为什么 AI 代理比普通机器人更危险
普通聊天机器人很多时候只是回答问题。AI 代理的能力更强：它会读取文档、调用工具、修改数据库记录、创建账单、发送客户消息，甚至执行代码。自治能力越高，错误的代价越大。
常见风险：
- 代理同时拿到了 CRM、邮件、知识库和支付系统的访问权；
- 个人数据、商业条款和内部指令进入了同一个上下文；
- 员工为了测试，临时把真实 token 粘贴进系统提示词；
- 日志保存了完整用户输入以及敏感密钥；
- 代理在没有审核的情况下发送消息、删除记录或执行错误操作。
结论： 代理安全不只是“保护模型”，还包括访问控制、密钥管理、日志策略和审批流程。
访问权限：最小权限，而不是完全开放
最常见的错误，是因为“集成更快”就直接给代理管理员账号。开发初期看起来方便，但在生产环境里非常危险。
如何限制访问权限
- 拆分角色 - 客服代理不应该看到财务报表，分析代理也不应该直接给客户发消息。
- 限制数据范围 - 不是整个 CRM，而是只开放需要的实体、字段和项目。
- 区分读取和写入 - 先从 read-only 开始，只有在确实需要时才加写权限。
- 使用服务账号 - 不要使用员工个人登录账号。
- 定期复查权限 - 权限需要定期审计，而不是永久有效。
| 方式 | 会发生什么 | 风险 |
|---|---|---|
| 给代理管理员权限 | 代理能看到并修改所有内容 | 出错时损失最大 |
| 仅对所需数据 read-only | 代理能分析，但不容易破坏流程 | 风险更低，审计更容易 |
| Role + scope + approve | 代理被限制，修改前还要审批 | 速度和控制之间更平衡 |
哪些系统最容易出问题
- CRM - 联系人、商机、备注、电话、邮箱；
- 邮件和消息系统 - 存在对外发送风险；
- 文件存储 - 合同、报告、个人数据；
- 金融系统 - 账单、支付、退款；
- 终端工具 - 命令、部署、迁移、数据删除。
如果一个代理需要同时访问五个系统，通常应该先问一句：是不是应该拆成多个职责更窄的代理。
密钥：最常见的泄露位置
密钥通常不是因为“超级黑客攻击”而泄露，更常见的是团队自己把它放到了不该放的地方：
- 被误提交到 git 的
.env； - 为了方便直接写进系统提示词；
- 发给外包或同事的截图、工单和文档；
- 请求和响应日志；
- 测试 JSON 文件和开发笔记本。
密钥管理的基本规则
- 把密钥放在 secret manager 或受保护的环境变量里，而不是提示词文本中。
- 在工具层注入 token，不要在模型层暴露。
- 对日志中的敏感字段做脱敏 - key、password、cookie、card number、access token。
- 区分 dev、stage 和 prod - 使用不同的密钥、scope 和限制。
- 准备吊销和轮换机制 - 一旦泄露，可以快速替换，而不必停掉整个系统。
好的实践： 模型只知道自己可以调用 create_invoice() 或 search_crm() 这样的工具，但永远看不到这些工具背后的真实 API key。
Human-in-the-loop：什么时候必须由人确认
并不是每个代理动作都需要人工审批。但有一类操作，加入 human-in-the-loop 节省下来的损失，往往比多花的时间更大。
建议人工确认的场景：
- 代表公司发送给客户的消息；
- 修改价格、折扣、合同条款或商机状态；
- 删除数据、文件和记录；
- 服务器命令和部署操作；
- 任何带有法律或财务后果的动作。
常见的控制模式
| 模式 | 如何工作 | 适用场景 |
|---|---|---|
| 全自动 | 代理自己判断并执行 | 只适合低风险内部任务 |
| Draft mode | 代理准备草稿，由人点击 confirm | 客服、销售、文档流程 |
| 双重审批 | 高风险操作必须单独 approve | 金钱、生产环境、删除、权限变更 |
对大多数 SMB 来说，更合理的方式是：代理负责收集信息和准备草稿，由人来确认对外或关键动作。
日志、审计与事故调查
如果代理犯了错，企业需要知道：
- 它收到了什么输入；
- 它调用了哪个工具；
- 工具返回了什么数据；
- 是谁批准了这个动作，或者为什么它会自动执行；
- 结果可以多快回滚。
因此，建议保留：
- 工具调用日志；
- 用户和会话 ID；
- 提示词或代理配置版本；
- 人工审批记录；
- 已脱敏的错误日志，避免明文暴露密钥。
重要： 什么都记、但不脱敏，本身就会变成新的泄露源。审计很重要，但不能以明文保存密码和 token 为代价。
更安全的 AI 代理架构
下面是一套适合很多项目的最小实践框架：
- 每个代理或每种角色使用独立服务账号
- 使用权限很窄的工具，不要做一个“什么都能干”的万能工具
- 使用 secret manager / env，不要把密钥放进提示词或仓库
- 对外部、财务和 destructive 操作加入审批步骤
- 做日志和监控，并对敏感数据脱敏
- 定期轮换密钥并复查权限
上线前应检查什么
- 代理不是在没有必要的情况下使用管理员身份运行；
- 仓库里没有真实 token 和密码；
- 测试数据不包含真实个人数据；
- 关键操作不能在没有确认的情况下执行；
- 每个工具的读取范围和修改范围都定义清楚；
- 发生事故时，有明确的停用代理流程。
常见实施错误
- 一个代理包打天下 - 客服、财务、后台都交给同一个代理。
- 把密钥写进提示词 - 因为“调试更方便”。
- 没有 read-only 阶段 - 从第一天起就允许写和删。
- 没有 human-in-the-loop - 直到第一次昂贵事故发生。
- 没有审计链路 - 出事后无法还原发生了什么。
代理越自治，就越需要像安全工程师一样思考，而不只是像 LLM 集成人员那样思考。
总结
AI 代理安全 的核心是三件事：最小权限、正确的密钥管理，以及对高风险操作启用 human-in-the-loop。如果你从一开始就限制 scope、让模型看不到密钥、加入审批和审计，那么 AI 会成为团队的加速器，而不是新的事故来源。
如果你计划把 AI 代理接入 CRM、客服或内部流程 - 联系我们。
常见问题
从安全角度看，AI 代理和普通聊天机器人有什么区别？
AI 代理通常不只是回答，它还会执行。 它能调用工具、读取数据库、修改记录、发送邮件、触发操作。因此风险不只是“回答错了”，而是“在真实系统里做错了事情”。
如果只是内部工具，可以给代理管理员权限吗？
通常不建议。 内部使用并不能消除误操作、泄露或错误调用工具的风险。即使是内部代理，也更适合使用独立服务账号、尽量 read-only、并只给非常窄的写权限。
代理工具的 API key 应该放在哪里？
放在 secret manager 或受保护的环境变量中。 不要放在系统提示词、markdown 文档、源代码或普通日志里。模型只负责调用工具，密钥应在模型上下文之外注入。
每一个代理动作都需要 human-in-the-loop 吗？
不需要。 搜索、草稿、分类和低风险分析通常可以自动完成。但对外消息、金钱相关操作、数据删除、状态修改和服务器命令，人工确认会安全得多。
如果密钥已经出现在日志或提示词里了，该怎么办？
按已泄露处理。 立即吊销或轮换该密钥，从日志和仓库中清除，检查相关系统，并修复根因，比如提示词模板、日志器、测试文件或开发流程中的问题。