AIP：面向Agent的身份认证协议

今天大家谈 MCP，谈 A2A，谈多智能体协作，更多是在解决”怎么连起来""怎么把工具调起来""怎么把任务分出去”的问题。但一旦 Agent 真开始替人做事，系统很快就会遇到另一个更棘手的问题：到底是谁授权它做这件事的？它把任务再转给别的 Agent 时，权限有没有被收紧？最后交回来的结果，又该怎么追溯？ 这正是今天介绍的这篇论文想补的空白。

论文标题叫《AIP：Agent Identity Protocol for Verifiable Delegation Across MCP and A2A》，核心目标就是给 Agent 世界补上一层”身份认证 + 可验证委托 + 可审计留痕”的协议层。

https://arxiv.org/pdf/2603.24775

MCP 和 A2A 没有解决委托问题

论文开头的判断非常直接：MCP 解决的是工具调用，A2A 解决的是 Agent 之间的协作，但二者都没有从协议层把”谁可以代表谁、把什么权限委托给谁、委托链条如何验证”这件事彻底说清楚。作者举了一个很典型的例子：Agent A 把一个任务委托给 Agent B，B 再去调某个 MCP 工具。此时系统通常缺三样东西：

一、无法严格验证 A 是否真的有权发起这次委托；

二、无法保证 B 拿到的权限一定比 A 更小；

三、无法把这条委托链和最终执行结果绑定成一个可审计的证据链。

论文引用的一项扫描甚至声称，约 2000 个 MCP 服务器样本里都缺少认证机制。不过这里要注意一个容易被误读的点：MCP 官方规范本身并不是”完全没有授权”，官方文档已经给出了基于 OAuth 2.1 的授权机制，允许 MCP server 作为 OAuth 资源服务器，client 作为 OAuth client 来访问受保护资源。AIP 真正想补的，不是”单跳有没有认证”，而是”多跳委托链能不能被持续验证”。

AIP 的核心：把委托链做成一等公民

AIP 的核心构件叫 IBCT，全称是 Invocation-Bound Capability Tokens。可以把它理解成一种”绑定调用的能力令牌”。它和普通 access token 最大的不同在于，普通 token 更多只是证明”你现在能访问什么”，而 IBCT 试图同时证明五件事：是谁授权的、委托经过了哪些 Agent、每一跳缩到了什么权限、最终做了什么、结果有没有被独立验证。论文里明确写到，一个完成态的 IBCT 就是要把这五个问题装进同一个工件里。

为了做到这一点，IBCT 被设计成了一个可追加、不可篡改的链式结构。它一般由三类 block 构成。

第一类是 Authority Block，也就是根授权块，定义整条链的起点身份、初始权限范围、预算上限、最大委托深度和过期时间；

第二类是 Delegation Block，也就是委托块，每次有 Agent 往下委托时，就追加一个新的块，同时必须把权限进一步收窄，并写清楚委托的上下文；

第三类是 Completion Block，也就是完成块，执行者在任务结束后可以写入结果哈希、验证状态、资源消耗和成本。

换句话说，AIP 不只是想证明”谁在调工具”，而是想把”谁在把什么权力转包给谁”也变成协议本身的一部分。

只能缩权，不能扩权

AIP 最有价值的设计，不是用了 JWT，也不是用了 Biscuit，而是它把”权限衰减”做成了硬约束。论文里明确写到，每个委托块都必须是父块权限的子集；如果某个 Agent 试图在下游 block 里扩大工具范围、提高预算、延长有效期，验证就会失败。也就是说，AIP 不是只解决”身份是谁”，还同时解决”身份拿到的权，能不能在传递过程中偷偷变大”。这点对 Agent 世界尤其关键，因为 Agent 和传统 API client 最大的不同，就是它天然更容易发生”链式执行”和”层层转包”。

论文还专门加入了两个非常工程化、也非常有现实意义的限制。第一是 max_depth，也就是最大委托深度，防止委托无限外溢；第二是 non-empty context，要求每个 delegation block 都必须带上非空 context，说明”为什么要委托”。这两个约束听起来很朴素，但意义很大。前者是在限制系统复杂度和权限蔓延，后者则是把”留痕”从日志层抬到了协议层：不是想记就记，不想记就算，而是不写明委托原因，链条本身就不合法。

论文后面的对抗测试也恰好证明，这两个约束正是普通 JWT 方案抓不到、AIP 能独立抓到的地方。

AIP 为什么要同时支持两种模式

从实现上看，AIP 没有强行把所有场景都塞进一套重型机制里，而是分成了 compact mode 和 chained mode 两种模式。compact mode 走的是 EdDSA 签名的 JWT，更适合单跳场景，比如一个 Agent 直接调用一个 MCP 工具；chained mode 则基于 Biscuit token 和 Datalog 策略，更适合多跳委托、跨组织协作和需要审计链的场景。

这个分层其实很合理，因为并不是所有 Agent 场景都需要复杂 delegation graph。很多时候，一跳调用用轻量 JWT 就够了；但只要出现 Agent 调 Agent，再落到工具执行，链式模式的价值就出来了。

这篇论文还有一个值得注意的点：它没有把身份解析设计得特别重。AIP 支持两种 identity scheme，一种是基于域名和 well-known 文档的 aip:web，适合长期运行、由组织托管的 Agent；另一种是 aip:key，也就是自证身份，标识符里直接带公钥，适合编排器临时拉起的短命子 Agent。后者的意义很明显：Agent 世界里大量执行体本来就是短时、临时、按任务生成的，你不可能要求每个子 Agent 都先去注册一套完整 IAM。AIP 在这里的设计取向是偏实战的。

AIP 是冲着 MCP/A2A 生态去的

AIP 不是一篇停留在密码学抽象层的文章，它明确写了协议绑定方式。对于 MCP，IBCT 会放在 X-AIP-Token 这个 HTTP 头里，server 端要做身份解析、签名验证、策略求值，再把验证后的身份注入请求上下文；对于 A2A，Agent 可以在 agent card 里暴露自己的 aip_identity，发任务时再把追加过 delegation block 的 aip_token 放进 task metadata。

这个意思很清楚：作者不是想做一个和现有 Agent 协议平行的”新大陆”，而是想把 AIP 嵌到 MCP 和 A2A 之上，变成它们的身份与委托控制层。

从这个角度看，AIP 更像一种 Agent IAM 协议化尝试。传统 IAM 管的是人和服务账号，最多再加一点 workload identity；但到了 Agent 系统里，问题变成了”一个执行体替另一个执行体做事”，甚至”多个执行体层层转授权”。这种情况下，如果还只靠 API key、静态 OAuth token 或网关 ACL 去兜，很多关键问题是回答不出来的。

安全链条并不会把 Agent 跑慢很多

很多安全协议一讲到这里就容易掉进一个坑：概念很完整，但工程成本太高，最后业务团队根本不愿意用。AIP 这篇论文相对比较能打的一点，是它做了两套参考实现，并且给了比较明确的性能数据。

论文报告称，compact mode 的验证延迟在 Rust 实现里是 0.049ms，在 Python 里是 0.189ms；真实 HTTP 的 MCP 调用里，AIP compact 只比无认证基线多 0.222ms，AIP chained 多 0.180ms；而在一个带真实 Gemini 2.5 Flash 推理的多 Agent 委托链里，AIP 平均只增加 2.351ms，占端到端延迟的 0.086%，p99 也只有 0.127%。从这些数字看，Agent 身份验证并不会成为主要性能瓶颈，真正耗时的依旧是 LLM 推理本身。

安全测试的结果也很有意思。论文做了六类攻击、600 次尝试，AIP 全部拦住了；而普通 JWT 方案只能拦住其中四类，漏掉了两类：委托深度越界和空 context 的审计逃逸。这两个点恰恰说明 AIP 的价值不只是”签得更严”，而是它的协议语义比普通 JWT 更完整。普通 JWT 可以证明某个 token 是签出来的，但它不知道 delegation depth 是什么，也不会强制你为每次委托填写上下文。

局限性

这篇论文如果从安全工程角度去看，优点和边界都很清楚。它补的是身份、授权、委托、审计这一层，不是内容安全，不是越狱防护，也不是运行时行为治理。AIP 可以保证一个 Agent 不能在协议层偷偷扩权，但它不能保证这个 Agent 拿着合法权限不会干坏事。论文在 threat model 里写得很明白：在授权范围内的恶意使用、TTL 窗口内的实时重放、验证器自己偷懒不检查、链上多个 Agent 在授权范围内串谋，这些都不是它能单独解决的。

论文自己的限制部分也写得很坦诚。

第一，实验基本还是单机 localhost，不是跨数据中心、不是生产流量、也不是持续高压环境，所以当前数据更多说明”密码学与协议开销不大”，还不能直接等价成”生产稳定可用”。

第二，chained mode 依赖 Biscuit 的 Datalog 策略求值，复杂策略本身会带来新的 DoS 面，因此论文建议默认使用更简单的策略 profile。

第三，也是最关键的一点：completion block 默认仍然是执行者自报。这意味着 AIP 可以证明”是谁声称自己完成了任务”，但默认并不能证明”它声称的结果就是真实的”。论文虽然提供了 counter-sign 和第三方见证的升级路径，但 v1 没有强制。

启发

如果站在今天的 Agent 产业现实去看，AIP 的真正价值不在于它已经成了标准，而在于它把一个很快会爆炸的问题提前形式化了：企业到底该怎么给 Agent 做身份和委托治理。过去系统世界里的 IAM，默认对象是”人”和”服务”；但 Agent 时代的新问题是，“一个会思考、会调用工具、会转包任务的执行体”，要不要拥有独立身份？它把任务继续外包给下游时，权限应该怎么收口？最后又如何在审计层说清楚责任链？AIP 的答案是：要，而且这件事不能只靠网关规则和业务日志凑合，最好要有协议级工件来承载。

当然，AIP 现在还远远谈不上已经坐实。它已经出现在 IETF Datatracker 上，但目前只是 individual Internet-Draft，状态上仍是 work in progress，不代表已经获得 IETF 正式背书，更不代表业界会按它这套直接收敛。可即便如此，这篇论文依然值得重视，因为它提出的不是一个小 patch，而是一种很可能会反复被后来者借鉴的框架：把 Agent 的身份、委托和结果证明合成一条可验证链条。一旦 Agent 真正进入企业流程、金融流程、采购流程和自动执行流程，这类协议层设计迟早都会成为刚需。

结语

简单说，这篇 AIP 论文做的事，可以概括成一句话：

它试图让 Agent 世界第一次认真回答”你是谁、你凭什么、你把权力给了谁、最后又做了什么”这四个问题。

这不是最热闹的赛道，但很可能是未来最绕不过去的底层赛道。因为 Agent 一旦从”会聊天”走向”会执行”，身份和委托就不再是可有可无的附属能力，而会变成整个系统可信性的底板。AIP 现在还只是第一版答案，但它至少已经把问题问对了。