企业IAM的下一个对象是Agent

charles_he
23 阅读17分钟

企业 IAM 的下一个对象不是员工，而是 Agent

当 Agent 可以代表员工读数据、调工具和修改业务状态时，它就不再只是一段应用代码，而是需要被识别、授权、撤销和追责的数字行动主体。

企业建设 Agent 平台时，最先讨论的通常是模型、知识库和 MCP。

到了真正接入 CRM、ERP、HR、财务系统时，另一个问题会突然出现：

这次操作到底是谁做的？

如果日志里只写员工账号，无法证明是员工本人操作，还是 Agent 代为执行。

如果只写一个共享服务账号，又无法知道 Agent 代表谁、基于什么任务，以及哪个版本生成了这次动作。

如果只记录 agent_name = finance-assistant，问题仍然没有解决。同名 Agent 可能已经更新过几十次，使用不同模型、提示词、工具和策略，实际行为边界完全不同。

这意味着企业 IAM 正在增加一类新的治理对象：Agent Identity。

它不是给 Agent 起一个名字，也不是把 API Key 存进 Secret Manager。它要让企业能够回答：

  • 哪个 Agent 正在运行；
  • 谁对它的业务目的负责；
  • 谁可以修改它的配置和凭据；
  • 它当前能访问哪些系统；
  • 它代表用户执行，还是以自身职责运行；
  • 哪个版本和实例发起了动作；
  • 任务结束、版本下线或 Sponsor 离职后，权限如何失效。

为什么应用身份还不够

企业并不缺少非人身份。

传统 IAM 已经管理：

Application
Service Principal
Managed Identity
Service Account
Workload Identity

这些机制可以让应用获取 Token、访问 API，也能绑定角色和权限。Microsoft Entra 对 Workload Identity 的定义，就是分配给应用、服务、脚本或容器，用于认证并访问其他服务和资源的身份。

因此，Agent Identity 并不意味着现有工作负载身份全部作废。

很多企业完全可以先使用 Service Principal、Managed Identity 或云厂商的 Workload Identity 作为 Agent 的认证载体。

问题在于，传统应用通常具有几个默认前提：

  • 生命周期相对稳定；
  • 部署和权限变化较慢；
  • 责任人明确；
  • 调用路径由代码预先确定；
  • 一个应用身份通常对应一套长期能力。

Agent 的运行方式不完全相同。

一个 Agent 可能由业务人员在低代码平台中创建，只存在几小时；也可能由系统按任务动态生成，一天创建和销毁数千个实例。它还能自行选择工具、循环调用、自动重试，并在不同任务中代表不同用户。

Microsoft Entra Agent ID 官方文档给出的区分很直接：传统 Application Identity 假设长期稳定、所有权明确和生命周期可管理；Agent 则可能动态创建，只存在几分钟，或者每天被创建、销毁数千次。

因此，真正缺少的不是另一种 Token 格式，而是围绕 Agent 建立专门的治理语义。

工作负载身份
→ 解决软件如何认证

Agent Identity
→ 进一步解决哪个 Agent、为何存在、由谁负责、以什么模式行动、何时应被撤销

Agent 名称不是身份

很多系统会把以下字段当成 Agent 身份：

{
  "agent_name": "采购助手",
  "model": "某大模型",
  "owner": "采购部"
}

这更像展示信息，不是可以用于安全决策的身份记录。

一个可治理的 Agent 至少要区分五类对象。

第一类：Agent Definition

这是产品和业务层面的 Agent 定义，描述它为什么存在。

agent_definition_id
name
business_purpose
risk_tier
data_domains
action_catalog
business_sponsor
technical_owner
status

例如：

名称：采购申请助手
业务目的：帮助项目经理创建并提交采购申请
风险等级：中
数据域：供应商、项目、采购
允许动作：查询供应商、创建采购草稿、提交审批

Definition 是稳定的业务身份，不应因为每次发布而改变。

第二类：Agent Version

Agent 的行为会随版本变化。

以下任一变化都可能改变其风险：

  • 系统提示词；
  • 模型或模型参数；
  • 工具清单；
  • MCP Server；
  • Memory 配置；
  • 检索数据源；
  • Policy Bundle；
  • Action Schema；
  • 规划器和重试逻辑；
  • 审批规则。

因此，版本不能只保存在发布流水线里。它应该进入授权和审计上下文。

agent_version_id
agent_definition_id
artifact_digest
model_ref
prompt_digest
tool_manifest_digest
policy_bundle_version
memory_profile_version
release_status
approved_at

这里需要特别校准一个边界：Microsoft Entra Agent ID 提供 Agent 身份对象和生命周期治理，但“Agent 身份必须如何绑定提示词、模型、工具清单和制品摘要”并不是 OAuth 或 IAM 自动完成的标准能力。

把这些字段纳入版本对象，是企业 Agent 平台需要补充的架构设计。

第三类：Agent Identity

Agent Identity 是 IAM 中可认证、可授权、可禁用的主体。

它可以映射到：

  • Agent 专用身份对象；
  • Service Principal；
  • Managed Identity；
  • 其他 IdP 中的 Workload Identity。

核心字段包括：

agent_identity_id
agent_definition_id
identity_provider
principal_id
tenant_id
authentication_method
credential_reference
sponsor
owner
enabled
expires_at

Secret 不应直接存入该记录，只保存 Secret Manager、Managed Identity 或证书的引用。

Identity 解决的是“谁在认证”，Version 解决的是“哪套行为正在运行”。两者相关，但不是同一个对象。

第四类：Agent Runtime Instance

同一版本可能同时运行多个实例。

agent_instance_id
agent_identity_id
agent_version_id
deployment_id
environment
runtime_node
started_at
terminated_at
session_id

实例信息对事故调查很重要。

如果某个 Agent 版本只在一个节点上出现异常，企业需要冻结该实例或部署，而不是立即删除整个 Agent Definition。

第五类：Delegation Grant

当 Agent 代表用户执行时，还需要记录这一次授权关系：

谁委托
委托给哪个 Agent
允许什么动作
面向哪些资源
在多长时间内有效
最多执行多少次
是否允许转委托
是否需要审批

上一系列文章已经讨论过：用户权限只是上限，不能自动成为 Agent 的完整权限包。

这里需要再强调对象边界：

Agent Identity ≠ 用户身份
Agent Identity ≠ Agent Version
Agent Identity ≠ Runtime Instance
Agent Identity ≠ Delegation Grant

把这些对象压成一个 agent_id，短期实现简单，长期几乎无法完成精确撤权和事故归因。

Sponsor 和 Owner 不是一回事

Agent 治理最容易被忽略的角色是 Sponsor。

传统应用常有一个 Owner 字段，通常指开发人员、系统管理员或应用负责人。但技术负责人不一定有权判断一个 Agent 是否仍具有业务价值，也不一定能判断它的业务行为是否符合预期。

Microsoft Entra Agent ID 将行政关系明确分成 Owner、Sponsor 和 Manager：

  • Owner 负责技术配置、凭据和运维管理；
  • Sponsor 对 Agent 的业务目的和生命周期负责；
  • Manager 表示组织层级中的管理关系，可为 Agent 请求访问包。

其中 Sponsor 是 Agent Identity 和 Blueprint 创建时的必需关系。Sponsor 可以决定续期、保留、停用和权限调整，却不因此自动获得修改认证配置的技术权限。

这个分工值得企业借鉴，但不必照搬具体产品模型。

在企业自己的治理体系中，至少应该区分：

Business Sponsor
→ 为什么需要这个 Agent
→ 它是否仍应存在
→ 是否符合业务目的
→ 事故中确认行为是否符合预期

Technical Owner
→ 如何部署和维护
→ 如何轮换凭据
→ 如何修复漏洞
→ 如何下线版本

Security Owner
→ 风险分级和策略基线
→ 高权限接入审批
→ 异常处置和再认证

Data Owner
→ 哪些数据域可以访问
→ 用途和保留规则
→ 敏感数据例外审批

小团队可以由一人承担多个角色，但责任关系不能消失。

谁创建 Agent，不代表谁永远负责

低代码平台会让业务人员快速创建 Agent。

创建者可以作为初始 Sponsor，但不能把“创建人”永久当成责任模型。员工可能调岗或离职，Agent 却仍在后台运行。

如果 Sponsor 离职后没有继任机制，会出现典型的孤儿 Agent：

身份仍然有效
凭据仍然可用
定时任务仍在运行
业务部门无人确认是否还需要
安全团队不敢直接删除

Sponsor 生命周期必须与 HR/IGA 事件联动：

Sponsor 调岗或离职
→ 查找其负责的全部 Agent
→ 转移 Sponsor 或进入冻结期
→ 暂停高风险动作
→ 重新执行访问审查
→ 超时未认领则禁用

这比在资产表中保留一个已经离职的邮箱地址有用得多。

Agent 需要哪几种运行模式

Agent Identity 不能只解决“代表用户”这一种情况。

企业至少会遇到三种模式。

交互式委托

用户在线发起任务，Agent 代表用户执行。

Subject = 用户
Actor = Agent Identity
Grant = 当前任务委托

下游访问优先使用 OBO 或 Token Exchange，并进一步受到任务对象、时间、金额和次数限制。

离线委托

用户或审批人在前一天创建任务，Agent 稍后异步执行。

此时不能长期保存用户会话 Token。更合理的方式是保存可撤销的任务 Grant，运行时再换取短期凭证。

自主职责

企业直接给 Agent 一项持续职责，例如检查证书到期、监控库存或整理低风险日志。

Subject = Agent Identity
Sponsor = 对业务职责负责的人或团队

它不代表某个在线用户，也不应该伪造一名员工充当 Subject。

三种模式必须在审计中可区分。否则同一条日志无法判断权限来源是员工委托，还是企业直接授予 Agent 的职责。

Agent 版本升级为什么需要重新评估权限

传统微服务升级后，服务身份通常保持不变。

Agent 也可以保持稳定身份，但版本变化可能比普通服务更直接地改变可执行行为。

例如：

v1：只能查询订单
v2：增加取消订单工具
v3：增加批量搜索和自动重试
v4：更换模型并接入长期 Memory

如果 IAM 只看到同一个 Service Principal，它可能认为四个版本完全等价。

因此，稳定身份与版本授权要分开：

Agent Identity
→ 保持主体连续性

Agent Version
→ 绑定制品、模型、提示词、工具和策略

Deployment Binding
→ 指定哪个环境允许运行哪个版本

Authorization Policy
→ 决定该版本可使用哪些 Action

并不是每次文案修改都要重新走最高级别审批。可以按变化类型决定评审强度：

只改展示文案
→ 自动验证

更换模型或系统提示词
→ 行为回归评估

新增读取工具
→ 数据域与权限评审

新增写操作、批量能力或外部发送
→ 安全评审 + 业务审批

扩大金额、数量或资源范围
→ 重新授权

关键是，权限不能脱离实际运行版本长期漂移。

一个可执行的生命周期状态机

Agent Identity 不应只有 enabled = true/false。

可以使用以下状态：

DRAFT
→ REGISTERED
→ RISK_REVIEWED
→ APPROVED
→ ACTIVE
→ SUSPENDED
→ RETIRING
→ REVOKED
→ ARCHIVED

DRAFT

Agent 还在设计，不允许访问生产系统。

REGISTERED

完成 Definition、Sponsor、Owner、风险等级和预期数据域登记。

RISK_REVIEWED

完成最小权限、工具、数据域、模型和副作用评估。

APPROVED

允许部署指定版本，但尚未代表任何用户取得任务委托。

ACTIVE

身份、版本、部署和策略绑定均有效，可以在授权范围内运行。

SUSPENDED

临时停止新 Token、任务领取或高风险动作，保留调查证据。

RETIRING

停止创建新任务，等待在途任务完成或迁移。

REVOKED

身份、凭据、会话、Grant 和工具访问全部撤销。

ARCHIVED

保留版本、审批、策略和审计证据，不再具备执行能力。

状态迁移要有审计事件，而不是直接改数据库字段。

禁用 Agent 时，到底要撤销什么

只把资产平台中的状态改成 Disabled，通常不够。

完整撤权至少包括：

  1. 禁止签发新 Token；
  2. 撤销或缩短已有 Token；
  3. 吊销凭据、证书或 Managed Identity 绑定；
  4. 取消未开始的 Delegation Grant；
  5. 停止领取新任务；
  6. 中断或隔离运行实例；
  7. 从 MCP 工具和 Action Allowlist 中移除；
  8. 主动失效 PDP 与 Gateway 缓存；
  9. 阻止消息队列中的延迟重试；
  10. 标记不确定结果并触发对账；
  11. 保留日志、输入摘要和下游回执；
  12. 从源系统读取最终状态。

这也是为什么 Agent 撤权时延必须成为生产 SLO。

一个身份显示已禁用，但旧 Token、缓存或队列任务还能运行半小时，就不能称为撤权完成。

Agent Identity 不等于给每个临时进程创建永久账号

反对 Agent Identity 的常见理由是：如果每个 Agent、版本和实例都建一个 IAM 对象，目录会迅速膨胀。

这个担心成立，所以不能把所有层都建成永久主体。

更合理的分层是：

Agent Definition
→ 稳定业务对象

Agent Identity
→ 可认证、可撤权的主体

Agent Version
→ 平台版本记录，不一定是独立 IAM 主体

Runtime Instance
→ 短生命周期运行记录或短期凭证

Delegation Grant
→ 任务级授权对象

哪些层需要独立 IdP 对象，取决于隔离需求：

  • 不同业务 Sponsor 的 Agent 应隔离；
  • 不同风险等级或数据域通常应隔离；
  • 生产与测试环境必须隔离；
  • 需要独立撤权和审计的 Agent 应隔离；
  • 每个无状态副本不必拥有永久账号，可以使用工作负载联邦或短期凭证。

身份数量不是目标。可独立授权、撤销和追责才是目标。

一个两万人企业的最小 Agent Identity Schema

企业不需要一开始就复制某个厂商的完整模型，可以先建立最小登记契约：

{
  "agent_definition_id": "agent-procurement-assistant",
  "display_name": "采购申请助手",
  "business_purpose": "为项目经理创建并提交采购申请",
  "business_sponsor": "group:procurement-product-owners",
  "technical_owner": "group:agent-platform-team",
  "security_owner": "group:enterprise-iam-security",
  "risk_tier": "MEDIUM",
  "operating_modes": ["DELEGATED_INTERACTIVE"],
  "data_domains": ["supplier", "project", "purchase"],
  "allowed_actions": [
    "supplier.search",
    "purchase_order.create_draft",
    "purchase_order.submit"
  ],
  "identity": {
    "provider": "enterprise-idp",
    "principal_id": "spn-agent-procurement-prod",
    "credential_mode": "workload-federation"
  },
  "active_version": {
    "version": "7.3.1",
    "artifact_digest": "sha256:...",
    "tool_manifest_digest": "sha256:...",
    "policy_bundle_version": "policy-2026-08-01"
  },
  "lifecycle": {
    "status": "ACTIVE",
    "review_due_at": "2026-11-01T00:00:00Z",
    "expires_at": "2027-02-01T00:00:00Z"
  }
}

这份记录不能替代 IdP、发布平台和源系统，但能把它们关联到同一个可审计对象上。

审计日志应该记录什么

一次 Agent 动作至少要关联：

agent_definition_id
agent_identity_id
agent_version_id
agent_instance_id
business_sponsor
technical_owner
subject_user（如存在）
delegation_grant_id（如存在）
action_name + action_version
mcp_client_id + mcp_server_id
policy_version
input_digest
resource_ids
approval_evidence
idempotency_key
source_system_result
post_action_readback

需要注意的是，Sponsor 是责任关系，不是运行时授权替代品。

Sponsor 对 Agent 负责，不代表 Sponsor 的个人权限会自动授予 Agent，也不代表 Sponsor 可以绕过源系统 ACL。

常见反对意见

“Service Principal 已经够了”

如果企业只有少量、长期稳定、完全自主运行的 Agent，Service Principal 加严格命名、Owner、标签、环境隔离和访问审查，确实可能够用。

但一旦需要区分业务 Sponsor、Agent 版本、动态实例、用户委托和任务级撤权，仅有 Service Principal 通常只能作为认证载体，无法独立承载完整治理模型。

“Agent 只是应用，不应该特殊对待”

从认证协议看，Agent 可以是应用。

从风险治理看，它又具有动态规划、工具选择、循环执行和代表多用户行动的特征。是否建立专门 Agent Identity，不取决于市场叫法，而取决于这些特征是否改变了授权、生命周期和审计要求。

“每个 Agent 都要 Sponsor，会拖慢创新”

没有 Sponsor 并不会消除责任，只会让责任在事故发生后才被寻找。

低风险实验可以采用团队 Sponsor、自动过期和沙箱策略；生产 Agent、写操作 Agent 和访问敏感数据的 Agent，则应有明确业务责任人。

“版本进入授权上下文太复杂”

所有变更都重新授权确实不可行。

可行做法不是忽略版本，而是按变更风险分级。只有新增工具、扩大数据范围、增加副作用或改变运行模式时，才触发更高级别的重新评审。

建议的落地顺序

第一步：盘点现有非人身份

找出所有被 Agent 使用的 Service Account、API Key、Service Principal 和 Managed Identity，重点识别共享高权限身份。

第二步：建立 Agent 登记门

生产 Agent 至少登记 Definition、Sponsor、Owner、风险等级、运行模式、数据域和动作目录。

第三步：绑定稳定身份与版本

让每次调用都能关联 Agent Identity、Agent Version 和部署环境。高风险动作拒绝无法识别版本的实例。

第四步：区分自主访问和用户委托

自主 Agent 使用自己的职责权限；代表用户时同时记录 Subject、Actor 和 Delegation Grant。

第五步：接入生命周期事件

把 Sponsor 离职、Agent 到期、版本下线、风险升级和权限审查结果接入 IAM/IGA、PDP、MCP Gateway 与任务系统。

第六步：演练撤权

验证禁用 Agent 后，新 Token、旧 Token、缓存、队列任务、运行实例和下游写入分别需要多久停止。

结论

企业过去主要管理两类行动主体：人和应用。

Agent 让两者之间出现了新的组合：

它像应用一样获取凭证和调用 API；
像员工一样接收目标、使用工具和执行业务动作；
又可能代表不同用户，在不同任务中获得临时权限。

因此，Agent Identity 的价值不是创造一种时髦账号，而是让企业重新获得几个基本能力：

可识别
可授权
可收窄
可暂停
可撤销
可追责

长期稳定的治理模型应同时保留：

Agent Definition：它为什么存在
Agent Identity：谁在认证
Agent Version：哪套行为在运行
Runtime Instance：哪个实例在执行
Delegation Grant：本次代表谁、允许做什么
Sponsor：谁对业务目的和生命周期负责
Owner：谁负责技术运维

企业 IAM 的下一个对象不只是 Agent 账号，而是围绕 Agent 建立的一整套身份、版本、责任和生命周期关系。

没有这层关系，MCP 接得越多，企业积累的就越可能不是 Agent 能力，而是一批难以撤权、无法归因的自动化影子账号。

参考资料

  1. Microsoft Entra Agent ID：What are agent identities
  2. Microsoft Entra Agent ID：Owners, sponsors, and managers
  3. Microsoft Entra Workload ID：What are workload identities
  4. OAuth 2.0 Token Exchange（RFC 8693）
  5. MCP Security Best Practices

发布摘要

当 Agent 可以代表员工调用 MCP、访问企业数据并修改业务状态时，它就不能只是一段使用共享服务账号的应用代码。本文从 Agent Identity、Version、Runtime Instance、Delegation Grant、Sponsor 和 Owner 六个对象出发，说明传统 Workload Identity 哪些能力仍可复用，企业又必须补齐哪些版本、责任、撤权和生命周期治理。

标签

AI Agent MCP IAM Agent Identity Workload Identity OAuth 2.0 权限系统 企业架构 身份治理 零信任

avatar
文章
阅读
粉丝