给 Agent 发身份证：标识、认证、登记三道关

2026 年 7 月 2 日，Stripe 和 Cross River 银行宣布：AI Agent 可以领银行级一次性虚拟卡，自己刷卡，碰不到你的真实卡号。我在上一篇支付的文章里把它拆成授权、结算、追责三道关——前两关的工程答案已经跑通，第三关还悬在法律侧。

但支付链上还有一个更前置的问题，比"错了谁担"更早撞上：这个刷卡的 Agent，到底是谁？

不是哲学问题，是工程硬门槛。没有可验证的身份，Mandate 授权令不知道绑在谁身上；MCP 直连数据库里的 OBO 身份传播不知道"替谁在问"；责任篇里多 Agent 交接的归因链，第一环就断了。支付、数据、追责三条线，此刻都指向同一件事：Agent 需要一张"身份证"——不是营销话术，是可登记、可认证、可注销、可审计的数字身份。

2026 年上半年，这件事从"各做各的"变成了"国家队和标准机构同时下场"。

一、为什么是现在：从"服务账号"到"自主行动者"

传统 IT 里，非人类身份长期被当成服务账号的变种：一个高权限 API Key、一张长期有效的证书、一套共享凭据，跑在 cron 或工作流后面，出了事往往只能追到"某个系统"，追不到"哪个 Agent、替谁、在什么任务上下文里干的"。

Agent 把这个模糊地带彻底暴露了，而且是以机器速度暴露的：

• 自主执行变长：Agent 可以无人值守跑几小时，中间 spawn 子 Agent、跨系统调用工具，凭据生命周期和人类账号完全不是一回事；
• 多跳委托变常见：客服 Agent 替用户退款是一跳，编排器 Agent 雇数据分析 Agent 再雇写库 Agent 是三跳——每一跳都需要知道"谁在替谁行动"；
• 概率式行为放大风险：同一个 Agent ID 这次查报表、下次可能写出越界 SQL 或错付款项，身份如果不能和任务边界、授权范围绑在一起，审计就是空壳。

NIST 在 2026 年 2 月正式启动 AI Agent Standards Initiative，首份概念文件《Accelerating the Adoption of Software and AI Agent Identity and Authorization》问了一个特别务实的问题：现有身份标准能不能直接给 Agent 用，还是必须从零重造？ 答案倾向后者里的"适配"——OAuth 2.0/2.1、OpenID Connect、SPIFFE/SPIRE、SCIM、NGAC，再加上 MCP，先拿来改，别急着发明新宗教。

几乎同时，国内路径也清晰了：2026 年 5 月 8 日，网信办、发改委、工信部联合发布《智能体规范应用与创新发展实施意见》，明确推动智能体互联协议（AIP）等国标应用；《人工智能 智能体互联》系列 7 项国标进入报批，中国电子技术标准化研究院牵头开源参考实现，智能体身份码（AIC）基于国家 OID 体系申领、上链注册，先锋计划已在招募实测伙伴。

大洋两岸，措辞不同，骨架相似：标识、认证、登记，再加一层多 Agent 交接时可追溯的委托链。

二、先认清：没有身份，三道关都会塌

在拆三道关之前，得看清"没身份"在生产里长什么样——很多团队是在"以为服务账号够用"的情况下就把 Agent 接进了支付、数据库和对外 API。

典型症状有三类：

1. 万能凭据：全公司 Agent 共用一个 API Key 或数据库账号，和MCP 那篇批判的"万能账号"是同一个坑，只是换了个 Agent 皮肤；
2. 身份与任务脱节：凭据长期有效、权限宽泛，Agent 换了一个 prompt 或子任务，身份上下文却没变——授权边界和实际行为对不上；
3. 多跳即断链：A 调 B、B 调 C，中间只有 HTTP 日志，没有可验证的"委托关系"记录，出事只能猜。

这三类合在一起，会直接击穿你已经建好的其他关：支付里的 Mandate 再漂亮，绑不到具体 Agent 实例；数据库 OBO 再标准，多跳之后 attenuation（权限收敛）没法审计；责任险和监管问询要归因时，第一问"是哪个主体干的"就答不上来。

所以身份不是"安全加分项"，是支付授权、执行下沉、责任定价的公共底座。这也是组织边界篇把"Agent 身份、登记、可追责"写进"薄协议腰"的原因——腰上如果连"谁"都说不清，发现、交易、结算全是空中楼阁。

那么这张"身份证"到底怎么发？可以拆成层层递进的三道关：先给 Agent 一个稳定的标识（你是谁），再给它一套会过期的认证凭据（此刻怎么证明），最后用登记把前两者变成可治理、可互认、可追溯的制度（谁发证、谁注销、出事查谁）。三关缺一，信任就建不起来。下面逐关拆开。

三、第一道关·标识：先回答"你是谁"

第一道关要解决的问题最朴素：在系统里，这个 Agent 有没有一个稳定、可解析、可对外互认的 ID？

不是"这次请求带了个 Bearer token"，而是：跨会话、跨平台、跨域协作时，别人能不能引用同一个主体？

国际上，NIST 概念文件把方向压在成熟标准上：SPIFFE ID 给工作负载一个 URI 形态的身份，SPIRE 负责签发与轮换；OAuth/OIDC 生态里则用 client_id、subject、actor 这几类声明的组合，来指代"软件主体"。Google 的 A2A、Anthropic 的 MCP，也各自补上了"Agent 描述"和"工具调用方是谁"。但这些都停在单一生态内部——跨厂商互认始终缺一个统一的登记层。

国内路径更具体：《人工智能 智能体互联》国标体系里的 AIC（Agent Identity Code，智能体身份码），按国家 OID 体系编制，作为智能体在全链路协作中的"数字身份证"。AIP 开源社区把能力拆成六大模块——身份码、身份管理、智能体描述、发现、交互、工具调用——标识是其余五块的起点：没有 AIC，发现与交互就退化成匿名广播。

工程上，标识关要满足四条：

• 全局可解析：ID 格式遵循公开规则（OID、URI 等），不能只是厂商内部自增整数；
• 与类型/版本可绑：同一开发者的"财报分析 v2"和"客服草稿 v1"应是不同标识，不能共用一个模糊"AI 服务"；
• 与人/组织主体可关联：Agent 背后必有法律或管理意义上的责任锚点（开发者、运营方、委托用户）；
• 可发现可引用：别的 Agent 或平台能通过注册表解析这个 ID 的含义与公钥/元数据，而不是靠私下抄一串 UUID。

很多团队以为"给 LLM 起个名字"就算标识。那是产品名，不是身份。真正的标识关，是让"名字"变成可验证的"证号"。

四、第二道关·认证：你怎么证明"你就是那个你"

有了证号，还要回答：当前这次行动，凭什么相信你是持证主体，而不是偷来的 Key？

NIST 强调的四个主题里，至少两个落在这里：强认证（别再用共享 API Key 糊弄）和最小权限（Agent 行为不可完全预测，默认权限必须窄、必须短）。

和第一道关的分工可以这样记：

• 标识回答"你是谁"（相对稳定的身份）；
• 认证回答"你此刻怎么证明"（随任务变化的凭据）。

工程上，认证关的主流方向是任务级、会过期的收敛凭据，而不是把人类用户的长期 token 直接塞给 Agent：

• OAuth 2.0 On-Behalf-Of（OBO）/ RFC 8693 token exchange：用户授权给 Agent A，A 向授权服务器换一张代表用户、但范围更窄的 token 去访问下游——MCP 直连数据库第二道关的核心就是这个，禁止把用户 token 原样透传；
• SPIFFE SVID：工作负载之间用短期自动轮换的证书说话，适合服务网格里的 Agent 到 Agent 调用；
• AP2 Mandate / Stripe SPT：支付场景把"意图与边界"压进可验证令牌——身份与授权上下文绑在一起，和认证关逻辑同构。

共同原则是：人类账号可以几年不换密码，Agent 凭据不该。 每次任务签发、任务结束吊销、权限随委托链逐跳收敛（attenuation），才是 Agent 时代的默认姿势。

NIST 也明确点出一个仍未闭合的硬问题：多跳委托（multi-hop delegation）。单跳 OBO 今天能跑通——客服 Agent 替用户退款。难的是 Agent A spawn Agent B，B 再调 Agent C：每一跳如何携带、压缩、审计委托关系？概念文件把它列为开放题，NCCoE 计划用参考实现探路。谁先把多跳身份链做稳，谁就扼住了多 Agent 编排的咽喉——这道题第七节会专门拆。

五、第三道关·登记：谁签发、谁注销、出事查谁

有 ID、有凭据，还差最后一环：谁承认你、谁给你发证、谁在你违规或退役时把你从网络里摘掉？

这就是登记（registration）关。它把标识和认证从"技术约定"变成"可治理的制度"：

• 注册表：记录 Agent 元数据——责任主体、能力声明、密钥材料、状态（活跃/暂停/注销）；
• 全生命周期：申领、更新、轮换、注销，和责任篇强调的"交接级审计链"同源——身份不是一锤子买卖；
• 跨域互认：A 平台的 Agent 到 B 平台干活，B 要能查登记记录、验证签发方，而不是默认信任一个陌生 JWT；
• 行为可回溯：国内 AIP 强调上链注册与行为审计，把"谁登记、谁签发、何时注销"留成争议时可举证的记录。

没有登记关，标识和认证会退化成自说自话的 JWT：任何内部系统都能自己签一张"我是 Agent"，对外互认和监管问询时一张废纸。

国内工程化路径已经动起来：AIP 应用验证先锋计划要求伙伴申领 AIC、改造接入、跨协议互通测试（兼容 MCP/A2A 等），CESI 提供自治域中心节点和互联平台测试环境。这和 NIST 侧"行业主导标准 + 开源协议 + 政府研究"的三柱计划，形成有趣的平行：都在补登记层与实测样板，而不是再写一份空洞白皮书。

六、协议腰：AIP、MCP、A2A 与 NIST 六标准怎么叠

身份关容易掉进一个坑：把"发身份证"做成又一家中心化平台垄断一切。组织边界篇提醒过"厚腰/聚合者悖论"——薄协议腰若被少数玩家把持，去中心化叙事会反转。

更稳妥的视图是分层叠腰，而不是"选一个协议干掉其他"：

• 执行层：各业务系统、支付网络、数据库引擎——消费身份，不定义身份；
• 工具/上下文层：MCP 把 LLM 接到工具，授权实现留给你，但生产部署必须接认证（WorkOS、AuthKit for MCP 等方案已经往这走）；
• 任务互操作层：A2A 等协议描述 Agent 之间如何委托任务、回传结果；
• 互联登记层：AIP 国标侧覆盖身份码、发现、跨域协作、行为审计，补齐 MCP/A2A 在跨组织身份互认上的缺口；
• 通用身份标准层：OAuth/OIDC/SPIFFE/SCIM——NIST 点名的六件套，负责"别重造轮子"。

MCP 擅长"一个 Agent 调一组工具"，A2A 擅长"两个 Agent 谈一笔任务"，AIP 国标路径更强调多中心互联 + 国家级身份码 + 审计闭环。它们是同一栈的不同层，竞争叙事往往被厂商放大，工程上更常见的是MCP 接入工具、A2A 谈委托、AIP/注册表管身份互认的组合拳。

NIST 首份概念文件的潜台词也很清楚：适配，而非重造（adaptation, not invention）。对国内企业，这意味着身份项目应优先对接现有 IdP（身份提供商）、IAM、API 网关和日志栈，再叠 AIC/AIP 的登记与互认要求——而不是另起炉灶做一个"Agent 专用账号体系"，和 HR 离职流程、密钥轮转、审计平台全脱节。

七、多 Agent 交接：身份必须"每跳收敛"

回到第四关末尾埋下的那道开放题。单 Agent 场景，三道关做完大半已经能跑；真正拷打架构的，是多 Agent 编排——也正是责任篇和 BTLJ 2026 年讨论的跨厂商委托链。

每一次 handoff，至少要留下四个可验证字段：

1. 上游 Agent ID（谁委托）；
2. 下游 Agent ID（谁承接）；
3. 委托范围（允许做什么、额度/数据域/工具列表）；
4. 责任主体链（开发者、运营方、最终用户锚点）。

OAuth OBO 的单跳模型是模板：每一跳换一张新 token，范围不比上一跳更宽。 多跳若做不到这一点，就会出现"编排器拿了用户全权，子 Agent 继承全权，孙 Agent 还能再转发"的爆炸半径。OpenTelemetry 的 agent spans 是观测起点，但观测不能替代密码学上可验证的委托记录——审计链要能和登记系统、授权令牌交叉印证，否则只是"看得见的扯皮"。

支付、数据库、对外 API 三条线在此汇合：

• 支付：Mandate 写清意图边界，需要绑 Agent ID 与商户上下文；
• 数据库：OBO 写清"替谁查"，需要绑数据库角色与行级策略；
• 责任：归因税要求每个交接点可举证——身份是唯一能把三处日志钉成同一根故事线的钉子。

八、工程落地：现在可以做的清单

标准和国标还在演进，但 NIST 和企业实践的共识已经够落地：

1. 清点非人类身份存量
把服务账号、API Key、证书、自动化脚本里藏着的"Agent 行为"全捞出来。很多团队会发现生产里的 Agent 化程度比自己以为的高。

2. 给 Agent 单独建生命周期
申领、绑定责任主体、任务级签发、到期自动吊销、人员离职/版本下线时同步注销——接入现有 IAM/SCIM，别让人工清 Key 成为唯一手段。

3. 标识先行，认证跟上，登记收口
先保证每个对外行动的 Agent 有稳定 ID 和登记记录，再改 OBO/Mandate，最后接 AIP/AIC 或 SPIFFE 等互认层。顺序反了，会在互认测试时推倒重来。

4. 多跳委托当显式架构题
在编排器设计阶段就画委托链，不允许"隐式继承用户全权"。单跳 OBO 能跑通不等于多跳安全，NIST 已把它标为开放题——你的系统别假装已解。

5. 和支付、数据关一起验收
身份项目不是安全团队的旁支。上线 checklist 里同时问：Mandate 绑了谁？数据库 OBO 替谁？日志里能不能串成一条人 → Agent → 子 Agent → 工具的链？

九、ICE 观察

技术层面：Agent 身份的主旋律是复用成熟标准 + 补登记与多跳委托两块短板。OAuth/OIDC/SPIFFE/MCP 解决大部分认证与工具接入；AIC/AIP 国标与 NIST 倡议补上跨域互认、生命周期登记、行为审计这些 MCP/A2A 单独覆盖不了的层。多跳委托仍是全行业的开放题，也是技术护城河所在。

落地层面：身份是三道关里最该先于支付和数据库去建的一层——没有标识和登记，授权令牌和责任归因都是无根之木。企业最容易犯的错，是用"内部 UUID + 长期 Key"冒充身份体系，等到要上跨部门 Agent、要对监管举证时才一次性爆雷。优先级建议：清点存量 → 生命周期 → 单跳 OBO/Mandate → 多跳委托设计 → 互认国标试点。

本土视角：国内节奏并不慢——实施意见、国标报批、AIC 申领、先锋计划已经把"身份证"从新闻标题推进到实测入口。真正要盯的不是"有没有国标"，而是国标能否和你现有的 IdP、数据平台、支付授权串成一条链，而不是再多一个孤岛注册中心。对做 Agent 平台、数据治理、行业互联的团队，谁能把 AIC 登记、MCP/A2A 接入、行为留痕做成一体化交付，谁就在卖"信任精品店"的入场券——这和责任篇的逻辑一致：出事可追到、可举证、可对接监管，比多一个聊天框值钱得多。

结尾

Stripe 让 Agent 能刷卡，把身份问题从后台搬到了前台：没有身份证，就没有可追溯的授权；没有登记，就没有可互认的信任；没有多跳委托链，组织边界解绑到一半就会因归因崩溃而重新收紧。

2026 年的信号很清楚：NIST 在定义"怎么适配旧标准"，中国在推"怎么登记新主体"。两条路并不矛盾，都在回答同一个问题——当软件开始长期替人行动，"谁"必须像"钱"和"数据"一样，被严肃地命名、认证、登记、注销。

Agent 时代的竞争，不只会发生在模型能力上，也会发生在谁能把身份这三道关做成默认基础设施。在那之前，每多放一个长期有效的万能 Key 到生产环境，都是在给未来的自己埋一张说不清的责任账单。