Agent IAM 系列（一）：Agent 不是服务账号

这是「Agent IAM 系列」第一篇。本文讨论的是：为什么 Agent 不能再被当作普通服务账号，企业 IAM 正在进入自治身份治理时代。

过去企业做身份与访问管理，主要管三类对象。

第一类是人，比如员工、管理员、外包人员和客户。

第二类是应用和系统，比如服务账号、API Key、数据库账号、CI/CD Token。

第三类是云原生环境里的工作负载，比如容器、微服务、Kubernetes workload。

这些对象虽然复杂，但总体上有一个共同点：它们的行为边界相对可预测。

员工有岗位，账号有归属，应用有固定功能，服务账号通常绑定一个系统或一段流程。

IAM 系统只要能回答“是谁”“能访问什么”“什么时候访问”“是否符合权限”，大多数场景就能运转起来。

Agent 出现后，这套假设开始松动。

一个企业 Agent 可能不是长期存在的账号，而是在某个任务中临时生成。

它可能不是单独行动，而是调用多个工具、访问多个系统、委派多个子 Agent。

它也可能不是按固定流程执行，而是根据目标自己规划路径、调整步骤，甚至动态生成代码或调用新的外部服务。

这时，继续把 Agent 当成一个普通服务账号管理，就会出现一个根本问题：我们看到了账号，却看不清真正的行动者。

2026 年 2 月，Angelika Steinacker 和 Hari Hayagreevan 发布技术报告《Governing AI Agents: An Agent-Aware IAM Framework》。

https://zenodo.org/records/18471221

这篇文章的核心观点非常直接：Agentic AI 引入了一类新的身份对象，作者称之为 Autonomous Non-Human Identities，也就是“自治非人类身份”。

这些身份能够自主行动、实时决策，并跨系统协作，传统面向人类用户或静态工作负载设计的 IAM 框架，已经很难处理它们带来的规模、短生命周期、委派和跨域信任问题。

企业真正要管理的，已经不是一个账号

在传统 IAM 里，账号经常被当成身份治理的核心对象。但这篇文章提醒我们，账号只是数字身份的一个属性。

原文中对 Digital Identity 的定义很关键：数字身份代表 IAM 语境中的一个实体，它可以是人，也可以是非人实体。

非人实体可以从手机、汽车，到 IT 系统、应用，再到 AI Agent。

一个数字身份包含唯一标识、类型、状态、账号、凭证、组织属性、成本中心、经理、Owner 等信息，账号只是数字身份的属性之一。

这句话放在 Agent 场景里非常重要。

如果企业只给 Agent 分配一个 API Key，或者让它复用某个系统账号，本质上只是解决了“怎么调接口”的问题，并没有解决“这个行动者到底是谁”的问题。

一个 Agent 的身份，应该至少回答几件事：它是谁创建的，归属哪个业务，基于哪个模型版本，运行在哪个环境，允许调用哪些工具，可以访问哪些数据，能否生成子 Agent，出了问题谁负责。

这些信息并不等同于账号权限。它们共同构成了 Agent 的数字身份。

服务账号通常是一个技术入口，Agent 则更像一个会行动的数字角色。它会理解任务、制定计划、调用工具、触发系统动作，有时还会代表某个人或某个业务流程执行决策。因此，Agent 的身份治理不能停留在“给它一个账号”这一步。

Agent 为什么会击穿传统 IAM 的假设

传统 IAM 适合管理相对稳定的对象。

员工身份通常持续数月、数年；服务账号通常绑定固定应用；机器身份虽然数量很多，但大多对应明确的工作负载和部署环境。

它们的权限可以通过角色、属性、策略和审批流程进行管理。

Agent 的问题在于，它把几个传统 IAM 最不擅长的特征集中到了一起。

它可能是短生命周期的：一个子 Agent 只存在几分钟，完成任务后就销毁。

它可能是上下文感知的：同一个 Agent 在不同任务中会访问不同数据、选择不同工具。

它可能是会委派的：一个主 Agent 可以生成多个子 Agent，每个子 Agent 又继续调用其他工具或系统。

它还可能是跨域协作的：企业内部 Agent 会调用外部 API、云服务、第三方模型、MCP 工具和数据源。

原文指出，传统 IAM 面向人类用户，依赖认证、授权和问责机制；但 Agent 以大规模、高速度、跨系统的方式自主行动，短生命周期和动态上下文让传统人类中心 IAM 模型不再适用。

即使是面向服务账号的非人类身份管理，也通常假设对象相对静态，难以治理能够独立决策、适应环境变化的 Agent。

所以 Agent IAM 的核心矛盾，不是传统 IAM 没有权限控制，而是它对“行动者”的理解太静态。

在过去，一个系统账号调用数据库，通常意味着某个固定系统在执行固定任务。

到了 Agent 场景，同样一个调用可能来自用户指令、任务规划、工具链触发、子 Agent 委派、Prompt Injection 诱导，甚至来自 Agent 自己生成的代码。

日志里看起来都是一次 API 调用，但安全含义完全不同。

Agent 需要成为 IAM 里的“一等身份”

这篇文章最重要的判断是：AI Agent 应该被视为一种独立身份类别，而不是传统服务账号的变体。

原文认为，IAM 需要沿两个方向演进。

第一，要承认 AI Agent 是一种特殊的工作负载身份，需要明确治理、完整生命周期管理和动态认证。

第二，要系统性扩展 Identity Fabric，引入去中心化标识、可验证凭证、动态策略执行和零信任原则。

这其实是在说，Agent 要进入企业 IAM 的“正编”。

它不能再躲在某个应用账号后面，也不能完全继承某个人的权限，更不能长期持有一串静态 API Key 在各个系统里乱跑。

每个关键 Agent 都应该有自己的身份、生命周期、Owner、Purpose、凭证、权限边界和审计链。

文章还专门提到几类 Agent 身份形态：

长期存在的 persistent agents，

临时存在的 ephemeral agents，

父子结构中的 hierarchical agents，

以及从同一来源分裂出来的 forked agents。

不同类型的 Agent，需要不同的治理方法。

这对企业落地很现实。

一个客服 Agent 可能长期存在，需要稳定身份和持续复核。

一个数据分析子 Agent 可能只在一次任务中存在，需要短期身份和自动注销。

一个主 Agent 调用多个子 Agent，需要记录父子关系和委派链。

一个 Agent 被复制到不同业务线使用，需要追踪来源和分叉后的责任边界。

如果 IAM 系统不能区分这些身份形态，就无法真正理解 Agent 行为。

传统 IGA 的 Joiner / Mover / Leaver 也要重写

这篇文章有一个很有意思的部分：它不是只谈认证和授权，而是把传统 IGA 里的 Joiner、Mover、Leaver 和 Recertification 拿出来重新讨论。

在人类身份治理中，Joiner 通常对应员工入职，Mover 对应转岗或角色变化，Leaver 对应离职和账号注销，Recertification 对应周期性权限复核。这个流程已经非常成熟。

但 Agent 的生命周期完全不同。

Agent 可能是显式部署的，也可能是其他 Agent 自动生成的；可能只存在几分钟，也可能由用户临时创建，形成所谓 shadow AI。

原文指出，组织常常缺少正式流程来追踪、分配 Owner 或复核 AI Agent 身份，这会带来影子 AI、归属不清和生命周期失控等问题。

更麻烦的是 Mover。

人的 Mover 通常是岗位变化，Agent 的 Mover 可能是模型更新、能力范围扩展、业务目的变化、目标变化、工具变化、数据源变化。

原文特别提到，当前行业几乎没有充分讨论 Agent 语境下的 Mover 流程，也就是当 Agent 的角色、权限、业务目的、目标发生变化时应该如何治理。

这其实击中了企业智能体平台的一个隐患。

很多企业一开始上线 Agent 时，会把它当成一个功能模块。今天加一个 RAG 数据源，明天加一个数据库查询工具，后天让它接入工单系统，再后来让它能自动发邮件、改订单、调用代码执行器。每一次看起来都是小改动，但从身份治理角度看，Agent 的能力边界已经发生了变化。

如果 IAM 不把这些变化当成身份生命周期事件来管理，Agent 就会在系统里悄悄长大。它原本只是一个问答助手，最后可能变成一个拥有多个系统访问能力的自动化执行者。

这就是 Agent IAM 必须前置设计的原因。等 Agent 已经跑起来，再回头补身份模型、补委派关系、补工具授权、补审计链，成本会非常高。

Identity Fabric：Agent IAM 不是一个孤立安全插件

文章并没有主张重新发明 IAM，而是希望扩展 Identity Fabric。

Identity Fabric 可以理解成企业身份治理的一张网，它把身份数据、身份服务、策略执行、编排能力、审计能力连接起来，让 IdP、PAM、IGA、SIEM、API Gateway、数据治理系统不再各自为政。

原文提到，Identity Fabric 的高层架构包括分层架构、模块化架构、编排层和 Identity Data Hub。它不能孤立运行，必须和组织结构、流程制度、技术基础设施、数据环境集成，也要和 SOC、ITSM 等安全和运维能力连接。

这对 Agent 场景非常关键。

Agent 安全不是模型团队一个部门能解决的问题，它涉及智能体平台、业务系统、IAM、数据安全、API 管理、日志审计、SOC、合规团队。

Agent 调用工具之前，平台要知道它是谁；

访问数据之前，数据系统要知道它为什么访问；

发生异常之后，SOC 要能还原它从哪个用户请求开始，经过了哪些 Agent 和工具，最后触发了什么动作。

所以 Agent IAM 更像一个控制平面，而不是一个单点产品。

Agent 平台负责产生上下文，IAM 负责身份和权限，策略引擎负责动态判断，工具网关负责执行控制，日志审计负责追踪，安全运营负责响应。只有这些能力串起来，Agent 才能在企业里真正可控运行。

四层架构：从身份，到信任，到控制，再到审计

这篇文章最适合直接引用的一张图，是它提出的 Agent-Aware IAM 四层部署架构。

这四层分别是 Identity Foundation、Trust & Federation、Security & Privacy Enforcement、Lifecycle & Observability。

原文认为，这套四层架构把 Identity Fabric 的理论结构转化为 Agentic AI 环境中的生产部署模式，可以支撑动态身份签发、实时信任建立和端到端来源追踪。

第一层是身份基础层。

这一层要解决 Agent 到底是谁的问题。

每个 Agent 都应该拥有唯一、可验证、绑定 Owner 和 Purpose 的身份。它不是只有账号和密钥，还应该包含 agentType、controllerID、modelVersion、purposeTag、executionContext 等属性。

原文案例中，信用评估 Agent A2 会拿到一个 5 分钟有效的临时身份，身份属性表明它可以访问 DB1 和 S2，但不能访问 S3。

第二层是信任与联邦层。

这一层要解决 Agent 如何跨系统、跨域、跨云建立信任的问题。

原文提到 OIDC Federation、OAuth Token Exchange、Verifiable Credentials、Cross-cloud trust brokers、Agent Naming Service 等能力。

一个 Agent 调用外部信用服务时，可以出示可验证凭证，证明自己是 credit-evaluator，访问范围是 risk-data-read，模型版本是 1.8，目标系统验证后再签发短期 Token。

第三层是安全与隐私执行层。

这一层要解决当前请求能不能放行的问题。

策略判断不能只看角色，还要看 Agent 身份、Purpose Tag、数据分类、风险分数和当前上下文。

原文案例中，A2 可以访问信用数据 DB1，但不能调用订单系统 S3；如果它因为错误、漂移或 Prompt Manipulation 尝试访问 S3，执行层应该立即阻断。

第四层是生命周期与可观测层。

这一层要解决事后能否复盘的问题。

企业和监管方需要知道哪个 Agent 做了什么、使用哪个身份、基于哪个模型版本、依据哪些输入、访问哪些数据、最后产生什么决策。

原文提出要把 Agent ID、Token、Task、访问数据和最终决策串起来，并记录 SBOM、模型 Hash、运行时完整性状态等证明信息。

这四层合起来，给了企业一个很清楚的建设路径。

先让 Agent 有身份，再让身份能跨域证明；然后把策略执行放到工具调用和数据访问链路上；最后把所有行为变成可审计、可追责、可解释的链路。

信用评分案例：为什么“能访问”不等于“该访问”

原文用了一个信用评分与订单管理的多 Agent 系统作为例子。

这个系统里有前端编排 Agent A1，负责接收和编排请求；

信用评估 Agent A2，负责读取风险数据并计算信用评分；

订单管理 Agent A3，根据策略阈值执行订单动作；

还有一个 LLM / Code-Generation Agent A1′，用于动态推理或工具生成。

它们会和企业系统 S1、S2、S3 以及信用数据仓库 DB1 交互。

这个例子很像未来企业 Agent 的真实形态。

一个业务任务不会只由一个 Agent 完成，而是由多个专门 Agent 协同完成。

A1 负责入口，A2 负责信用评估，A3 负责订单动作，A1′ 负责补充推理或生成代码。它们共同完成“客户信用验证并推进订单处理”这个流程。

问题也随之出现。

A2 需要访问信用数据，但不应该访问订单系统；A3 需要执行订单决策，但不应该读取信用评分模型逻辑或 PII；A1′ 如果生成了试图扩大权限的代码，系统应该撤销它的 Token 并告警。

原文明确把这些动作放在运行时策略执行和可观测链路里，而不是只靠静态角色权限解决。

这里真正有价值的地方在于，它把 Agent 安全从“模型输出安全”拉回了“企业动作安全”。

很多人谈 Agent 风险，首先想到的是 Prompt Injection、越狱、输出有害内容。

但企业真正担心的，往往是 Agent 在业务系统里做了什么。它有没有读取不该读取的数据，有没有调用不该调用的工具，有没有代表用户触发了不可逆操作，有没有在子 Agent 委派中扩大权限。

这不是内容安全问题，而是身份治理和访问控制问题。

Agent IAM 必须在平台建设初期就设计

这篇文章虽然讨论的是 IAM，但对智能体平台建设有一个很强的现实提醒：Agent IAM 很多能力不能等上线后再补。

因为第三方安全系统事后能看到的，往往只是 API 日志、网络流量、工具调用记录和异常事件。但 Agent 行为真正需要的上下文，很多只存在于 Agent 平台内部。

比如，某次数据库访问到底来自哪个用户请求？是主 Agent 发起，还是子 Agent 发起？这个子 Agent 是谁创建的？它继承了哪个父 Agent 的权限？当前任务是什么？它调用工具之前的计划是什么？这次访问是否符合它的 Purpose？

如果平台一开始没有记录这些信息，后面的审计和治理就会变成猜谜。

这就是为什么 Agent IAM 更像平台架构的一部分，而不是上线后的安全外挂。

企业在建设智能体平台时，至少要从一开始设计 Agent ID、Session ID、Task ID、Parent Agent ID、Tool Call ID、Data Access Event、Purpose Tag、Model Version、Policy Decision、Audit Trace 这些基础字段。

它们看起来像元数据，实际上是未来安全治理、合规审计和事故追责的骨架。

没有这些骨架，Agent 的行为就会散落在多个系统日志里。安全团队可能知道“某个接口被调用了”，却不知道“哪个 Agent 因为什么任务调用了它”。

第三方厂商的机会：不是替企业重建 IAM

Agent IAM 必须前置设计，并不意味着第三方安全厂商没有机会。

相反，机会会很大。

只是这个机会不太像传统意义上的“卖一个 IAM 系统”。

企业已有 IAM、IdP、PAM、SIEM、数据安全和 API 网关，不会因为 Agent 出现就全部推倒重来。

更现实的模式，是第三方厂商提供 Agent 身份与行为治理增强层。

这个增强层可以帮助企业发现 Agent 资产，识别影子 Agent，梳理 MCP、Tool、Skill、RAG、长期记忆和外部 API 的调用面；

也可以在工具调用和数据访问前做动态策略判断，把 Agent ID、用户身份、任务上下文、Purpose、工具风险、数据分类和风险分数放进统一决策；

还可以把 Agent 行为链路转成审计报告，用于安全运营、合规检查和事后溯源。

换句话说，企业智能体平台负责产生可信上下文，第三方安全产品负责消费上下文、评估风险、执行策略、生成审计。

这个定位会比“替企业做一个 Agent IAM”更现实，也更容易落地。

对 AI 安全厂商来说，真正要争取的位置，是 Agent Runtime、Tool Gateway、MCP Gateway、Data Access Gateway 和企业 IAM 之间的控制面。

谁能在这里建立策略和审计能力，谁就更可能成为 Agent 时代的安全基础设施。

Agent 时代，IAM 正在从后台系统变成前台控制面

这篇文章最后有一个判断很值得记住：信任，而不是技术能力，正在成为企业采用 Agentic AI 的关键约束。

组织如果不能把 IAM 现代化为 Agent-Aware IAM，不仅会继承前所未有的网络安全风险，也无法安全、规模化地运行 AI Agent。

IAM 正在成为 AI 驱动转型的推动因素，也可能成为限制因素。

这句话其实点出了 Agent 落地的核心。

未来企业不是没有 Agent 能力，而是不敢让 Agent 真正行动。

让 Agent 写一段摘要，很容易；让 Agent 读取业务数据，开始有风险；让 Agent 调用工具，风险继续上升；让 Agent 代表企业执行订单、审批、转账、发邮件、改配置、生成代码并部署，风险就进入了另一个层级。

到了这个阶段，企业最关心的问题不再是“模型聪不聪明”，而是“这个 Agent 能不能被管理”。

能不能知道它是谁。 能不能限制它能做什么。 能不能确认它代表谁行动。 能不能控制它调用哪些工具。 能不能约束它访问哪些数据。 能不能追踪它生成了哪些子 Agent。 能不能在出事后完整复盘。

这些问题最终都会回到 IAM。

所以，Agent 不是服务账号。它是一种新的自治数字身份。

过去 IAM 管的是人和系统的访问权限。

Agent 时代，IAM 要开始管理会行动、会委派、会变化、会跨系统协作的数字角色。

这也是 Agent 安全正在进入的新阶段：从内容护栏，走向身份治理；从工具拦截，走向行为链路；从单点防护，走向企业级控制面。

下一篇，我们会继续讨论作者后续提出的两个概念：Purpose 和 Intent。

因为即便一个 Agent 拥有合法身份和合法权限，也还会出现一个更细的问题：它有权限，不代表它此刻就该这么做。