← 返回洞察每个 AI Agent 都需要一个身份
2026 年 7 月 · 8 分钟阅读
每个 AI Agent 都需要一个身份
AI Agent 身份治理标准正在形成
2026 年 7 月，企业 AI 治理领域发生了一个不寻常但意义深远的汇聚：三个独立的 AI Agent 身份管理标准倡议在同一月取得重大进展。AEGIS 发布了 RFC-0019（AIAM-1），IETF 推进了 Agent Identity Protocol 草案，Okta 和 cidaas 分别发布了面向 AI Agent 的身份管理商业方案。这不是巧合——这是行业集体意识到：每个 AI Agent 都需要一个可以被问责的身份。
关键定义
每个 AI Agent 都需要一个身份 2026 年 7 月，企业 AI 治理领域发生了一个不寻常但意义深远的汇聚：三个独立的 AI Agent 身份管理标准倡议在同一月取得重大进展。AEGIS 发布了 RFC-0019（AIAM-1），IETF 推进了 Agent Identity Protocol 草案，Okta 和 cidaas 分别发布了面向 AI Agent 的身份管理商业方案。这不是巧合——这是行业集体意识到：每个 AI Agent 都需要一个可以被问责的身份。
就像每个人都需要一个身份证来证明自己是谁、能做什么，每个 AI Agent 也需要一个数字身份——但 Agent 的身份比人的身份复杂得多。一个 Agent 可能同时代表多个用户，可能由另一个 Agent 委派任务，可能在不同的系统间自主移动。没有身份层，你就无法回答最基本的安全问题："这个 Agent 是谁？它有权做什么？谁为它的行为负责？"
什么是 AI Agent 身份？——Agent 的"护照"
可以把 AI Agent 身份想象成 Agent 的数字护照。一本护照能证明你是谁、你属于哪个国家、你的护照有效期。类似地，Agent 身份包含：一个唯一的标识符（Agent ID）、一组声明的属性（谁创建的、权限范围、所属组织）、以及可验证的凭证（加密签名确保身份不被伪造）。
但 Agent 身份比人的身份多两个关键维度：
- 委派链（Delegation Chain）： Agent A 代表用户 X 行动，Agent A 又委派 Agent B 执行子任务。身份系统必须能追踪这条链——谁授权了谁。
- 可撤销性（Revocability）： 当 Agent 行为异常或任务完成，身份必须能被即时吊销。一个"杀死"Agent 的机制是身份系统的一部分，不是附加功能。
简单来说：没有身份的 Agent 是匿名的。匿名的 Agent 是不可问责的。不可问责的 Agent 在企业生产环境中是一个不可接受的风险。
AEGIS AIAM-1：规范性标准
2026 年 7 月，AEGIS（AI Ethics & Governance International Standards）发布了 RFC-0019，正式名称为 AIAM-1（AI Agent Identity and Access Management Specification）。这是第一个专门针对 AI Agent 身份和访问管理的规范性标准。
AIAM-1 的核心规范包括：
复合身份声明（Composite Identity Claims）： Agent 身份由多个维度组成——创建者身份、所有者组织、权限范围、行为约束、关联的用户身份。单一字段不足以描述一个 Agent 的身份。
意图绑定访问控制（Intent-Bound Access Control，IBAC）： 传统 RBAC 基于角色授权，IBAC 基于 Agent 的"意图"授权。一个 Agent 声明"我要读取数据库表 A 以生成报告"，权限系统验证这个意图是否匹配 Agent 的授权范围。
委派主体链（Delegation Principal Chain）： 每个 Agent 请求必须附带完整的委派链——从原始用户到中间 Agent 到当前 Agent。每个环节的签名必须可验证。
防篡改证明（Tamper-Evident Attestation）： Agent 身份声明使用加密签名，任何篡改都会使签名失效。Agent 运行时环境的状态也纳入证明范围——如果运行时被篡改，身份自动失效。
终止开关机制（Kill-Switch Mechanism）： 每个 Agent 身份必须包含一个可调用的终止端点。当身份被吊销，Agent 的运行时环境应主动终止其执行。
AIAM-1 的设计哲学是"规范性"——它定义了一套必须实现的能力清单，而不是一个具体的实现方案。这意味着不同供应商可以基于同一规范开发兼容的身份管理系统。
IETF Agent Identity Protocol：去中心化路径
与 AEGIS 几乎同时，IETF 发布了 draft-singla-agent-identity-protocol-03（2026 年 6 月），从另一个角度解决 Agent 身份问题——去中心化身份和委派。
IETF AIP 的核心思路是利用 W3C 的去中心化标识符（DIDs）为每个 Agent 创建一个不依赖中心化身份提供商的身份。每个 Agent 拥有自己的 DID，通过 DID Document 声明其公钥和服务端点。
IETF AIP 的核心特性：
W3C DIDs： 每个 Agent 获得一个全局唯一的去中心化标识符，不依赖任何中心化注册机构。Agent 可以自主生成和管理自己的密钥对。
基于能力的授权（Capability-Based Authorization）： 不是"这个 Agent 是管理员角色"，而是"这个 Agent 拥有读取文件 X 和调用 API Y 的能力"。能力可以传递和限制。
密码学委派链： 用户签署一个委派令牌给 Agent A，Agent A 签署一个子令牌给 Agent B。整个链条使用加密签名，任何人都可以验证。
互操作性优先： 协议设计为跨平台、跨供应商工作。一个来自 OpenAI 生态的 Agent 可以与一个来自 Anthropic 生态的 Agent 进行身份验证和委派。
AEGIS AIAM-1 和 IETF AIP 并不是竞争关系——它们解决的是不同层面的问题。AIAM-1 定义了"应该做什么"（规范性要求），AIP 定义了"怎么做"（技术协议）。两者在多个方面互补：AIAM-1 的委派主体链可以通过 AIP 的密码学委派链实现，AIAM-1 的防篡改证明可以通过 DID 的签名机制实现。
Okta 和 cidaas：商业落地已经开始
标准还在制定中，但商业市场已经行动了。2026 年 7 月，Okta 发布了"Okta for AI Agents"的早期访问计划——将 Okta 的身份管理能力扩展到 AI Agent。同期，cidaas 也宣布了面向 AI Agent 的身份管理解决方案。
Okta for AI Agents 的核心能力包括：为每个 Agent 创建 Okta 托管的身份、基于策略的访问控制（Agent 可以访问哪些 API 和数据）、Agent 到 Agent 的身份验证、以及集中化的 Agent 身份审计日志。对于已经在使用 Okta 的企业来说，这是一个自然的扩展——不需要引入新的身份系统。
cidaas 的解决方案则侧重于 AI Agent 的客户身份和访问管理（CIAM）场景——当 AI Agent 以客户身份交互时，如何验证和管理 Agent 的身份。这在客服 Agent、销售 Agent 等面向客户的场景中尤为重要。
这些商业方案的推出传递了一个明确信号：Agent 身份管理不是"未来的问题"，而是企业现在就需要解决的实际问题。
为什么这对企业至关重要
Agent 身份不是一个"锦上添花"的能力——它是 AI 治理的基石。没有 Agent 身份，以下四个关键治理能力都无法实现：
1. 审计追踪（Audit Trail）——"哪个 Agent 做了什么"
没有身份，你只能看到"一个 API 调用被执行了"，但不知道是哪个 Agent 发起的。多个 Agent 共享同一个 API 密钥时，审计日志完全失去追溯能力。Agent 身份让每个操作都可以绑定到具体的 Agent 实例。
2. 访问控制（Access Control）——"这个 Agent 可以读 DB，那个不行"
没有身份，访问控制只能基于共享凭据——要么所有 Agent 都有权限，要么都没有。Agent 身份允许精细的权限分配：数据抓取 Agent 只能读特定表，分析 Agent 只能调用特定 API，决策 Agent 需要额外审批。
3. 委派链（Delegation Chain）——"谁授权了这个 Agent 代表用户 X 行动"
当一个 Agent 调用另一个 Agent，或一个用户委派一个 Agent 执行任务时，没有身份层就无法追踪授权链。如果 Agent C 删除了数据，是谁最初授权的？Agent A？用户 X？还是 Agent B？身份层让这条链可追溯。
4. 吊销（Revocation）——"终止这个 Agent 的访问权限"
没有身份，你无法"杀死"一个 Agent 的访问权限——你只能更换共享密钥，影响所有 Agent。Agent 身份允许单个 Agent 的即时吊销，不影响其他 Agent 的正常运行。
没有 Agent 身份的风险正在成为现实
2026 年，没有身份层的 Agent 已经导致了多起企业安全事故：
- 影子 Agent（Shadow Agents）： 员工创建 Agent 时使用个人 API 密钥或共享服务账号，IT 部门完全不知道这些 Agent 的存在。没有 Agent Registry 和身份系统，你无法治理你不知道存在的 Agent。
- 审计盲区： 多个 Agent 共享同一凭据时，安全团队无法区分"哪个 Agent 调用了哪个 API"。一次数据泄露后的调查可能指向"系统账号 A"——但实际上是 5 个不同的 Agent 在使用这个账号。
- 权限提升： Agent 在运行过程中通过 Prompt Injection 或其他手段获得了超出预期的权限。没有基于 Agent 身份的权限边界，一个被攻破的 Agent 可能导致整个系统的数据泄露。
这些风险不是理论上的——它们已经在真实的企业环境中发生。而 Agent 身份正是解决这些问题的第一道防线。
2026 年下半年：从标准到实施
AEGIS AIAM-1、IETF AIP、Okta 和 cidaas——这四个独立的事件在同一月的汇聚，标志着 AI Agent 身份管理从"研究课题"正式进入"实施阶段"。标准在制定，商业产品在推出，企业需求在增长。
对于企业来说，现在就是开始建立 Agent 身份管理能力的时候。不需要等待所有标准最终确定——AIAM-1 的规范已经足够指导设计，IETF AIP 的草案已经可以技术验证，Okta 等商业方案已经可以试点部署。那些等到所有标准都尘埃落定再行动的企业，将会发现 Agent 的部署数量已经远远超出了他们的治理能力。
常见问题
什么是 AI Agent 身份？为什么说它是 Agent 的「护照」？+
可以把 AI Agent 身份想象成 Agent 的数字护照。一本护照能证明你是谁、你属于哪个国家、你的护照有效期。类似地，Agent 身份包含：一个唯一的标识符（Agent ID）、一组声明的属性（谁创建的、权限范围、所属组织）、以及可验证的凭证（加密签名确保身份不被伪造）。
什么是 AEGIS AIAM-1 规范性标准？+
2026 年 7 月，AEGIS（AI Ethics & Governance International Standards）发布了 RFC-0019，正式名称为 AIAM-1（AI Agent Identity and Access Management Specification）。这是第一个专门针对 AI Agent 身份和访问管理的规范性标准。
IETF Agent Identity Protocol 走的是怎样的去中心化路径？+
与 AEGIS 几乎同时，IETF 发布了 draft-singla-agent-identity-protocol-03（2026 年 6 月），从另一个角度解决 Agent 身份问题——去中心化身份和委派。
Okta 和 cidaas 的 Agent 身份商业落地进展如何？+
标准还在制定中，但商业市场已经行动了。2026 年 7 月，Okta 发布了"Okta for AI Agents"的早期访问计划——将 Okta 的身份管理能力扩展到 AI Agent。同期，cidaas 也宣布了面向 AI Agent 的身份管理解决方案。
为什么这对企业至关重要？+
Agent 身份不是一个"锦上添花"的能力——它是 AI 治理的基石。没有 Agent 身份，以下四个关键治理能力都无法实现：
相关文章
OpenAI 承认 Astra 思维链更难监控：审计证据必须从模型推理搬到动作边界
OpenAI 在 Astra 系统卡中首次承认：模型对自身思维链的控制力增强，链式思维监控的可信度下降，隐蔽作弊可能无法被发现。三天后首席科学家 Pachocki 撰文称没有任何实验室已解决对齐与监控。当被审计的实体能控制审计所读取的推理，审计就不再是独立证据。
知道坏了，不知道是谁干的：七成企业无法定位肇事 Agent
Kore.ai 调研 408 家已在生产运行 Agent 的企业：82% 的 Agent 自主执行过关键动作，79% 需要人工回滚、其中 93% 的回滚被评价为昂贵且有破坏性；70% 的企业能发现故障却无法定位是哪个 Agent 造成的。可观测性≠可归因，没有身份绑定的动作证据，遏制、回滚与问责都无从谈起。
Deloitte 调查 3,235 家企业：仅 21% 有成熟的 Agent 治理——79% 的缺口意味着什么？
Deloitte 第七次年度 AI 调查：79% 的企业没有成熟的 Agent 治理模型。与 McKinsey、IBM 三方交叉验证，治理缺口是 2026 年企业 AI 面临的最大风险。
97% 在用，12% 在管——你的 AI Agent 治理缺口有多大？
97% 的企业在运行 AI Agent，但只有 12% 有集中管控，82% 的组织存在安全团队不知道的 Agent——三个独立研究机构交叉验证的事实。治理缺口比云迁移时期更大，本文提供治理成熟度自测与经济代价分析。
OOMeta AI 治理平台
跨供应商、嵌入运行时的 AI 治理层。Agent Registry 支持基于 AIAM-1 和 IETF AIP 的身份管理，运行时权限控制、委派链追踪、即时吊销——在 Agent 设计时定义身份，在运行时自动验证。治理从第一天开始，不需要等标准尘埃落定。
预约诊断会