权限漂移，指的是 AI Agent 在长期运行中慢慢拥有了比团队原本预期更大的能力。它通常不是从一次明显事故开始的。更常见的情况是：客服 Agent 多拿了一个 CRM 字段，浏览器 Agent 的 allowlist 放宽了一点，某个工具 schema 增加了导出参数，临时事故权限没有回收，测试凭证上线后还活着。每个变化单独看都说得过去，但叠加之后，Agent 可能已经从受控自动化变成了可以读取过多数据、发送过多内容，或绕过原本承诺审批的系统。
这是生产环境里很常见的问题，因为 AI Agent 夹在产品工作流和安全策略之间。产品团队会不断增加能力，因为用户希望减少人工交接。工程团队会加工具，因为旧流程太手工。支持团队会要求更多上下文，因为半截答案会让用户不满。这些都不是错。真正的风险是，权限变化往往比权限复查流程走得更快。
这份清单适合已经进入 pilot 或生产阶段的团队。建议每月使用一次；每次重大工具变更后使用一次；Agent 扩展到新客户群前使用一次；当 Agent 从只读辅助走向写入型工作流执行时，也应该完整复查。
1. 从权限基线开始
不要凭记忆做审查。先拉出真实基线：工具列表、OAuth scope、service account 角色、数据库权限、浏览器 origin、文件存储访问、队列权限、外发目的地、审批规则和租户边界。基线应该说明 Agent 被允许读取、转换、写入、发送、删除、购买、发布或执行什么。
最实用的格式是四列清单：能力、负责人、当前范围、审批要求。如果团队不能快速拿出这份清单，本身就是一个发现项。生产 Agent 不应该依赖某个工程师记得哪一个凭证或工作流设置控制了高风险动作。
2. 对比声明权限和运行时现实
很多团队文档里是一套权限模型，实际运行时是另一套。README 说 Agent 只能起草回复，但集成 token 可以直接发送消息。策略说导出需要审批，但工具接受导出参数且不要求 reviewer。工作流说 Agent 按租户隔离，但日志显示跨租户搜索结果进入了 prompt context。
审查时看运行证据，而不只看配置页面。查看最近的工具调用、审批日志、浏览器 trace、API 审计日志和失败尝试。问题不是“我们原本想怎样”，而是“上周 Agent 实际能做什么”。
3. 检查工具 schema 增长
工具 schema 很容易变大。一个无害的查询工具可能增加更新字段。一个工单工具可能增加分配、打标签和关闭动作。文档工具可能增加导出和分享选项。邮件工具可能从批准的内部队列变成任意收件人。这些小变化，是权限漂移进入 Agent 系统最常见的路径之一。
把当前工具 schema 和上一次批准版本做 diff。重点看新增写入参数、自由文本目的地、文件附件、批量动作、管理员字段，以及为了某个客户加入的“高级”选项。任何新的动作类别，都应该触发审批、日志、测试和回滚复查。
4. 重新审查审批边界
审批常见两种漂移。第一，团队因为早期用户抱怨流程慢而减少审批。第二，审批还在界面里，但已经失去了做真实判断所需的上下文。reviewer 可能只看到“approve response”，却看不到来源记录、外发目的地、客户层级、命中的策略规则或将被发送的数据。
抽查最近二十个高风险动作审批。reviewer 能否在三十秒内理解业务影响？能否编辑、拒绝或升级？审批发生在动作之前，还是只是事后记录？如果审批界面已经变成盖章动作，即使 checkbox 仍在，边界也已经漂移。
5. 找出陈旧的临时权限
临时权限是最稳定的漂移来源之一。事故、演示、迁移和客户 onboarding 期间，团队会为了推进工作放宽权限。问题不在于紧急变更，而在于紧急状态结束后没有回收。
搜索名称中包含 test、temporary、migration、demo、backfill、support override、incident、beta 或 admin 的权限授予。检查 service account、API key、feature flag、allowlist、浏览器 profile、队列和内部工具。每个临时授权都应该有负责人、原因、过期时间和移除证据。
6. 审查数据移动路径
只检查读取权限是不完整的。很多 Agent 事故真正发生在数据移动阶段。Agent 可能需要读取客户记录用于支持，但这不等于它可以把数据粘到浏览器表单、通过邮件发送、附加到工单、写进公开 issue，或存入长期 memory。
追踪 Agent 读取敏感数据之后，这些数据可以流向哪里。包括工具输出、生成草稿、日志、trace、分析事件、支持备注、导出文件、截图、下载文件和 memory store。如果 Agent 可以把数据移动到新目的地，这个目的地就需要自己的策略检查和测试用例。
7. 区分租户扩展和功能扩展
一个 Agent 对某个客户群安全，不代表对另一个客户群也安全。内部用户、小规模 pilot、企业租户、受监管客户和管理员工作流，风险画像并不一样。权限漂移常发生在一个为窄范围人群设计的能力，被扩展到更广泛人群时，却没有重新审查。
列出哪些租户、套餐、角色、地区和工作流可以使用每个 Agent 能力。然后和最初的上线决策对比。如果某项能力从内部 beta 进入所有客户，或从只读客户扩展到生产管理员，就把它当成一次新上线，而不是例行发布。
8. 测试负向路径，而不只是正常路径
如果测试只确认正常任务还能工作，权限漂移很难被发现。增加一组测试，要求 Agent 超出当前权限：把数据发到新地址、跳过审批、更新受限字段、搜索另一个租户、导出批量文件、使用 allowlist 外的浏览器页面、调用管理员工具，或把敏感细节记住供未来使用。
每个测试都应该有预期结果：拒绝、脱敏、请求审批、停止或升级。工具、prompt、模型、权限和客户群变化后都要重新运行。当一个负向测试开始像正常任务一样通过时，权限漂移已经发生。
9. 在日志里寻找静默边界跨越
日志可以在用户报告之前暴露漂移。关注被阻止的工具调用、反复被拒绝的审批、参数异常宽泛的工具调用、跨租户搜索尝试、大型导出、外部目的地、高风险浏览器点击，以及敏感字段出现在生成内容中。这些信号不一定代表已经造成伤害，但说明边界正在承受压力。
好的日志记录策略决策，而不只是最终动作。审查者应该能看到 Agent 试图做什么、命中了哪条规则、涉及什么数据、是否经过审批、最终结果是什么。没有这条 trace，权限漂移会藏在看起来成功的自动化里。
10. 给每个高风险能力指定负责人
没有负责人的权限会自然腐化。每个工具、凭证、宽 scope、外发目的地、memory store 和审批例外，都应该有明确的业务或工程负责人。负责人需要判断该能力是否仍然必要、当前范围是否过宽、测试是否仍匹配风险。
这不需要变成庞大的治理流程。如果权限清单是最新的，证据容易阅读，每月三十分钟的复查就能抓住很多问题。关键是负责人审查真实使用情况，而不是只看静态配置列表。
最低审查包
一次实用的权限漂移审查，至少应把这些材料放在一起：当前权限清单、上次批准的权限清单、工具 schema diff、审批日志样本、敏感数据移动图、租户和角色暴露列表、负向测试结果、陈旧权限清理列表，以及负责人签字。如果买家问 Agent 上线后如何继续受控，这份材料比一句“我们遵循最小权限”更有说服力。
相关资源
- AI Agent 信任边界审查清单
- AI Agent 数据外泄防护清单
- AI Agent 工具权限清单
- OWASP Top 10 for Large Language Model Applications
- MITRE ATLAS
如果要做更完整的上线和上线后复查，可以使用 AI Agent 就绪度自评，或申请 AI Agent Readiness Audit。