问题所在：智能体不是人类
当企业大规模采用 AI 智能体时，都会撞上同一堵墙：
“我们的身份系统根本不是为这个设计的。”
- Okta、Active Directory、Auth0：为人类登录应用而设计（数千名用户）
- AI 智能体：数百万个身份，7×24 小时运行，跨越组织边界
面向人类的 IAM 工具会失效：
- 🚨 智能体爆炸式增长：1,000 名员工 → 100,000 个智能体（100:1 的比例）——IAM 成本暴涨
- 🚨 无认证机制：智能体不会输入密码或点击”使用 Google 登录”——服务账户共享凭据
- 🚨 跨组织盲区：智能体跨公司交互（智能体 A → 智能体 B）——面向人类的 IAM 系统不支持组织外联合
- 🚨 生命周期混乱：智能体动态生成/终止——面向人类的 IAM 需要手动开通/注销
这不是配置问题——而是架构不匹配。
人类身份系统的设计初衷是：
- ✅ 小规模（数千，而非数百万）
- ✅ 手动流程（IT 管理员创建账户）
- ✅ 同一组织内（内部目录）
- ✅ 交互式认证（密码、MFA、SSO）
智能体身份则需要：
- ❌ 海量规模（数百万个身份）
- ❌ 自动化开通（智能体自我注册）
- ❌ 跨组织联合（智能体 A 跨边界信任智能体 B）
- ❌ 非交互式认证（密码学证明，而非密码）
这篇深度解析将阐述：
- 为什么人类身份架构对智能体行不通
- 智能体身份从根本上有何不同
- 如何构建可扩展的智能体身份系统
人类身份：遗留架构
人类 IAM 的工作原理
核心原语：
-
目录（Active Directory、Okta、Azure AD）：
- 集中式用户数据库
- 属性：用户名、邮箱、部门、角色
- 认证：密码哈希、MFA 令牌
-
认证：
- 用户输入用户名 + 密码
- 系统查询目录 → 密码匹配？→ 授予会话
- MFA：用户输入一次性验证码（短信、App、硬件令牌）
-
授权：
- 基于角色的访问控制（RBAC）：“用户 X 拥有角色 Y → 可访问资源 Z”
- 策略存储在目录或应用中
-
会话管理：
- 用户认证通过 → 签发会话令牌（Cookie、JWT）
- 令牌超时后过期（15 分钟至 24 小时）
- 用户登出 → 令牌被吊销
这对人类是可行的：
- ✅ 人类能记住密码（或使用密码管理器）
- ✅ 人类通过 UI 交互（输入密码、点击 MFA 提示）
- ✅ 人类在工作时间内操作（会话超时、重新认证可接受）
- ✅ 人类属于单一组织（单一目录）
人类 IAM 在智能体场景下的失效点
1. 规模：数百万个身份
人类规模：
- 拥有 10,000 名员工的企业 → Okta 中有 10,000 个身份
- 成本：5 美元/用户/月 × 10,000 = 每月 5 万美元
智能体规模：
- 同一家企业部署 AI 智能体 → 每名员工对应 100 个智能体（工作流自动化、客服、数据分析）
- 10,000 名员工 × 100 个智能体 = 1,000,000 个智能体身份
- 按人类 IAM 定价计算的成本：5 美元 × 100 万 = 每月 500 万美元 🚨
为什么会这样：
- 每个智能体都需要唯一身份（按智能体归因、审计追踪）
- 无法共享凭据（无审计追踪、无法吊销）
- 人类 IAM 按每个身份收费（定价模型彻底崩溃）
2. 认证：没有交互式登录
人类认证：
- 用户访问应用 → 重定向到登录页面 → 输入密码 + MFA → 携带会话令牌跳转回来
智能体认证：
- 智能体没有 UI（无法”点击”登录按钮）
- 智能体没有密码（无法记忆或输入）
- 智能体全天候运行（没有登录会话，没有超时）
当前的权宜之计：服务账户
- 在 Okta 中创建通用的”bot-user”：
service-account-bot-1 - 所有智能体共享凭据（API 密钥、OAuth 客户端密钥）
- 问题：无法按智能体归因（日志只显示”bot-1 执行了操作”，不知道是哪个智能体）
结果： 审计追踪形同虚设，无法在不影响其他智能体的情况下吊销单个智能体的访问权限。
3. 跨组织：智能体需要联合
人类 IAM（同一组织内）：
- 员工登录内部应用（Slack、JIRA、GitHub）
- 所有应用信任公司的 Active Directory（SAML、OIDC）
- 无外部信任：无法与另一家公司的 AD 联合
智能体交互（跨组织）：
- A 公司的智能体支付 B 公司的账单
- B 公司的智能体向 A 公司的 API 请求数据
- 需要跨组织信任：A 公司的智能体要向 B 公司证明自己的身份
人类 IAM 不支持联合：
- 没有内置的跨组织目录共享
- 若要实现需要：A 公司与 B 公司共享 AD（安全噩梦）
- 每个合作伙伴都要手动搭建（VPN、API 密钥、定制集成）
结果： 智能体无法跨组织边界证明自己的身份。
4. 生命周期：动态创建/终止
人类的生命周期：
- 员工入职 → IT 管理员创建账户（手动开通）
- 员工离职 → IT 管理员停用账户（手动注销）
- 频率：低（招聘/离职事件较少发生）
智能体的生命周期：
- 工作流生成智能体 → 立即需要身份（无手动开通）
- 智能体完成任务 → 终止 → 身份应立即被吊销
- 频率：高（智能体每天生成/终止数千次）
人类 IAM 需要手动开通：
- IT 管理员批准账户创建（工单、审批流程）
- 目录同步延迟（数分钟至数小时）
- 没有能”1 秒内创建 1,000 个智能体身份”的 API
结果： 智能体身份管理成为瓶颈。
智能体身份：有何不同？
核心要求
| 要求 | 人类身份 | 智能体身份 |
|---|---|---|
| 规模 | 数千 | 数百万 |
| 认证 | 交互式（密码、MFA） | 非交互式（密码学证明） |
| 范围 | 同一组织内（内部目录） | 跨组织（联合信任） |
| 生命周期 | 手动（IT 开通） | 自动化（自我注册） |
| 凭据 | 密码（可重复使用的密钥） | 密码学密钥（不可重复使用） |
| 会话 | 短期（15 分钟 - 24 小时） | 持续（7×24 小时运行） |
| 吊销 | 手动（IT 停用） | 即时（信任注册表） |
| 审计 | ”用户 X 执行了操作" | "智能体 Y（经用户 X 授权）执行了操作” |
1. 面向智能体的去中心化标识符（DID）
取代： 集中式目录（Okta、Active Directory）
使用： 去中心化标识符（DID）
原因：
- ✅ 自我主权：智能体拥有自己的 DID（没有中央目录来控制它）
- ✅ 全局唯一：DID 在任何地方都可解析（默认跨组织）
- ✅ 密码学保障：DID 包含公钥（智能体通过签名证明所有权）
- ✅ 无需按身份计费：创建 100 万个 DID → 无需按身份支付许可费
示例：
// 智能体 DID 文档
{
"id": "did:webvh:agent-12345",
"verificationMethod": [{
"id": "did:webvh:agent-12345#key-1",
"type": "Ed25519VerificationKey2020",
"controller": "did:webvh:agent-12345",
"publicKeyMultibase": "z6MkpTHR..."
}],
"authentication": ["#key-1"]
}智能体证明身份的方式：
- 智能体发送消息：“我是
did:webvh:agent-12345” - 智能体用私钥对消息签名
- 接收方根据 DID 文档中的公钥验证签名
- 无需密码，无需 MFA，无需交互式登录
2. Mandate：凭证委派式授权
取代： 存储在目录中的基于角色的访问控制（RBAC）
使用： 能证明凭证委派关系的可验证凭证（Mandate）
原因：
- ✅ 可移植：智能体随身携带 Mandate（不存储在接收方的目录中）
- ✅ 密码学可验证：Mandate 由委派方（用户或组织）签名
- ✅ 跨组织：智能体可向任意接收方出示 Mandate（无需共享目录）
- ✅ 可吊销：信任注册表将 Mandate 标记为无效（即时吊销）
示例：
// 支付 Mandate（W3C 可验证凭证）
{
"type": ["VerifiableCredential", "PaymentMandate"],
"issuer": "did:webvh:alice", // Alice 将权限委派给智能体
"issuanceDate": "2026-07-22T00:00:00Z",
"credentialSubject": {
"id": "did:webvh:agent-12345", // 智能体接收 Mandate
"authorizedActions": ["payment"],
"paymentLimit": "$10,000",
"validUntil": "2026-08-22T00:00:00Z"
},
"proof": { ... } // Alice 的签名
}智能体使用 Mandate 的流程：
- 智能体向支付处理商出示 Mandate
- 处理商验证：Alice 的签名是否有效？智能体 DID 是否匹配？是否未被吊销？
- 处理商放行支付（智能体已获 Alice 授权）
无需 RBAC——授权随智能体一同流转。
3. 信任注册表：实时授权
取代： 目录中的静态策略（更新慢，无法跨组织）
使用： 信任注册表（实时授权查询）
原因：
- ✅ 实时吊销：将智能体的 Mandate 标记为无效 → 下一次请求立即被阻止
- ✅ 跨组织查询：B 公司查询信任注册表 →“A 公司的智能体是否获得授权？”
- ✅ 动态策略：无需重新部署智能体即可更新授权规则
示例（TRQP 查询）：
POST /trqp/query
{
"agentDID": "did:webvh:agent-12345",
"action": "payment",
"context": { "amount": "$8,000", "recipient": "did:webvh:supplier-x" }
}
响应:
{
"authorized": true,
"reason": "Agent has valid payment mandate from Alice, limit not exceeded"
}如果 Alice 吊销了 Mandate：
POST /trqp/revoke
{
"credentialID": "mandate-12345"
}
# 下一次支付尝试:
POST /trqp/query { ... }
响应:
{
"authorized": false,
"reason": "Mandate revoked by issuer"
}即时吊销——无需等待目录同步。
4. 自动化生命周期管理
取代： 手动开通（IT 管理员创建账户）
使用： 自我注册 + 信任注册表验证
原因：
- ✅ 无需手动步骤：智能体自动生成 DID + 密钥
- ✅ 可扩展至数百万：创建 100 万个智能体 → 无 IT 瓶颈
- ✅ 立即终止：智能体完成任务 → 密钥被删除，Mandate 被吊销
生命周期流程：
- 智能体生成：工作流创建智能体 → 智能体生成 DID + 密钥对
- 注册：智能体在信任注册表中注册 DID（通过签名证明所有权）
- 签发 Mandate：用户/组织向智能体签发 Mandate（W3C VC）
- 智能体运行：智能体持 Mandate 执行操作（跨组织、7×24 小时）
- 智能体终止：任务完成 → 信任注册表中的 Mandate 被吊销，密钥被删除
无需人工介入——完全自动化。
架构模式
模式 1：服务账户 → 按智能体分配 DID
之前（服务账户）：
10,000 个智能体 → Okta 中 1 个共享的 "service-account-bot"
- API 密钥: abc123xyz (所有智能体共享)
- 日志: "bot 执行了操作" (无法按智能体归因)
- 吊销: 更换 API 密钥 → 所有智能体都受影响之后（按智能体分配 DID）：
10,000 个智能体 → 10,000 个唯一 DID
- 每个智能体: 拥有自己的 DID + 私钥
- 日志: "智能体 did:webvh:agent-12345 执行了操作"
- 吊销: 吊销智能体 12345 的 Mandate → 仅该智能体受影响迁移步骤：
- 部署 Agent Gateway（为智能体签发 DID）
- 智能体在信任注册表中注册 DID
- 用基于 DID 的认证取代服务账户 API 密钥
- 弃用服务账户（审计日志现在可按智能体归因）
模式 2：RBAC → Mandate（可移植授权）
之前（目录中的 RBAC）：
用户 Alice → 角色: "支付审批人" (存储在 Okta 中)
- Alice 登录支付应用
- 应用查询 Okta: Alice 拥有 "支付审批人" 角色 → 放行
- 跨组织: B 公司无法查询 A 公司的 Okta (无联合机制)之后（Mandate）：
Alice 向智能体签发支付 Mandate:
- Mandate: "智能体 12345 最多可支付 $10k" (W3C VC，由 Alice 签名)
- 智能体向 B 公司出示 Mandate
- B 公司验证: Alice 的签名是否有效？信任注册表是否确认？
- 跨组织可行: 无需访问 A 公司的目录迁移步骤：
- 识别授权策略（RBAC 角色）
- 将策略转换为可验证凭证（Mandate）
- 通过 Elements Services 向智能体签发 Mandate
- 智能体出示 Mandate 而非查询 RBAC
模式 3：密码轮换 → 密钥轮换
之前（密码轮换）：
服务账户密码每 90 天轮换一次
- IT 管理员生成新密码
- 更新所有智能体的配置 (手动或脚本化)
- 停机窗口 (智能体使用新密码重新部署)之后（密钥轮换）：
智能体的 DID 文档支持多个密钥:
- 密钥 1: 活跃 (当前使用中)
- 密钥 2: 待启用 (新密钥，尚未使用)
- 密钥 3: 已弃用 (旧密钥，宽限期内仍被接受)
轮换流程:
1. 智能体生成密钥 2，添加至 DID 文档
2. 智能体开始使用密钥 2 进行新的签名
3. 接收方同时接受密钥 1 和密钥 2 (宽限期)
4. 24 小时后，从 DID 文档中移除密钥 1
零停机——密钥轮换无缝完成。真实案例
案例 1：加密货币交易所（智能体交易）
问题： 60% 的交易由智能体执行，但日志只显示”账户 12345 执行了操作”——无法证明是哪个智能体、哪个用户授权的。
人类 IAM 方案（失效）：
- 在 Okta 中创建服务账户:
trading-bot-1 - 所有交易智能体共享 API 密钥
- 结果: 无法按智能体归因，无法吊销单个智能体的访问权限
智能体身份方案：
- 每个交易智能体获得唯一 DID:
did:webvh:agent-trader-001、did:webvh:agent-trader-002…… - 用户向每个智能体签发支付 Mandate（每笔交易上限 1 万美元，30 天后过期）
- 智能体用自己的 DID 私钥为每笔交易签名
- 交易所验证：智能体的签名 + Mandate 有效 + 信任注册表确认未被吊销
- 结果: 日志显示”由用户 did:webvh:alice 授权的智能体 did:webvh:agent-trader-001 购买了 1 枚 BTC”
审计追踪：归因完整。
案例 2：B2B 智能体支付
问题： A 公司的智能体支付 B 公司的账单。B 公司无法验证该智能体是否获得授权——缺乏跨组织信任。
人类 IAM 方案（失效）：
- B 公司无法访问 A 公司的 Okta/Active Directory
- 人工核实：电话、邮件确认、发票
- 结果: 速度慢（数天），容易被欺诈（伪造邮件）
智能体身份方案：
- A 公司向智能体签发支付 Mandate（由 CFO 的 DID 签名）
- 智能体向 B 公司出示 Mandate
- B 公司验证：CFO 的签名是否有效？信任注册表是否确认 A 公司 CFO 的授权？
- 结果: 即时验证、密码学证明，无需电话核实
跨组织信任：开箱即用。
案例 3：医疗智能体（PHI 访问）
问题： 医院的 AI 智能体访问患者病历。HIPAA 要求审计追踪：哪个智能体、哪位临床医生授权、何时授权。
人类 IAM 方案（失效）：
- 智能体共享 “ehr-bot” 服务账户
- 日志: “ehr-bot 访问了患者 12345 的病历” (无法归因到具体临床医生)
- 结果: HIPAA 审计失败——无法证明是哪位临床医生授权的
智能体身份方案：
- 临床医生向智能体签发 PHI 访问 Mandate（由该医生的 DID 签名）
- 智能体向 EHR 系统出示 Mandate
- EHR 验证：医生签名 + 信任注册表确认医生持有执业资格 + Mandate 未被吊销
- 结果: 日志显示”由临床医生 did:webvh:dr-smith 授权的智能体 did:webvh:agent-ehr-001 访问了患者 12345”
符合 HIPAA：审计追踪完整。
迁移路径：从人类 IAM 到智能体身份
阶段 1：识别智能体身份
审查现有系统：
- 有多少个服务账户？（通常：10-100 个共享账户）
- 每个服务账户对应多少个智能体？（通常：每个账户 100-1,000 个智能体）
- 智能体总数：10 个账户 × 100 个智能体 = 1,000 个无法归因的智能体
示例：
- 服务账户:
api-bot-1→ 被 500 个智能体使用 - 服务账户:
trading-bot-1→ 被 200 个智能体使用 - 服务账户:
ehr-bot-1→ 被 300 个智能体使用
总计：1,000 个智能体，3 个共享账户，零归因。
阶段 2：部署智能体身份基础设施
组件：
- Agent Gateway：为智能体签发 DID，强制执行 Mandate 验证
- 信任注册表：存储智能体授权信息，提供 TRQP 查询
- Elements Services：向智能体签发 Mandate（W3C VC）
部署方式：
- 部署 Agent Gateway（本地或云端）
- 连接信任注册表（Affinidi 托管或自托管）
- 与现有 IAM（Okta、Active Directory）集成以处理用户认证
阶段 3：为智能体签发 DID
针对每个智能体：
- 智能体生成 DID + 密钥对（Ed25519 或 ML-DSA）
- 智能体在信任注册表中注册 DID（通过签名证明所有权）
- 智能体获得唯一标识符:
did:webvh:agent-12345
大规模操作：
- 脚本: 遍历 1,000 个智能体 → 生成 DID → 在信任注册表中注册
- 耗时: 每个智能体约 1 秒 → 15 分钟内完成 1,000 个智能体
- 无需手动开通
阶段 4：将 RBAC 转换为 Mandate
针对每条授权策略：
- 识别: “用户 X 可执行操作 Y”
- 转换为 Mandate: 带有
credentialSubject.authorizedActions = [Y]的 W3C VC - 通过 Elements Services 向智能体签发 Mandate
- 智能体将 Mandate 存储在 Vault 中（设备安全隔区）
示例：
- RBAC 规则: “Alice 拥有’支付审批人’角色 → 可审批最高 1 万美元的支付”
- Mandate:
{ "issuer": "did:webvh:alice", "credentialSubject": { "id": "did:webvh:agent-12345", "authorizedActions": ["payment"], "limit": "$10,000" } }
阶段 5：替换服务账户
针对每个服务账户：
- 智能体停止使用共享 API 密钥
- 智能体改为出示 DID + Mandate
- 接收方验证: DID 签名 + Mandate 有效 + 信任注册表确认
- 逐步推行: 服务账户在迁移完成前保留宽限期（30-90 天），完成后弃用
结果：
- 之前: 3 个服务账户，1,000 个智能体，零归因
- 之后: 1,000 个唯一 DID，完整审计追踪，可按智能体单独吊销
智能体身份架构的优势
1. 可扩展性
- ❌ 人类 IAM: 5 美元/用户/月 × 100 万个智能体 = 每月 500 万美元
- ✅ 智能体身份: 无需按身份计费 → 可扩展至数百万而不会导致成本暴涨
2. 归因
- ❌ 共享服务账户: 日志显示”bot 执行了操作”（无法确定智能体身份）
- ✅ 按智能体分配 DID: 日志显示”由用户 did:webvh:alice 授权的智能体 did:webvh:agent-12345 执行了操作”
3. 跨组织信任
- ❌ 人类 IAM: 无联合机制（无法验证外部智能体）
- ✅ 智能体身份: DID + Mandate 可跨组织使用（密码学证明，无需共享目录）
4. 实时吊销
- ❌ 密码轮换: 90 天周期，所有智能体都受影响
- ✅ Mandate 吊销: 信任注册表将其标记为无效 → 下一次请求立即被阻止，仅受影响智能体受限
5. 自动化生命周期
- ❌ 手动开通: IT 管理员创建账户（瓶颈）
- ✅ 自我注册: 智能体自动生成 DID（可扩展至数百万）
开始构建智能体身份
用智能体身份架构取代人类 IAM 工具：
- 部署 Agent Gateway：为智能体签发 DID
- 接入信任注册表：实时授权查询
- 签发 Mandate：将 RBAC 策略转换为 W3C VC
- 迁移智能体：用按智能体分配的 DID 取代服务账户
文档：
相关资源
技术深度解析
- 去中心化标识符（DID） - 智能体如何获得唯一身份
- 可验证凭证 - Mandate 的工作原理
- DIDComm 消息传递 - 智能体之间如何通信
相关解决方案
总结
人类 IAM 工具在 AI 智能体场景下会失效：
- ❌ 规模（数千 → 数百万个身份）
- ❌ 认证方式（密码/MFA → 密码学证明）
- ❌ 跨组织能力（同组织目录 → 联合信任）
- ❌ 生命周期（手动开通 → 自动化自我注册）
智能体身份需要：
- ✅ DID：自我主权、全局唯一、密码学保障
- ✅ Mandate：可移植授权（W3C VC）
- ✅ 信任注册表：实时授权 + 即时吊销
- ✅ 自动化生命周期：自我注册，无需手动开通
迁移路径：
- 审查：统计服务账户数量以及每个账户对应的智能体数量
- 部署：Agent Gateway + 信任注册表 + Elements Services
- 签发：为所有智能体签发 DID（自动化）
- 转换：RBAC 策略 → Mandate（W3C VC）
- 替换：服务账户 → 按智能体分配的 DID（逐步推行）
结果： 可扩展、跨组织、可审计的智能体身份体系——专为数百万个跨组织边界 7×24 小时运行的智能体而构建。