Agent 身份与最小权限授权：你的 AI 团队正在忽视的安全隐患

大多数 AI Agent 架构都存在一个悄无声息的安全问题，直到出了事才会被发现。你构建了 Agent，用应用现有的服务账户凭证将其接入内部 API，上线生产，然后继续下一个任务。Agent 正常运行，用户很满意。而与此同时，在你的审计日志里，一个服务账户身份正在悄悄触碰 Agent 曾经需要访问的每一条客户记录、每一张账单表和每一份内部文档——却没有任何痕迹说明是哪个用户发起了什么请求，又是为什么。

这不是一个理论风险。当安全事件发生，或者当监管机构询问"3 月 14 日谁访问了这份数据"时，答案每次都一样：[email protected]。每一个操作、每一次请求、每一次读写——全部归结为同一个身份。审计记录在技术上是正确的，但在取证层面毫无用处。

服务账户陷阱

传统的服务间认证建立在一个静态关系上：服务 A 总是需要权限 Y 来完成工作。权限在初始化时被分配，在设置阶段被审查，之后很少被重新检视。当服务是确定性的时候，这个模型是有效的——一个读取发票、写入支付记录的账单服务，其操作范围是可预测且有边界的。

AI Agent 从三个维度打破了这一假设。

首先，Agent 具有涌现式访问模式。一个客服 Agent 今天可能需要读取 CRM 数据，但下周某个用户让它拉取趋势报告，它就开始查询数据分析仓库。随着你赋予 Agent 越来越多的能力，它可能触碰的数据范围也在不断扩大，初始的权限授予变得越来越过时。

其次，Agent 代表拥有不同权限级别的多个用户进行操作。一个市场分析师和一位 C 级高管可能使用同一个 Agent，但他们在你的系统中拥有截然不同的数据访问权限。当两者都通过同一个服务账户路由时，Agent 的权限就变成了所有用户权限的并集——或者更糟糕的是，与用户权限完全脱钩，仅反映服务账户被预配置时的权限。

第三，Agent 容易受到提示注入攻击。恶意用户、检索语料库中被污染的文档，或被篡改的工具响应，都可以将 Agent 引向其原始设计者从未预期的操作。当 Agent 的凭证权限宽泛时，一次成功的提示注入所造成的破坏范围与权限成正比，而非与意图成正比。

2024 年 Palo Alto Networks 的"Double Agents"研究在 GCP Vertex AI 中具体揭示了这一问题：继承了过于宽泛服务账户权限的 Agent，让研究人员得以从受限的消费者项目横向移动到基础设施层资源，访问了与 Agent 任务毫无关联的源代码和容器镜像。这是架构层面的弱点，而非模型失败——权限的生命周期超出了 Agent 合理需求的任何定义。

生产级 Agent 身份的正确形态

正确的思维模型不是"给 Agent 一个身份，然后限制它能用这个身份做什么"，而是"只给 Agent 执行当前特定任务所需的身份"。

按任务颁发的临时凭证是这一理念的实际落地方式。Agent 不再使用长期有效的 API 密钥运行，而是由密钥管理系统（AWS STS、GCP 服务账户模拟、带有短 TTL 租约的 HashiCorp Vault）颁发临时凭证，其作用域精确限定于当前特定任务所需的权限，有效期以分钟计。任务完成后，凭证过期。没有可供窃取的常驻访问权限。

Okta 2025 年的安全基准测量了这一方案的效果：使用短期令牌（有效期 300 秒以内）的组织，与使用 24 小时会话的组织相比，凭证被盗事件减少了 92%。当凭证动态颁发并自动过期时，轮换的运维开销便烟消云散了。

基于 SPIFFE 的工作负载身份将这一方案推进了一步。每个 Agent 实例都获得一个具有短 TTL 的可加密验证身份证书，与特定的工作负载和任务上下文绑定。证书编码的不仅是"这是 AI Agent 服务"，还包括"这是 Agent 实例 X，正在执行任务 Y，代表用户 Z"。这个身份贯穿每一次下游 API 调用，让审计日志真正有意义。

双重身份编码问题

当 Agent 代表用户执行操作时，下游系统需要了解两件事：是谁授权了这个操作（真实用户），以及是什么系统执行了它（Agent）。这就是主体层级问题，大多数实现对此处理得很糟糕。

最简单的做法：Agent 使用自己的服务账户调用 API，用户身份被记录在某个应用层日志里。这破坏了取证能力——API 原生的审计记录显示的是 Agent 而非用户，重建完整调用链需要跨系统关联日志。

IETF 有一份草案规范（On-Behalf-Of User Authorization for AI Agents）对此进行了形式化定义。该模式使用令牌交换：用户的会话令牌被换成一个新令牌，该令牌在同一个凭证中同时编码了用户身份和 Agent 身份。下游 API 看到的令牌表明"这是用户 Alice，由 agent-v2 代表，该 Agent 被授予了这些特定作用域"。撤销机制也很清晰——使 Alice 的会话失效，同时也使 Agent 代表她行动的能力失效。

在实践中，这对应于 OAuth 2.0 实现中的 On-Behalf-Of（OBO）流程。关键要求是：Agent 的令牌绝不能拥有比它所代表的用户更广泛的权限。如果 Alice 无法读取薪资数据，代表 Alice 行动的 Agent 就不能读取薪资数据，无论 Agent 自己的服务账户能访问什么。这一"委托而非放大"的原则，是区分正确作用域的 Agent 与授权绕过向量的关键所在。

真正有效的审计记录

当每个 Agent 操作都携带正确的双重身份凭证时，审计日志才真正有用。你看到的将不再是：

2026-03-14 14:32:01  [email protected]  READ  customers/record/9821
2026-03-14 14:32:02  [email protected]  READ  customers/record/9822

而是：

2026-03-14 14:32:01  user:[email protected] via agent:support-v2 task:ticket-12847  READ  customers/record/9821

这个差异不只是形式上的。当审计员或事件响应人员询问"3 月 14 日谁访问了客户记录 9821"时，第一份日志需要另行调查支持 Agent 在 14:32 在做什么以及是谁触发了它。第二份日志直接给出了答案。

这一点在欧盟《人工智能法》（法规 2024/1689）背景下尤为重要，该法规要求自 2026 年 8 月起对高风险 AI 系统自动记录事件。在一个使用共享服务账户的系统上事后构建完善的审计记录是痛苦的——需要在整个技术栈的每一层都进行埋点。而从一开始就正确构建，只需要在凭证层实现正确的身份传播。

分阶段授权作为安全层

即使拥有了正确作用域的凭证，Agent 也能从与任务风险相匹配的分阶段访问模型中受益。

第一阶段：只读观察。Agent 可以查询任何所需数据，但不能写入、修改或触发操作。适用于研究 Agent、报告生成和分析任务。

第二阶段：仅起草，需人工审批。Agent 可以提议操作——一封草稿邮件、一个日历变更提案、一个待执行的查询——但这些操作在人工确认前不会执行。此阶段的凭证包括读取权限，以及对"草稿"命名空间的写入权限，对正式系统没有任何写入权限。

第三阶段：在监督下执行，具有限定写入权限。Agent 可以在严格定义的范围内执行有限的真实操作（发送消息、创建工单）。凭证是针对特定任务的，在操作完成后立即过期。

授权升级路径在每个阶段都应要求明确的理由，系统应默认使用能够满足用户明确意图的最严格阶段。大多数 Agent 任务不需要第三阶段，但大多数团队一开始就从那里着手，因为这样更简单。

爆炸半径公式

评估当前授权设置的一个有用方法：爆炸半径 = 访问范围 × 操作速度 × 检测窗口。

访问范围是 Agent 凭证能触碰到你系统的多少部分。操作速度是 Agent 每分钟执行多少操作。检测窗口是从安全事件发生到被发现需要多长时间。

宽泛的服务账户最大化了范围。自主 Agent 最大化了速度。共享凭证和薄弱的审计记录最大化了检测窗口。三者的乘积决定了事后复盘讨论的惨烈程度。

临时凭证同时缩减了范围并压缩了检测窗口——一个被泄露的凭证在能被系统性利用之前就过期了，而严格的作用域限制了攻击者在那个窗口内能触达的内容。这不是教科书意义上的纵深防御；这是你能对任何生产 AI 系统的授权架构做出的、投入产出比最高的单一改变。

从哪里开始

如果你继承了一个已经使用共享服务账户的 Agent 系统，迁移路径有一个自然的顺序：

1. 审计服务账户实际能访问什么。 大多数团队都会对其范围感到震惊。云提供商的 IAM 分析器会自动发现未使用的权限。

2. 在更改凭证之前，先将任务级别的身份上下文添加到你的现有日志中。 现在就建立审计记录，这样你就可以比较变更前后的行为。

3. 在基础设施层迁移到短期令牌。 这不需要修改 Agent 代码——这是 Agent 运行时部署方式中的凭证供应变更。

4. 如果你的 Agent 代表特定用户行动，则实现用户委托。 这就是 OBO 模式，需要在认证层进行令牌交换，但这是获得用户发起的 Agent 操作有意义审计记录的唯一途径。

5. 定义与 Agent 实际任务配置相匹配的分阶段授权层级。 默认推向第一阶段；要求经过深思熟虑后才能升级到第三阶段。

那些造成最严重安全事件的 Agent，不是那些使用了巧妙提示注入或复杂攻击手段的。而是那些拥有无限制访问权限、自主运行了数月、然后在安全事件取证中被发现的——当调查人员问"这个服务账户还做了什么"时，答案是"一切"。

---

你为 Agent 选择的身份模型是一个产品决策，不仅仅是安全决策。它决定了你的审计日志是否有用，你的权限模型在遭受攻击时是否能优雅降级，以及一个糟糕的提示或恶意文档是否能将你的 Agent 变成一个拥有全系统凭证的内部威胁。大多数团队把这个决策推迟到出问题之后再说。那些做对的团队在需要之前就构建了正确的作用域——因为在一个运行中的生产系统上事后改造授权机制，比从一开始就正确设计要难上一个数量级。