AI Agent 权限蔓延：无人审计的授权债

在试点项目结束六个月后，你的客户数据智能体仍然拥有对生产数据库的写入权限，而它自第一周以来就没再触碰过这些数据库。没有人恶意授予这种访问权限，但也没有人将其撤销。这就是 AI 智能体权限蔓延 (AI agent permission creep)，它现在已成为生产级智能体系统中授权失败的首要原因。

这种模式显而易见：智能体最初拥有一套最小权限集，随着集成的扩展（“只为这个工作流添加 Salesforce 的读取权限”），部署后的权限收紧步骤被无限期推迟。与人类身份与访问管理 (IAM) 中至少在名义上强制执行的季度访问审查不同，智能体身份完全处于大多数组织访问审查流程之外。《2026 年企业基础设施安全中的 AI 现状报告》（调查对象为 205 位 CISO 和安全架构师）发现，70% 的组织授予 AI 系统的访问权限超过了同角色的员工。拥有过度特权 AI 的组织报告的安全事件发生率为 76%，而执行最小权限原则的团队仅为 17% —— 两者相差 4.5 倍。

为什么漂移是有方向性的

权限蔓延本质上是不对称的：更多的访问权限会自动累积；而减少访问权限则需要明确的决策。每次集成都会增加一个范围。没有人会为了移除六个月前的范围而专门写一张工单。

产生这种情况的组织压力是可预见的：

交付压力与“先授权、后收紧”的文化。 团队在发布压力下会预先提供广泛的访问权限，以确保智能体能处理所有预期的任务，并真心打算随后收紧权限。但由于缺乏强制触发机制，这种收紧从未发生。

工具链鸿沟。 大多数智能体框架并不原生强制执行工具层级的权限。工具运行时的权限与智能体进程相同，继承了所有凭据。当你给智能体“Jira 的访问权限”时，它获得的是整个 Jira 实例以及 Jira OAuth 应用配置的所有范围，而不是“在项目 ABC 中创建工单”的特定权限。

权责不明。 在大多数团队中，智能体并未分配给具体的人类所有者。当部署智能体的人员调岗或离职时，智能体仍带着既定权限继续运行。这里没有直接责任人 (DRI) 的交接触发器，也没有注销清单。

OAuth 的增量授权机制。 应用程序可以随时请求额外的范围，并弹出扩大权限的授权界面。已经信任该应用程序的用户往往会不加审视地批准。每一次授权都在无声无息中扩大了爆炸半径。

结果是可预见的。IBM 的 2025 年 AI 安全报告发现，13% 的组织已经遭受过 AI 模型或应用的泄露，而其中 97% 的被攻击者缺乏适当的 AI 访问控制。在 2024 年至 2025 年间，涉及智能体的泄露事件同比增长了 340%。

你未曾预料的授权绕过

最隐蔽的权限蔓延形式并不是智能体拥有臃肿的权限列表，而是智能体被用作授权绕过路径。

2025 年记录的一起事件：某科技公司的营销分析智能体被授予了广泛的客户数据读取权限。一名权限受到明确限制的新入职员工通过该智能体请求了客户流失分析。智能体返回了该员工无法直接访问的敏感客户数据。没有配置错误，也没有违反策略。被用于数据访问决策的是智能体的身份，而非员工的身份。

这就是实践中的 OWASP LLM06:2025 “过度代理 (Excessive Agency)”。智能体对于其合法工作流拥有正确的权限。但由于这些权限超过了任何单个用户应有的权限，且智能体未应用请求用户的授权上下文，它变成了一条提权路径。下游系统根据智能体的身份授权了请求，而该身份的访问权限远高于发出请求的人类。

修复方案并非全局移除智能体的访问权限，而是在正确的层级强制执行授权。操作应在用户的上下文下以最小权限运行，而不是使用通用的高特权智能体身份。在 LangGraph 等框架中，这意味着在创建时将用户身份绑定在工具闭包中（而不是作为 LLM 可访问的参数传递），并依靠数据库层的行级安全性 (RLS) 作为最终防线。

孤立权限的审计方法论

在平均的企业环境中，非人类身份 (NHI) 的数量已达到人类身份的 82:1。97% 的 NHI 带有过度特权。审计数据显示，只有 38% 的 NHI 在过去九个月内处于活跃状态 —— 这意味着绝大多数既定权限属于无人使用的集成。

实际审计分为四个阶段：

发现与分类。 找出所有连接的应用程序和智能体身份。重点清查自主智能体（它们比被动 OAuth 集成具有更高的风险）。优先处理未经验证或没有正式治理记录的身份。在典型的企业环境中，一次发现行动识别出了 101 个 AI 智能体 —— 43 个高风险，71 个需要审查，2 个完全没有正式记录。

权限映射。 可视化范围风险 —— 特别留意读写权限，如 mail.readwrite 或 files.readwrite.all。追踪最初授权每个集成的人类用户，以及该人员是否仍在组织内。由离职员工授权且没有撤销触发器的令牌是典型的孤立权限。

历史使用分析。 针对每对“智能体-工具”组合，检查其最后一次针对生产环境运行的时间。90 天内未被调用的工具应考虑撤销权限。自试点以来从未被调用的工具几乎肯定可以安全移除。这与应用于人类角色认证的逻辑一致：“此人当前的岗位是否仍需要此访问权限？”

审查生命周期。 实施循环节奏：每周进行范围映射审查，每两周撤销陈旧集成的令牌，每月刷新库存。这并不罕见 —— 这正是应用于人类 IAM 的那套规范，只是为了适应智能体身份更快的漂移速度而进行了调整。

即时功能置备

长期权限是问题的根源。结构化的解决方案是临时性的、任务作用域的凭据——在需要时置备，在任务完成时自动撤销。

智能体的核心 JIT 模式如下：

1. 智能体针对特定工具和作用域请求权限提升
2. 授权策略根据上下文（任务类型、请求用户、时间窗口）评估请求
3. 授予具有短 TTL（生存时间）的访问权限
4. 在受限凭据下执行任务
5. 凭据自动过期；审计日志记录完整的交互过程

修复工作流中的一个具体例子：监控智能体检测到配置错误的云存储桶。策略智能体验证该违规行为。修复智能体请求针对该特定存储桶的临时写入权限。获得批准后，写入权限仅授予用于修复，随后自动撤销。链条中的每个智能体仅拥有该特定操作所需的权限。

对于基于 OAuth 工具访问的智能体（大多数生产部署），这直接对应于作用域限定为特定操作的短期 OAuth 令牌——例如 tickets:create 而非 jira:all，且仅在工作流持续期间有效。MCP 授权规范（2026 年 4 月更新）通过资源指示器 (RFC 8707) 使其正式化，确保令牌明确声明其预期接收者，防止令牌在不同 MCP 服务器之间被滥用。

JIT 模型还解决了授权绕过问题。如果智能体必须为每次操作请求受限的短期凭据，而不是持有长期访问权限，那么请求用户的上下文可以在请求时纳入授权决策，而不仅仅是在智能体部署时进行一次性决策。

智能体授权需要季度审查

访问审查的类比非常精准：每个智能体身份都应该有一个指定的人类负责人和一个所属团队。当负责人离职时，该智能体将被标记，并对其权限进行审查——这与服务账号的 DRI（直接责任人）交接相同。智能体权限应与人类角色一起纳入季度权限审查。

ISACA 在 2025 年的分析指出了传统 IAM 在结构上对智能体失效的原因：静态权限无法反映每个任务的上下文；遗留系统无法表示智能体生成子智能体的委托链；缺乏针对瞬时智能体凭据的实时撤销基础设施。这些是工程问题，而非组织问题——它们需要专门构建的工具。

但组织纪律是前提条件。在实施 JIT 置备或实时撤销之前，必须有人拥有每个智能体身份，并对其实施的权限范围负责。只有 21% 的组织拥有成熟的智能体治理模型。78% 的组织没有关于创建或删除 AI 身份的正式政策。

智能体的访问审查模板与人类的类似：

• 该智能体是否仍有活跃的负责人？
• 所有授予的工具作用域是否仍在生产环境中行使？
• 权限范围是否与当前工作流成比例，还是反映了试点阶段的要求？
• 智能体身份是否已纳入安全事件审查流程？
• 凭据是否按定义的计划进行轮换？

当审查员判定智能体的访问权限不再合适时，它将通过与人类权限决策相同的工作流被撤销，而不是通过单独的流程或一次性的 Slack 请求。

工具权限的正确粒度

“访问 Jira”不是一种权限。一种权限应该是：“在项目 ABC 中创建工单，字段：{摘要, 描述, 严重程度}，严重程度限制为 {S1, S2, S3}，速率限制为每分钟 5 个工单。”

这种“任务 + 资源 + 操作 + 约束”模型正是 OWASP 所指的“功能最小化”：扩展程序应仅包含合法功能所需的特定能力。受损或行为异常的智能体的爆炸半径受其工具权限的具体程度限制。

在实践中，这意味着：

• 为智能体可以调用的每个工具定义工具访问契约：允许的操作、允许的资源、允许的作用域、所需的上下文参数、速率限制、副作用分类以及回滚预期。
• 实施分级遏制而非二元化的允许/拒绝：降级为只读、禁用特定的高风险工具、沙箱模式（仅限提案）、隔离（位于明确的批准门禁之后）、强制停止。行为异常的智能体不需要被销毁，而是需要被降级。
• 在下游系统中强制执行授权，而不是在 LLM 本身。模型不是安全边界，被调用的 API 才是安全边界。

对于多智能体架构和基于 MCP 的部署，OPA（开放策略代理）网关模式提供了策略即代码的强制执行：每个请求在执行前都经过验证和授权，删除操作被明确阻止，并且操作在带有强制清理机制的短期隔离环境中执行。

智能体扩张的复合风险

该问题的最后一个维度是速度。人类身份的扩张积累缓慢——通过角色变更、团队转移、项目交接。而智能体身份的扩张可能瞬间爆发。企业级的一个 OAuth 授权可以同时在多个服务中创建多个令牌，每个令牌都持有长期访问权限，直到被明确撤销。

Drift-Salesforce 事件（2025 年 8 月）说明了其爆炸半径：从单个集成中窃取的 OAuth 令牌提供了对 700 多个客户环境的访问权限。这些令牌在标准安全控制之外运行——绕过了 SSO、MFA 和 CASB——因为它们依赖于委托授权而非交互式登录。次年的一次 MCP 服务器暴露事件发现，492 台服务器暴露在互联网上且无需任何身份验证，过度授权的凭据以明文形式存在于配置文件中。

在机器身份与人类身份比例达到 82:1 的情况下，单个配置错误的智能体令牌所产生的攻击面在类别上远大于受损的人类凭据。授权纪律需要与此规模相匹配。

答案不是放慢智能体部署的速度。而是将智能体身份纳入与人类身份同等的一等公民授权处理——季度审查、JIT 置备、指定负责人、自动撤销触发器——并在工具级别而非仅仅在智能体级别执行最小特权原则。