智能体凭据爆炸半径：你的 IAM 模型从未列举的主体类别

安全部门花了十年时间才彻底终结了“全能服务账号”。分限令牌、短期凭据、JIT 访问、逐操作审计——这整套最小权限方案终于落地并稳固下来。然而，AI 团队接入了一个智能体，提示词要求提供工具目录，于是工程师请求了平台所能发放的最广泛的 OAuth 作用域。已被弃用的模式换了一身新衣服又回来了，而这次调用 API 的主体是一个没人确定该如何限定作用域的随机循环。

这个智能体拥有日历、文件存储、CRM 和部署流水线的读写权限，因为 API 表面无法预先枚举。令牌是长效的，因为没人接入刷新路径。审计日志记录的是持有者，而非具体操作。IAM 负责管理人类和服务的身份，平台团队负责工作负载身份，AI 团队负责智能体的实际权限，而这三方集合的交集却无人管辖。

这并非假设。在生产环境中，机器身份的数量现在大约是人类身份的 82 比 1，且 92% 的云身份运行时拥有的权限从未被行使过。Gartner 预测，到 2028 年，四分之一的企业违约事件将追溯到 AI 智能体滥用，这并非对新型攻击类别的预测——而是对过去十年已经学会预防的每一起特权账号事件的重演，只不过换了一个 IAM 模型从未枚举过的新主体类别。

工具让请求权限变得容易

智能体发布时权限过大的原因平淡得令人沮丧：工具让粗粒度权限变得容易，而细粒度权限变得困难。当你启动一个新的工具集成时，SDK 会问“你想要哪些作用域？”平台暴露的作用域集是每个消费者可能需要的并集——例如 calendar.events.readwrite 而不是 calendar.events.create_for_meeting_id_X。工程师勾选了覆盖智能体在每个可能的会话中可能尝试的所有合理操作的复选框，因为在运行时构建渐进式授权流，谁都没有这个预算。

模型随后就在那个范围内运行。提示词说“安排会议”；但凭据完全可以同样轻易地删除整个日历。在“智能体被要求做的事”与“智能体能做的事”之间，只隔着一个提示词。当有一天一封带有恶意负载的邮件、一个恶意搜索结果或一个敌对 HTML 负载引导智能体偏离任务时，凭据的爆炸半径是原始作用域授予的所有操作的并集——而不是用户真正想要的操作。

定义了 2025 年末的 Salesloft–Drift 泄露事件是这个故事的最坏情况：一个 OAuth 令牌授予了第三方集成访问数百个下游环境的权限，一次沦陷，处处可用。那里的模式并不新奇。它与 AI 团队今天发布的模式完全相同，只不过被生产环境中的智能体数量放大了。

针对工具的作用域划分，而非针对智能体

首先要落地的纪律是旧版 IAM 模型已经深谙、但智能体 IAM 模型仍在假装可以避免的：将凭据的作用域限定在操作上，而不是主体上。一个“日历智能体”不需要日历权限；create_meeting 调用需要 calendar.events.create，list_attendees 调用需要 calendar.events.read，这些应该是从两个不同的短期授权中铸造出的两个不同的令牌。

MCP 授权规范在 2025 年末朝着这个方向演进——服务器现在可以通过 WWW-Authenticate 标头声明每个作用域的要求，而客户端应使用 Step-Up 授权流，仅在工具确实需要时才请求额外的作用域。这一规范变更在有线格式上承认了在会话开始时将所有作用域捆绑进单个令牌从一开始就是错误的。目前的实现工作——即那些真正执行 Step-Up 而不是在会话开始时请求所有可能作用域并集的客户端——在很大程度上仍有待行业普及。

实际做法：枚举你的智能体拥有的工具，写下每个工具所需的 最小 作用域，并将任何作用域宽于其操作的工具视为凭据 Bug。如果你的工具描述说“发送电子邮件”而 OAuth 作用域授予了 mail.read，那么无论智能体是否行使过读取权限，你都遇到了凭据 Bug。

绑定到操作的即时凭据

针对工具的作用域划分缩小了跨工具的爆炸半径。JIT 凭据则缩短了跨时间的爆炸半径。其纪律与云原生工作负载身份已经为人类和服务调用者强制执行的一致：不要预先配置长效凭据；在使用的瞬间铸造短期凭据，并将其作用域限定在智能体即将执行的特定操作上。

一个可行的方案：当智能体决定调用工具时，运行时拦截该调用，将操作提交给凭据代理（Vault、内部 STS 或类似 AWS IAM Roles Anywhere 的托管服务），并收回一个在接下来的 60 秒内有效、且作用域限定在智能体即将接触的资源 ID 上的令牌。该令牌在下一次工具调用前过期，且无法针对不同的资源进行重放。智能体持有的凭据有效期绝不会超过单次工具调用。

这是一个有意义的工程投资——这也正是 HashiCorp Vault、AWS IAM 和 Azure 托管身份十年来一直努力的方向。智能体运行时是现有模式的一个新客户端，而不是一个需要发明的新模式。那些在这方面拖延的团队仍在将 OpenAI API 密钥粘贴到 .env 文件中；而那些付诸实践的团队则获得了一个生命周期与操作生命周期匹配的凭据，其爆炸半径被限制在模型在 60 秒内针对单个资源 ID 所能完成的合理操作之内。

审计日志记录的是令牌，而不是操作

一种更隐蔽的失败模式：即使凭据限定了作用域，审计日志通常也没有。IAM 平台会记录 “agent-X-token 在 14:32:11 调用了 calendar.events”；而它应该记录的是 “agent-X 代表用户-Y，在会话-Z 中，根据提示词-P，调用了 cancel_meeting，参数为 {meeting_id: 12345}，该操作未经人工批准，是由一封入境邮件的内容触发的”。第一条记录只能告诉你使用了某个令牌，而第二条记录才能告诉你该用途是否合法。

之所以这一点至关重要，是因为智能体事故看起来与传统的凭据事故并不相同。凭据并没有被盗取；它是被一个受上游内容引导而偏离任务的智能体按设计正常使用的。检测信号不是 “一个未经授权的方持有此令牌”，而是 “该智能体采取了任何人类都没有要求的行动”。如果没有针对每个动作的溯源追踪——提示词、来源内容、工具、参数、原始用户——安全团队就无法区分这两者。事故响应手册将以 “我们撤销了令牌” 开始，以 “我们不知道智能体用它做了什么” 结束。

如果能在设计初期就考虑到这一点，将这种溯源能力构建到审计流水线中的成本是很小的；但如果在第一次事故发生后再补救，成本将非常巨大。那些现在就制定这项规范的团队——在每一行审计记录中命名操作、提示词、来源和用户——将是在 18 个月后无需编写复盘报告的团队。

异常工具调用以及智能体无法触发的撤销路径

第四项规范与传统的入侵检测最为相似，但有一个关键的转变：不能指望智能体本身来检测其自身凭据的异常使用。一个被入侵的智能体——无论是受到间接提示词注入的影响，还是其系统提示词本身就是攻击的一部分——都没有动机也没有能力标记自己的行为。检测必须存在于智能体之外。

这种模式正是工作负载身份（workload identity）厂商趋于一致的做法：为每个智能体建立行为基准（它使用哪些工具，按什么顺序，针对什么资源类型，以什么频率），并在实时行为发生偏离时触发自动撤销路径。一个客服智能体在处理支持队列中的工单时调用了 1000 次 send_email 是正常的，但如果它现在针对整个客户数据库调用 send_email，这种偏差会被针对智能体的基准检测捕捉到，而针对工具的作用域检查则无法发现。

撤销路径是 AI 团队几乎总是忘记连接的部分。凭据经纪人必须支持立即作废令牌，智能体运行时必须优雅地处理随之而来的 401 错误（而不是用新令牌静默重试），值班频道必须接收到带有足够上下文的告警，以便人类做出判断。端到端连接好这一环节的团队可以在几秒钟内隔离行为异常的智能体；而没做这一点的团队将从客户那里得知事故。

谁负责这种连接（The Join）

这个故事中最难的部分不是技术，而是组织架构。IAM 负责人类身份和服务账户身份。平台团队负责普通服务的工作负载身份。AI 团队负责智能体运行时、提示词、工具目录，以及（默认情况下）智能体持有的凭据。这三者的并集就是智能体的有效权限表面，但在大多数组织中，没有一个单一的负责人能从端到端描述它。

解决方案不是成立一个新团队，而是为这种连接（the join）指定一个明确的负责人。无论该职能属于 IAM、平台团队，还是属于一个新的 “智能体身份” 职能部门，都取决于组织架构，但必须存在这样一个文档：列出智能体的名称、它可以调用的工具、每个工具解析出的凭据、每个凭据的作用域、每个凭据的有效期、审计目的地以及撤销路径。一个无法为生产环境中的智能体提供该文档的团队，实际上是在发布一个爆炸半径无限大的产品，并称之为“功能”。

在第一次事故发生前应该构建什么

智能体身份的故事将由第一代公共事故来定义——为 “完成我的工作” 而生成的凭据被用于 “提取客户表数据”，而审计日志中没有人能说清哪个提示词引导了哪个工具访问了哪个资源。那些正在编写复盘报告的团队是将智能体凭据视为旧服务账户模式的重构；而那些在复盘报告中编写 “建议” 的团队，则是将智能体视为具有自身身份模型的新主体类别（principal class）。

具体来说，在下一个智能体上线之前：

• 枚举工具目录和每个工具的最小作用域。 将任何凭据范围超过其操作需求的工具视为 Bug。
• 在工具调用时生成凭据，而不是在会话开始时。 签发 60 秒有效期的令牌，作用域限定在模型即将触及的资源 ID 上。
• 记录操作、提示词、来源内容和发起用户——而不仅仅是令牌。 令牌级的审计日志无法回答复盘报告中将提出的问题。
• 构建智能体无法触发的撤销路径。 针对每个智能体的行为基准、偏离时的自动隔离以及人类可读的告警。
• 指定负责 IAM、平台身份和智能体权限之间连接的负责人。 一份文档，一个签字确认，一个名字。

智能体是一种新的主体类别。组织花费十年时间加固的 IAM 模型是为那些不会随提示词漂移、不会以工程师从未想象过的方式组合工具调用、且攻击面不包括模型被要求阅读的任何文档的主体而编写的。那些将智能体视为旧模型重构的团队正在为自己买下一场全行业即将共同承担的事故。而那些将智能体视为新模型——拥有自己的作用域词汇表、凭据寿命、审计形式和负责人——的团队，将在复盘报告开始大量出现时依然保持稳健。