Agent 正在成为 IAM 的新工作负载，而你的服务账号还没准备好

先把现有做法最有力的一面讲清楚，因为它并不愚蠢。过去二十年，服务账号和 API 密钥一直在承载机器工作负载。大家理解它们，它们能被审计，每一家云平台和 SaaS 工具都支持它们，安全团队甚至已经有一张表格专门记录这些账号。当有人说 Agent 需要一种新的身份类别时，一个合理的回应是：我们已经有了，叫做非人类身份，直接用就行。

但问题正是从这里开始。服务账号回答的是“哪个系统正在发起调用？”Agent 迫使我们回答一个更难的问题：“哪个 Agent 正在调用，它代表谁，正在追求什么目标，以及未来三十秒内谁能单独撤销它？”IAM 行业自己的数据表明，非人类身份的数量如今已经比人类身份高出一个数量级。2026 年 Verizon DBIR 也警告，随着 Agentic AI 到来，服务账号和机器账号将成为需要重点关注的对象，参见 Token Security 对该报告的解读。这篇文章要解释为什么旧的映射方式开始失效，行业正在构建什么来替代它，以及失败案例已经呈现出什么样子。

关键结论 - 服务账号和 API 密钥假设调用方稳定且具有确定性。Agent 是临时的、非确定性的，还会彼此委派任务，这会打破共享凭据原本依赖的审计、撤销和最小权限假设。 - 标准正在走向“每个 Agent 一个工作负载身份”：IETF WIMSE 工作组正在被推动要求 Agent 必须通过身份本身被区分，而不能只依赖 token scope，并使用类似 SPIFFE 的每 Agent 标识符作为策略、审计和撤销的稳定键。 - 事故已经非常具体：Salesloft Drift 生态中被攻破的 OAuth token 被用于横向进入企业 Salesforce 环境，而 Hugging Face 7 月的入侵由一个自主 Agent 从头到尾完成。 - 实施建议正在收敛：每个 Agent 拥有独立身份，短生命周期、任务级范围的凭据在模型上下文之外签发，审计轨迹绑定到具体 Agent，而不是共享角色。 - 如果你的所有 Agent 都使用同一个共享服务账号认证，那么日志无法告诉你究竟哪个 Agent 做了什么。这就是本周应该执行的测试。

发生了什么

8 月最初几周，两件事汇到了一起。第一，标准讨论开始变得具体。8 月 4 日提交的一项 IETF WIMSE 架构草案 issue 认为，草案目前关于 AI 中介者的措辞太弱：它允许通过“separate workload identities or token scopes”区分自主 Agent 的操作，但该 issue 指出 token scope 并不能解决身份问题。Scope 只能限制一个 token 可以做什么，却不会改变这个 token 代表谁。多个 Agent 共用同一份凭据时，无论 scope 如何不同，它们在审计日志、撤销系统和每 Agent 策略中仍然无法区分。提出的修复方式是：托管 Agent 平台应该给每个 Agent 分配一个唯一的工作负载标识符，通过专用 claim 携带，并把它作为策略、审计和撤销的稳定键。Google 的 Agent 身份设计被作为可行范例，其中每个已部署 Agent 都获得一个基于 SPIFFE、并与该 Agent 资源绑定的身份。

第二，事故仍在不断发生。7 月中旬的 Hugging Face 入侵 是首个公开披露、明确指向一家知名公司，并由自主 Agent 从头到尾执行的入侵：在数据集 pipeline 中执行代码、收集凭据、在内部集群之间横向移动，并在一个周末完成数千次操作。更早些时候，面向 AI Agent 的社交网络 Moltbook 在达到 150 万 Agent 账号后的几天内，就因为数据库配置错误泄露了 150 万个 API token，参见 Studio Global 的汇总。DBIR 反复引用的非人类身份攻击案例也具有同样的形态：Salesloft Drift 的 OAuth token 被攻破后，被用于进入 Google、Cisco、Zscaler 等大型企业的 Salesforce 环境。这正是 Agent 所依赖凭据面临的风险形态。

2026 年 8 月，一项 IETF WIMSE issue 提议，Agent 的操作必须通过独立工作负载身份来区分，而不是依赖 token scope，并把每 Agent 标识符作为策略、审计和撤销的稳定键。此前 7 月发生了 Hugging Face 的 Agent 驱动入侵，1 月则发生了 Moltbook Agent 平台泄露 150 万个 API token 的事件。

为什么服务账号和 API 密钥无法直接映射到 Agent

这种错配有四个不同侧面，值得分别说清楚，因为解决方案并不相同。

共享身份会摧毁归因能力。 服务账号的设计前提就是共享、静态和相对宽泛的权限。如果十个 Agent 共用一个账号，那么你的审计日志只会显示一个行为主体。正如 Cockroach Labs 的实践文章 所说，你无法判断哪个 Agent 访问了哪些数据，轮换凭据意味着必须协调所有 Agent，而账号权限最终会漂移成“任何 Agent 曾经需要过的全部权限”的并集。他们匿名化的案例和我从客户团队那里听到的不同版本非常相似：一个支持类 Agent 用某个账号运行了三个月，该账号拥有整个客户数据库的读取权限，开发阶段为了方便这样配置，上线前却从未收紧。

Agent 是临时的，密钥不是。 一个 Agentic workflow 可能在几秒内向模型提供商、向量数据库、三个 API 和云存储完成认证，然后就消失。长生命周期 API 密钥假设调用方持续存在，因此值得按计划轮换。两者错配会产生蔓延：给早已无人记得的 Agent 创建的密钥仍然有效，而且权限依然很宽。

委派会打断“代表谁”这条链。 代表用户行动的 Agent 和完全自主行动的 Agent，在策略引擎看来本应完全不同。使用共享服务账号后，两者看起来一模一样。OAuth 委派对于用户场景处理得还算合理；自主场景需要 Agent 自己的身份，而多 Agent 委派则要求每一次 hop 都收窄下游权限，而不是扩大权限。

模型永远不应该持有秘密。 这是结构问题，不是配置问题。只要凭据被放入上下文窗口，它们就对模型可见，也会暴露给任何能够操纵模型的输入。Prompt injection 可以借助 Agent 自己的输出把这些秘密带出去。正确做法是在任务执行时由 token service 签发短生命周期、范围受限的凭据，并由工具执行层持有，让模型能够触发调用，但秘密永远不进入模型上下文。Cockroach Labs 很好地解释了这一点，也与我给构建自托管 Agent 技术栈的客户提供的建议一致：Harness 持有密钥，模型持有意图。

共享服务账号会破坏 Agent 归因，因为日志中只剩一个行为主体；它们的生命周期比临时 Agent 工作负载更长；它们模糊用户委派行为与自主行为之间的边界；它们还会诱使团队把凭据传入模型上下文，让 prompt injection 有机会接触这些秘密。参见 Cockroach Labs 和 miniOrange 的对比。

厂商和标准机构正在构建什么

正在成形的架构大致有三层。令人鼓舞的是，厂商和标准社区正在向近似相同的模式收敛。

每个 Agent 一个工作负载身份。 前面的 WIMSE 方向就是标准化版本：每个逻辑 Agent 都获得一个唯一、稳定的标识符，建议形式是 SPIFFE URI，并与任何共享执行角色分离。策略、审计和撤销都以这个标识符为键。如果平台托管的多个 Agent 共用执行凭据，则需要额外增加每 Agent claim。最重要的变化就在这里：身份按 Agent 分配，而不是按 deployment 分配。

使用身份联合，而不是存储长期秘密。 Descope 关于 Agent 工作负载身份联合的说明 展示了这种模式：Agent 的平台身份，例如 AWS IAM role 或通过 IRSA 使用的 Kubernetes service account，被交换成身份平台签发的短生命周期、范围受限 token。身份平台还会为 Agent 创建一个目录记录，使审计轨迹能够在 token 过期后继续保留。没有长期密钥可以泄露，而身份记录的生命周期也超过任意一份具体凭据。

发现与治理正在成为一个市场。 商业层面，Reco、Token Security、Oasis、Aembit 等非人类身份厂商都在围绕 Agent 重新定位：发现所有 Agent 凭据，把它们映射到明确的所有者，标记过度授权，并能干净地撤销。Reco 的思路 很实用：根据 Agent 的角色选择身份类型，用户代理操作使用 delegated OAuth，自主操作使用独立 workload identity，并随着责任范围扩大持续审查权限，因为 Agent 会像员工积累办公室钥匙一样积累权限。OWASP 在 2025 年 12 月发布的 Top 10 for Agentic Applications 中，把 Identity and Privilege Abuse 列为一级风险类别，让安全团队能够用统一词汇描述审计问题。这一层最终应该落在你的整体技术栈哪里，既是 tooling 问题，也是治理问题。我在 AI Agent 治理中讨论了组织侧。

正在成形的架构包括：WIMSE 讨论提出的每 Agent workload identity，并使用类似 SPIFFE 的标识符作为策略、审计和撤销的键；Descope描述的平台身份联合到短生命周期 scoped token，并保留持久的 Agent 目录记录；以及围绕非人类身份发现和最小权限治理形成的厂商市场。

当 Agent 身份出问题时

三个事件，三种不同的失效模式，都值得研究。

Hugging Face，2026 年 7 月：攻击者的身份问题，也是防守方的身份问题。 这场由 Agent 执行的入侵从代码执行 worker 中获取云和集群凭据，然后进行横向移动。这是典型的过度授权工作负载故事：一个数据处理组件持有值得被窃取的凭据。较少被报道的细节是 Hugging Face 披露的取证不对称。攻击 Agent 不受任何使用政策约束，而公司自己的取证工作最初却被他们尝试使用的托管模型安全限制挡住。于是团队最终在自己的基础设施上运行 open-weight 模型 GLM 5.2 来进行取证分析。同一事件的攻防两端，都出现了身份和访问控制问题。

Salesloft Drift，DBIR 的警示：token 变成万能钥匙。 某个厂商生态中被攻破的 OAuth token 被用于横向进入大型企业的 Salesforce 环境。没有密码，没有针对人的钓鱼，只有受到广泛信任、被安静复用的非人类凭据。任何使用长期 OAuth grant 连接 SaaS 工具的 Agent 都具有同样的风险形态，对策也应该具有同样的形态：短生命周期、窄 scope、每 Agent 独立、可撤销。

Moltbook，2026 年 1 月：Agent 平台会聚合身份风险。 一个 Agent 账号平台因为数据库配置错误，泄露了 150 万个 API token，以及邮箱地址和 Agent 之间的消息，参见 Studio Global 的报道。当你集中管理 Agent 身份时，也同时集中其 blast radius。这里也值得说明，我会把流传中的部分事件细节视为“已报道”而不是“已审计确认”。Hugging Face 自己的披露属于一手来源，Moltbook 的数字则来自二手报道。

已有记录的 Agent 身份失败包括：2026 年 7 月 Hugging Face 入侵，自主 Agent 获取云和集群凭据后进行横向移动，参见 Waxell 分析；Salesloft Drift OAuth token 被用于进入企业 Salesforce tenant，参见 Token Security 对 2026 DBIR 的解读；以及 Moltbook 泄露 150 万个 Agent API token。

现在该做什么

1. 本周：盘点所有 Agent 凭据，并执行归因测试。从日志里任选一个 Agent 操作，问自己能否判断是哪个 Agent 做的、它代表谁，以及能否只撤销这个 Agent 而不影响其他 Agent。如果答案是否定的，你就存在共享身份问题，这应该是第一个修复项。

2. 本月：挑一个自主 Agent，把它从长期凭据迁移到短生命周期、任务级 scope 的 token。这些 token 由 token service 或身份平台签发，保留在工具执行层，并且永远不进入模型上下文。从拥有最广访问权限的 Agent 开始，通常就是某个人当初为了赶进度而“临时”给了过宽权限的那个。

3. 本季度：给每个逻辑 Agent 一个独立、稳定的身份。有对应基础设施时使用 SPIFFE ID，没有时至少做到每 Agent 一个唯一服务账号。把审计和告警绑定到该身份，并在真正需要之前写好撤销 runbook。如果你还在更早阶段，甚至还在决定 Agent 应该在哪里运行，那么本地 Agent 与云端 Agent之间的取舍会决定这一层你能掌握多少控制权。

FAQ

从 IAM 角度看，什么是 Agent 身份？

它是分配给单个 AI Agent 的独立、可验证身份，与运行它的平台以及它所代表的用户分离。这个身份是认证、授权策略、审计轨迹和撤销的稳定键，就像 workload identity 用来识别微服务一样，只不过它需要适应那些临时、非确定性、还能彼此委派的调用方。

为什么 Agent 不能直接共享一个服务账号？

技术上当然可以，而且今天大多数系统确实这样做。问题在于：审计日志显示的是共享账号，而不是实际执行操作的 Agent，因此无法归因；账号权限会逐步膨胀为所有 Agent 权限需求的并集；撤销一个 Agent 意味着必须给所有 Agent 轮换凭据；你也无法区分用户委派操作和自主操作。它在第一次事故之前都能工作，事故发生后你才会发现自己无法重建到底发生了什么。

标准机构正在如何处理 Agent 身份？

IETF WIMSE 工作组正在把 workload identity 架构扩展到 AI intermediaries，并有一个活跃提案要求使用每 Agent 标识符，建议机制是 SPIFFE URI，而不是依赖 token scopes。OWASP 在 2025 年 12 月发布了 Top 10 for Agentic Applications，把 identity and privilege abuse 作为一个明确类别。Cloud Security Alliance 也有 Agent 身份治理框架，建议每个 Agent 都拥有唯一身份。

Agent 凭据是否应该出现在模型上下文中？

不应该。上下文窗口中的任何内容都对模型可见，也可能被 prompt injection 外泄。行业正在接受的模式是：凭据在任务执行时由 token service 签发，由模型与 API 之间的工具执行层持有，限制在当前任务范围内，并保持短生命周期。模型请求执行动作，Harness 持有秘密。

最后结论

身份领域有句话说，identity 就是 control plane，而 Agent 将比微服务更严苛地检验这句话。方向已经足够清楚，现在就可以开始建设：每个 Agent 独立身份，秘密留在模型之外，token 的过期速度要快于事故扩散速度，审计必须能回答“哪个 Agent、代表谁、为了什么目标”。今年夏天出问题的组织并没有运行什么奇特架构，它们只是使用共享凭据，然后寄希望于一切顺利。这就是需要补上的缺口，而且大多数所需技术已经存在。

如果你正在把 Agent 身份映射到现有 IAM 体系，并希望有真正做过这类系统的人参与讨论，这正是我提供的工作之一。联系我。

来源

• IETF WIMSE WG, draft-ietf-wimse-arch issue #139, "AI and ML-Based Intermediaries: token scopes do not create per-agent identity": https://github.com/ietf-wg-wimse/draft-ietf-wimse-arch/issues/139（提交于 2026-08-04，访问于 2026-08-29）

• Cockroach Labs, "AI Agent Identity Security": https://www.cockroachlabs.com/blog/ai-agent-identity-security/（发布于 2026-07-17，访问于 2026-08-29）

• Token Security, "The 2026 Data Breach Investigations Report Confirms It: Identity Is the Control Plane for Agentic AI": https://www.token.security/blog/the-2026-data-breach-investigations-report-confirms-it-identity-is-the-control-plane-for-agentic-ai（发布于 2026-05-20，访问于 2026-08-29）

• Descope, "What Is Workload Identity Federation for AI Agents?": https://www.descope.com/learn/post/workload-identity-federation-for-agents（发布于 2026-06-22，访问于 2026-08-29）

• miniOrange, "Why AI Agents Need Workload Identity, Not Shared Secrets": https://www.miniorange.com/blog/workload-identity-ai-agents/（发布于 2026-05-20，访问于 2026-08-29）

• Reco, "Non-Human Identities for AI Agents: How to Govern Access": https://www.reco.ai/blog/non-human-identities-for-ai-agents（发布于 2026-07-20，访问于 2026-08-29）

• Waxell, "Hugging Face Breach: How an AI Agent Ran the Attack": https://www.waxell.ai/blog/hugging-face-agentic-attacker-ai-breach-2026（发布于 2026-07-17，访问于 2026-08-29）

• Studio Global, "EU AI Act August 2026: Enforcement Powers Go Live as Autonomous Agent Breach Tests Regulators": https://www.studioglobal.ai/discover/answers/what-key-enforcement-powers-and-transparency-obligations-6a6bff1f2240a0fb8c880846（发布于 2026-08-17，访问于 2026-08-29）