AI Agents暴露身份生命周期治理盲区

身份生命周期管理的架构原本是围绕一个拥有雇佣记录、主管和离职日期的人来设计的。AI agents 没有这些要素。随着自主 principal 在企业环境中大量出现，为人类建立的治理模型出现了传统 IGA 工具并未设计去发现的结构性盲点。本指南说明该模型在哪些地方失效、它无法治理什么，以及将其扩展到 agents 具体需要什么。

身份生命周期管理原本要处理什么

要理解为什么身份生命周期管理在 AI agents 周围会失效，你需要先了解它原本擅长做什么，以及它是为谁而设计的。整个架构建立在一个基本假设之上：每个身份都对应一个人，而这个人的组织状态会通过有记录、由 HR 驱动的事件发生变化。

身份生命周期管理流程从一个身份的首次 provisioning 事件开始，一直到它经历的每一次修改，再到最终停用。其核心是一个事件驱动的控制系统，围绕三类标准转换：joiner、mover 和 leaver。

HR 作为权威引擎

HR 平台，无论是 Workday、SAP SuccessFactors 还是 ServiceNow HR，都是驱动整个 identity and access management 生命周期的 system of record。新员工记录会触发向 Active Directory 或 Azure AD 的自动 provisioning，再通过 IGA connectors 将 entitlement 传播到下游应用。部门调动会更新 role 属性并重新计算合适的 entitlement 集。离职事件会触发所有已连接系统的 deprovisioning 工作流。

这个模型的优势在于其确定性。访问权限反映的是一个可验证的组织事实：某人在某个团队中、在某个主管之下担任某个具体角色。基于角色的访问控制会将这些属性映射到定义好的 entitlement 集，在入职时直接提供正确权限，而无需对每个账户单独协商。

Identity governance 生命周期管理在此基础上建立问责机制。访问认证活动会流转到 identity manager 或 application owner 进行确认。职责分离控制会检测冲突权限。审计日志会将每一次 provisioning 操作追溯到最初的 HR 事件以及授权批准人，从而提供 SOX、HIPAA 和 PCI DSS 等框架所要求的合规证据。

身份生命周期管理各阶段在实践中如何执行

当员工变更岗位时，属性更新会自动重新计算 entitlement，撤销新岗位不需要的权限，并授予其需要的权限。当员工离职时，HR 的 termination 事件会触发所有已连接应用的 deprovisioning。认证活动会按既定周期运行，在事件之间填补空档，要求主管就当前访问是否符合当前岗位要求进行确认。

标准身份生命周期管理各阶段中的每一项控制，都假设存在一个拥有雇佣记录、主管关系以及可预测转换模式的人类 principal。访问审查工作流会路由给人。provisioning 触发点来自人类在 HR 系统中进入或改变状态。offboarding 则在人类的组织状态变化时触发。

这个模型是连贯的、可审计的，并且有数十年的 IGA 工具支撑。它能可靠治理人类身份群体。问题正是在其边缘开始，也就是那些在企业环境中积累访问权限的 principal 已经不再拥有雇佣记录、主管或离职日期的时候。

AI Agents 为什么不在这个模型范围内

AI agents 不会通过 HR 到来。它们没有雇佣记录、汇报结构，或可映射到 entitlement 集的明确角色档案。它们由工程师、编排框架或自动化部署流水线创建，并以开发者在创建时限定的权限，或平台默认授予的权限进入生产环境。

这个起源故事打破了身份生命周期管理模型所依赖的每一项假设。

没有权威来源，就没有受治理的入口点

标准 identity and access management 生命周期控制需要一个权威来源来发起 provisioning。对于人类，这个来源是 HR 系统。对于 AI agents，provisioning 通常发生在开发者提交配置文件、平台 API 调用实例化新的 agent runtime，或者像 LangChain、AutoGen 或 AWS Bedrock Agents 这样的编排层启动新的执行上下文时。这些事件都不会触及 IGA 平台，也不会生成一个绑定到明确定义 identity owner 的 provisioning 记录。

agent 到达时，凭据已经附带：手工创建的 service account、存储在环境变量中的 API key，或通过开发者同意流程签发的 OAuth grant。如果 IGA 平台看到了这些凭据，它会将其视为具有固定用途的静态 machine identity。实际上它面对的是一个自主 principal，它会做出访问决策、跨越 API 边界，并以传统 service account 从不会有的方式积累行为范围。

在为固定角色而建的系统中，scope 是动态的

RBAC 之所以有效，是因为人类岗位职能在一定范围内是可预测的。数据库管理员需要特定权限。财务分析师需要访问一组明确系统。entitlement 集是围绕这些职能设计的，并在通过有记录的 HR 事件发生角色变化时更新。

AI agents 不会停留在固定功能边界内。一个用于总结内部文档的 agent，可能通过 tool-calling 或 RAG 检索模式，去查询它并未被明确赋权的 API，将输出写入原始范围之外的存储系统，或者串联多个企业系统的操作来完成任务。访问面在运行时扩张，驱动因素是 agent 的目标导向行为，而不是治理团队事先做出的任何策略决定。

身份生命周期管理各阶段并不是为治理运行时扩张的 scope 而设计的。它们是为治理在 provisioning 时定义、并在已知转换点调整的访问而设计的。

在同一时间多环境实例化

一个人类 identity 在同一时间只存在于一个地方。一个 AI agent 可以同时在多个云环境、容器化工作负载和 SaaS API 表面上以数十个并行实例运行。每个实例都可能带有自己的凭据集、自己的工具权限以及自己的会话上下文，而这些在任何 IGA 系统中都不会被关联起来。

在 multi-agent 架构中，这种复杂性会进一步放大。orchestrator agents 会生成 sub-agents，分派任务，并在执行上下文之间传递凭据。identity and access management 生命周期没有原生模型来处理一个会动态分叉、委派并在分布式执行图中重新组合访问权限的 principal。

IGA 工具实际看到什么

当 IGA 平台遇到一个 agent identity 时，它看到的是带有 API key 或 OAuth client 凭据的 service account。Identity governance 生命周期管理工具会对其应用与任何 machine identity 相同的治理逻辑：检查是否有 owner、验证凭据年龄，并查看该账户是否出现在最近一次 access review 中。

它看不到的是，这个账户正在主动做出授权决策、跨越应用边界，并以传统 service account 不具备的自主程度运行。治理记录看起来是静态的，实际访问行为却完全不是。

Agents 从未触发的生命周期事件

joiner-mover-leaver 模型之所以有效，是因为人类雇佣关系会生成一系列结构化事件，治理系统可以据此采取行动。AI agents 不会生成这些事件。标准身份生命周期管理各阶段中的每个控制点都依赖一个 agent 部署在设计上不会产生的信号。

没有 joiner 事件，就没有受治理的入口

当新员工加入时，HR 记录的创建会触发 provisioning。访问会按角色定义进行范围控制，经过审批链路，并在 IGA 平台中记录且附带 owner。身份在第一天就进入治理边界。

AI agent 则通过部署流水线、Terraform apply，或对 agent 编排平台的直接 API 调用进入生产环境。没有 IGA workflow 被触发。没有访问请求被提交。没有主管批准 entitlement 集。agent 的凭据，无论是 service account、OAuth client 还是 API key，都会与部署一起内联创建，通常由同一个自动化流程负责 provision 计算环境。identity and access management 生命周期从未收到 joiner 信号，因此该 agent 的治理记录最初就是空白的。

没有 mover 事件，就没有 entitlement 重新计算

当人类员工变更角色时，HR 属性更新会流入 IGA 平台，触发 entitlement 重新计算。旧角色适用的访问会被撤销，新角色需要的访问会被 provision。治理记录会反映当前组织现实。

AI agents 会不断改变 scope，而这些变化都不会生成 mover 事件。一个被重新调整以访问新数据源、扩展去调用更多 API，或重新部署到不同环境的 agent，不会更新任何 HR 系统。没有 IGA connector 收到属性变化。没有 access review 被触发去核对 agent 现在可访问的内容与其最初 provisioned 的内容是否一致。Identity governance 生命周期管理对完全发生在部署层中的 scope 扩张没有可见性。

没有 access review 信号

周期性 access certification 依赖向特定 identity 相关联的主管或 application owner 发送审查任务。该路由逻辑需要一个在记录中有 human owner，并且 IGA 平台可以沿着其组织关系追踪的 identity。

agent identities 会在部署迭代中累积权限，却不会产生 recertification workflow 依赖的任何信号。每一次新的工具集成、每一项额外的 API scope、以及每一层扩展的 OAuth grant，都会被添加到 agent 的访问档案中，而不会触发审查。诚实地回答什么是 identity lifecycle management 这个问题，对于 agents 来说，就是一种不会产生认证记录、不会形成确认历史，也没有持续治理证据的模型。

没有 leaver 事件，就没有 deprovisioning

当 HR termination 记录关闭雇佣关系时，offboarding 会触发。agent 对应的情况——部署被退役、工作流被弃用，或项目被关闭——不会产生等价信号。

被退役的 agent 凭据会在 secrets manager、环境变量存储和 OAuth authorization server 中长期存在，远远超过其所服务的工作负载停止运行之后。围绕 HR 触发 deprovisioning 构建的身份生命周期管理解决方案，没有机制去检测 agent 是否已经消失。凭据仍然有效。访问路径仍然开放。治理记录显示该 identity 仍然活跃，因为从 IGA 平台的角度看，什么都没有变化。

这对 provisioning、审查和 offboarding 意味着什么

上述治理缺口并非理论上的边缘情况。它们会在 agent 生命的每个操作阶段产生具体风险，并持续叠加。当 provisioning 没有定义好的 scope、审查没有产生可行动信号、offboarding 没有触发条件时，访问面只会朝一个方向扩张。

Provisioning：过度授权成为默认起点

人类 provisioning 从角色定义开始。IGA 平台将岗位职能映射到 entitlement 集，新 identity 获得的访问会校准到该职能所需范围。scope 在 identity 存在之前就已定义。

agent provisioning 则是反过来的。开发者需要 agent 完成某个任务，因此会授予足够宽泛的访问以确保成功。主流云和 SaaS 平台中的最省阻力路径往往是宽松的：当 AWS IAM policies 以 wildcard 方式限定时会默认倾向于广泛的资源访问，OAuth consent flows 会签发所有请求的 scopes 而不会逐项挑战权限，而在 Azure AD 或 Google Workspace 中创建 service account 时也没有内建的 entitlement 治理检查。

agent 在首次运行时就以过度授权的状态进入生产环境，没有最小必要基线、没有审批链，也没有将所授予访问与明确业务需求关联起来的 IGA 记录。

Access reviews：找不到 owner 的路由逻辑

标准 identity governance 生命周期管理平台中的 certification campaigns，会根据 identity 属性路由审查任务，尤其是 manager 关系和 application ownership 记录。审查人会收到 identity 及其 entitlement 列表，确认每项访问授权仍然合适，然后提交 attestation。

agent identity 从根本上破坏了这一路由逻辑。大多数没有 manager 属性。许多在 IGA 平台中没有定义 human owner。即便存在 application ownership 记录，它们通常指向一个团队而不是个人，而该团队对 agent 当前访问内容的熟悉程度，往往与最初 provision 的内容并不一致。

当 certification campaigns 真的覆盖到 agent identities 时，审查人确认的是 IGA 系统中的访问记录，而该记录反映的是创建时 provision 的内容，而不是 agent 通过迭代部署变更累积下来的内容。这个 attestation 在形式上是完整的，在操作上却毫无意义。

Offboarding：比工作负载存活更久的凭据

HR 触发的 deprovisioning 是确定性的。终止记录关闭，IGA 平台向每个已连接应用发送 deprovisioning 指令，访问路径在一个明确时刻关闭。

agent 弃用不会生成等价信号。开发团队退役一个工作流、归档仓库并退役计算环境。service account 仍然保留在 Active Directory 或 Entra ID 中。API key 在 secrets manager 中仍然有效。OAuth authorization grant 在 authorization server 上仍然有效。发行这些凭据的系统都没有收到撤销指令，因为一开始就没有任何系统监控该 agent 的运行状态。

陈旧的 agent 凭据不是小问题。一个带有生产数据库访问权限、且附着于已不再运行工作负载上的长期 API key，就是一条没有 owner、没有审查历史、也没有过期时间的非受治理访问路径。在大量 agent 通过迭代部署周期运行的环境中，这些凭据积累的速度会快过任何人工审计流程的处理能力。

当前在大多数企业环境中实现的 identity and access management 生命周期，没有机制去检测 agent 不活跃、根据运行状态标记凭据年龄，或在工作负载停机时触发撤销。

如何扩展身份生命周期管理以覆盖 agents

将身份生命周期管理扩展到覆盖 AI agents，并不意味着把 HR 驱动的工作流硬套到一种本来就不是为其设计的 principal 类型上。它的意思是，围绕 agent 的实际运行特征重建治理逻辑：它如何被创建、scope 如何演变，以及其运行生命周期如何结束。

跨所有部署面进行自动化发现

agent identities 会在云服务商 IAM 系统、SaaS OAuth authorization server、Kubernetes service account、secrets manager 和 CI/CD pipeline 凭据存储中被创建。没有任何单一系统维护完整清单，而通过自动化流水线部署的 agents 往往根本不会出现在传统 IGA 平台寻找它们的任何位置。

一个真正适用于 agents 的 identity lifecycle management 解决方案，需要持续、自动化的发现能力，对 agents 实际存在的环境进行探测：读取 AWS 和 Azure 中的 IAM policy attachments，从 authorization server 提取 OAuth client registrations，从 Kubernetes namespaces 中暴露 service account 配置，并识别嵌入运行时配置中的 API keys。发现必须是持续的，因为 agent 部署变化的速度比任何季度审计周期都快。

围绕 agent 行为构建属性模型

人类 identity 属性映射到组织结构：部门、职位、主管。这些属性支撑 entitlement 决策和审查路由。agent identity 需要完全不同的属性模型。

每个 agent identity 都需要记录明确的 owning team、定义好的运行目的、被授权访问的系统和 API 的有界列表、部署时间戳，以及与其所服务工作负载绑定的预期运行寿命。行为属性同样重要：agent 调用了哪些 API、调用频率如何、以及跨哪些数据面调用。为 agents 构建的 identity governance 生命周期管理方法，会将观察到的访问模式视为治理输入，并使用行为基线找出 agent 持有但从未实际使用过的权限授予。

按 agent 功能范围限定的策略驱动 provisioning

与其在部署时授予访问并随后审查，不如让 agent identities 的 provisioning 遵循成熟 IAM 项目框架对特权人类账户应用的最小权限逻辑：定义 agent 执行其文档化功能所需的最小访问权限，在凭据签发时通过策略强制该范围，并将凭据附加到一个明确 owner 身上，由其对任何 scope 变更承担责任。

在实践中，这意味着把 agent provisioning 集成进 IGA intake workflow，而不是完全留在部署流水线内部。当 agent 需要访问生产 API 或敏感数据存储时，该请求应通过 access governance control 流转，而不是绕过去。

以持续行为监控替代周期性审查

周期性 access certification 对 agent identities 不会产生可操作的信号。可行的替代方案是持续行为监控：追踪每个 agent 实际调用了什么，将观察到的访问与已 provision 的 entitlement 集进行比对，并实时标记偏差。

当 agent 开始调用超出其 provisioned scope 的 API 时，这种偏差就是一个需要立即响应的治理事件，而不是等到下一次季度审查才暴露的问题。行为监控填补了 agent principals 在 identity and access management 生命周期中因 recertification campaigns 而留下的空白。

由运行状态触发的弃用工作流

agents 的 offboarding 需要一个反映运行现实的触发机制。与凭据使用日志挂钩的不活跃监控提供了信号：在定义窗口内没有产生经过身份验证请求的 API key，应被列为撤销审查候选。scope change detection 可在部署修改附着于 agent 凭据的权限时发出标记，生成一个路由到 owning team 进行重新授权的治理事件。

将这些信号连接到自动化撤销工作流，并与 AWS Secrets Manager、Azure Key Vault 或 HashiCorp Vault 集成，可以在无需人工发现步骤的情况下关闭 offboarding 缺口。agents 的身份生命周期管理阶段，会在运行状态结束时结束。

Orchid Security 的位置

大多数企业 IAM 技术栈，只治理它们能通过现有 connectors 看到的 identity 群体。agent identities、未受治理的凭据，以及绕过 corporate IdP 的认证路径，都会落入这些 connectors 无法触及的区域。这正是 Orchid Security 被设计来填补的空白。

跨完整 identity 面进行持续发现

Orchid 部署轻量级 orchestrators，直接对应用进行探测，从受管和非受管环境中提取 authentication flows、authorization logic、account configurations 和 credential storage patterns。结果是一个持续更新的 identity inventory，反映环境中实际存在的内容，包括每一个从未通过 IGA intake workflow 的 agent identity、service account 和 API credential。

对于那些在问实践中什么是 identity lifecycle management 的组织来说，Orchid 的答案从可见性开始：你先治理你已经发现的东西，而大多数项目并没有发现全部。

反映 agent 现实的 identity graph

Orchid 的 identity graph 会把每一个 principal，无论人类还是非人类，映射到它实际使用的 authentication flows、entitlements 和应用访问路径。对于 agent identities，图谱会特别展示 owning team、已 provision 的 permission set、观察到的行为模式和凭据年龄，从而生成 agent 所需、但传统 IGA 平台不会生成的属性模型。

自主身份的防护栏

Orchid 面向 autonomous identity 的防护栏，会将策略驱动控制直接应用到 agent identity 群体：将 scoped provisioning 与文档化的 agent 功能绑定，持续监控其与已 provision entitlement 的行为偏差，并以不活跃信号而非 HR 事件触发弃用工作流。

该平台可与现有 IAM、PAM 和 IGA 基础设施集成，通过组织已经在使用的工具来路由 remediation，而不是替换它们。治理范围会扩大以匹配真实的 identity 面，包括 agent identities，而 identity and access management 生命周期也会扩展去覆盖所有传统身份生命周期管理解决方案都排除在边界之外的 principal。