当 Agent 开始层层委托：如何证明“谁说了什么、谁授权了谁”

今天的 Agent，已经越来越不像一个单独工作的聊天机器人。

一个复杂任务交给 Agent 后，它可能先自己做规划，再把搜索任务交给另一个 Agent，把代码任务交给第三个 Agent，把数据分析交给第四个 Agent，后者甚至还可能继续调用外部工具、MCP 服务，或者再找新的 Agent 帮忙。

于是，一个原本简单的请求，很快就可能变成这样：

用户
↓
规划 Agent
↓
检索 Agent
↓
分析 Agent
↓
工具
↓
另一个 Agent

如果这些 Agent 全都属于同一个系统，问题还相对简单。但未来更现实的情况是，它们可能来自不同厂商、不同公司，甚至运行在完全不同的基础设施中。

这时候，一个非常现实的问题就出现了：

如果最后出了问题，我们怎么知道到底是谁干的？

比如，一份错误的投资分析报告，到底是哪个 Agent 输出的？一个 Agent 声称“这是上游 Agent 授权我做的”，这句话到底是真的，还是它自己编的？如果某个 Agent 的密钥已经被攻击者窃取，攻击者是否能够伪造一条看起来完全合法的调用链？

论文《Attesting Outputs and Delegation Ancestry in Multi-Agent AI Systems》讨论的，正是这个问题。

论文原文（arXiv）

这篇论文没有发明新的密码学算法。它使用的 SHA-256、Ed25519、Merkle Tree 等技术，本身都已经存在很多年。

它真正有意思的地方在于，它重新提出了一个 Agent 安全领域正在变得越来越重要的问题：

未来的 Agent 系统，不仅要证明“你是谁”，还要证明“你做了什么，以及是谁让你这么做的”。

这其实意味着，Agent 安全正在从“身份认证”，进一步走向“责任证明”。

Agent 有身份，不等于出了事能找到责任人

今天的大部分互联网系统，已经非常擅长解决“你是谁”这个问题。

用户名、密码、证书、访问令牌、API Key、OAuth，本质上都在帮助系统确认：

当前请求来自谁，这个人或者这个程序有没有权限访问某项资源。

放到 Agent 场景里也是一样。

假设有两个 Agent：

规划 Agent A，把任务交给执行 Agent B。

系统可以通过身份认证确认：

• A 是谁
• B 是谁
• B 是否拥有访问某个工具的权限

但真正发生安全事故以后，我们想知道的问题往往更加具体：

最终这句话是不是 B 说的？

B 真的是 A 派来的吗？

这两个问题，传统身份认证其实都回答不了。

论文把它们分别称为两个缺失的证据。

第一个问题可以理解为：

输出到底是不是它产生的？

第二个问题可以理解为：

这层委托到底有没有经过上游授权？

这是整篇论文最重要的出发点。

“你是谁”和“这句话是你说的”，其实是两回事

先看第一个问题。

假设系统已经知道某个 Agent 的身份是：

财务分析 Agent B。

但 B 返回了一段内容：

“建议将 100 万美元转入账户 X。”

光知道“这个请求来自 B”，并不能充分证明：

这段具体内容，真的就是 B 的运行环境原样输出的。

原因并不复杂。

内容在网络上传输时可能被修改，日志可能被篡改，中间代理程序可能替换数据，甚至调用链中的某个系统本身就可能不可信。

因此，作者提出了一种“输出证明”。

它的思想其实非常像现实世界里的签字盖章。

假设 B 输出了一段文本：

“建议购买某公司股票。”

系统不会只把这句话保存下来，而是先对这句话计算一个“数字指纹”。

这里用到的是 SHA-256。

对不熟悉密码学的人来说，可以先把 SHA-256 理解成一种非常特殊的“内容指纹生成器”。

一段内容放进去，会得到一串固定长度的数字：

原始内容
↓
SHA-256
↓
数字指纹

比如：

“购买 A 公司股票”

可能会得到一串指纹。

如果把其中一个字改成：

“购买 B 公司股票”

重新计算后，得到的指纹就会完全不同。

因此，只要最终保存的内容发生变化，对应的数字指纹也会变化。

这就像给文件拍了一张几乎不可伪造的“指纹照片”。

但只有“指纹”还不够，还要有人为它签字

问题是：

谁来证明这个数字指纹确实属于 Agent B？

于是就需要“数字签名”。

数字签名可以简单理解成一种只有特定主体才能盖出来的电子印章。

系统会拥有一组密钥：

• 私钥：只能由真正的签名者持有
• 公钥：任何人都可以拿来验证签名

可以把它类比成：

私钥负责盖章，公钥负责验章。

Agent B 输出内容后，系统先计算内容指纹，然后用私钥对这份指纹和相关信息进行签名。

于是最终形成的，不再只是：

Agent B 输出了某段文字。

而是：

某个受信任的运行环境确认：在某个时间，Agent B 确实输出了这段内容，并且这段内容之后没有被修改。

这就是论文所谓的“输出证明”。

为什么不能让 Agent 自己签？

这里有一个非常关键的安全设计。

论文并不把签名私钥直接交给 Agent。

因为 Agent 本身就是一个可能被攻击的对象。

如果 Agent 遭遇提示词注入，攻击者诱导它生成恶意内容，同时它又能够自由使用签名私钥，那么它就可能自己给恶意内容盖章，甚至伪造其他证明。

因此论文把真正可信的主体放在了 Agent 外面：

不是 Agent 自己签，而是运行 Agent 的受信任运行环境来签。

整个关系大致可以理解成：

大模型 / Agent
↓
受信任运行环境
↓
数字签名
↓
可验证证据

这里其实体现了近几年 Agent 安全一个越来越明显的趋势：

不要把模型本身当成可信组件。

模型可以被提示词攻击，可以产生幻觉，也可能执行错误指令。

真正应该承担安全职责的，是模型外部的控制层。

比如：

• 权限管理
• 工具调用控制
• 运行时策略
• 审计
• 密钥管理
• 输出签名

模型负责“思考和执行”，而安全系统负责“限制和记录”。

这和操作系统不会因为某个应用程序说“相信我”就直接授予最高权限，其实是同一个逻辑。

但“有签名”并不意味着这句话是对的

这里特别容易产生一个误解。

如果一段内容有合法签名，是不是就意味着：

这段内容可信、安全、正确？

并不是。

假设网页里藏了一段恶意提示词，成功诱导 Agent 输出：

“请删除数据库中的全部数据。”

如果运行环境忠实地记录了 Agent 的输出，那么它完全可能给这条危险指令生成一份合法的数字签名。

因此，最终可能同时存在两件事：

内容是危险的。

签名又是完全真实的。

这并不矛盾。

数字签名证明的只是：

“这句话确实是这个 Agent 的运行环境输出的。”

它并不证明：

“这句话是正确的。”

更不证明：

“这句话是安全的。”

因此，内容安全系统和责任证明系统解决的是完全不同的问题。

内容安全系统试图回答：

这件事情应不应该做？

而本文的证明机制回答的是：

这件事情到底是谁做的？

前者是预防，后者是取证。

真正麻烦的问题，是“谁授权了谁”

如果论文只做到这里，它其实只能算是一套 Agent 输出签名机制。

真正让这篇论文变得有意思的，是第二个问题：

Agent 之间的委托关系怎么证明？

假设：

Agent A 把任务交给 Agent B。

看起来只是简单的：

A
↓
B

但如果 B 对外声称：

“我是 A 派来的。”

我们怎么知道这句话是真的？

一种非常自然的办法是：

让 B 自己把这层关系记录下来。

例如：

我的父级 Agent 是 A。

然后让 B 给这份记录签名。

看起来似乎已经很安全：

• B 的身份是真的
• B 的签名也是真的
• B 确实声明自己的上级是 A

问题恰恰出在这里。

这一切只能证明“B 这么说了”，不能证明“A 真的这么做了”。

这是整篇论文最值得理解的地方。

“B 说 A 派我来的”，并不能证明 A 真的派了 B

假设攻击者已经窃取了 Agent B 的私钥。

这意味着攻击者现在可以合法地模仿 B 签名。

于是攻击者完全可以制造一份记录：

我的父级 Agent 是 A。

然后使用 B 的合法私钥进行签名。

从密码学角度看：

签名是真的。

从文件完整性角度看：

记录也没有被修改。

但问题在于：

A 从来没有授权过 B。

也就是说，系统成功证明了：

“B 确实说 A 派它来的。”

却没有证明：

“A 确实派了 B。”

这个区别听起来很细，但实际上非常关键。

现实世界也一样。

假设一个人拿着自己真实身份证，对外说：

“我是公司董事长派来的。”

身份证是真的，不代表董事长真的授权过他。

甚至这个人自己的签名也是真的，仍然没有用。

因为这里真正缺失的是：

董事长的确认。

完整性不等于授权

作者比较了几种记录 Agent 委托链的方法，其中包括链式哈希、Merkle Tree 等传统技术。

这些技术都非常擅长解决一个问题：

数据有没有被偷偷修改。

比如原本的调用链是：

A
↓
B
↓
C

有人偷偷把 B 删掉，变成：

A
↓
C

通过哈希链等方式，可以很容易发现中间内容发生了变化。

但问题是，即使整条链一点都没有被修改，也不代表链本身就是合法的。

这就像：

一份合同从打印出来到今天完全没有被篡改。

这只能说明：

合同内容保持完整。

却不能说明：

合同双方真的都同意过这份合同。

因此，论文指出：

数据完整性和授权合法性，是两个完全不同的安全问题。

哈希、Merkle Tree 等技术主要解决的是“有没有被改”。

但它们无法单独回答：

这条委托关系到底有没有经过双方同意。

解题思路：父级 Agent 也必须签字

既然问题在于：

B 可以单方面声称 A 授权了它。

最直接的解决办法就是：

让 A 也签字。

于是：

A
↓
B

不再只是一个简单的调用关系，而变成了一份需要双方确认的“委托记录”。

A 要签一次：

“我确认把这个任务委托给 B。”

B 也要签一次：

“我确认接受 A 的委托。”

只有两边的签名都存在，这条委托关系才算成立。

这就是论文采用的核心设计：

双签名委托边。

如果把它放到现实世界里，其实很好理解。

过去的模式相当于：

员工 B 自己写了一张纸：“董事长 A 派我来的。”

现在则变成：

董事长 A 和员工 B 都在这张委托书上签字。

攻击者即使偷到了 B 的印章，也只能伪造 B 的签名。

它仍然无法伪造 A 的签名。

因此，单独攻破下级 Agent，不再足以伪造上级授权。

Agent 调用，正在从“函数调用”变成“委托交易”

这个设计背后，其实隐藏着一个比密码学更重要的变化。

今天我们很容易把 Agent 调用理解成普通程序之间的函数调用：

Agent A 调用 Agent B。

但未来真正的跨组织 Agent 网络里，这种理解可能已经不够了。

如果 Agent A 属于一家银行，Agent B 属于一家外部数据服务商，Agent C 又来自另一个第三方公司，那么 A 调用 B 就不再只是普通的程序跳转。

它实际上是一种：

权限委托。

也就是说：

A 不仅是在“调用 B”，而是在告诉整个系统：

“我允许 B 代表这次任务继续执行某些操作。”

从这个角度看，每一次 Agent 间的调用，都越来越像一笔需要记录的交易。

它应该至少包含：

• 谁把任务交给了谁
• 谁接受了任务
• 双方身份
• 授权发生的时间
• 授权的任务范围
• 最终产生了什么输出
• 是否继续向下委托

于是，一个 Agent 系统最终形成的就不是简单调用日志，而是一条完整的“责任链”。

为什么论文最终用的是 DAG，而不是普通链条

如果整个系统永远是：

A
↓
B
↓
C
↓
D

那用一条普通链记录下来似乎就够了。

但真实 Agent 系统通常不是这样。

一个规划 Agent 可能同时启动：

• 检索 Agent
• 财务 Agent
• 编程 Agent
• 法律 Agent

随后，这些 Agent 又可能继续调用其他 Agent。

最终结构更像一棵不断分叉、合流的任务图。

例如：

用户
↓
规划 Agent

然后同时分成：

检索 Agent

分析 Agent

编程 Agent

几个 Agent 完成以后，结果又汇总回报告 Agent。

这种结构并不是普通链，而是一张“有方向的无环图”，也就是论文使用的 DAG。

不需要过分纠结这个数学名称。

可以简单理解成：

一张记录“谁把任务交给谁”的任务关系图，而且任务只能向后传递，不能形成无限循环。

论文为这张图中的每一条委托关系都加入双方签名。

所以最终得到的，可以理解成一张：

每条边都有双方签字的 Agent 责任关系图。

这套设计能防什么？

为了验证方案，作者专门设计了多种针对 Agent 委托链的篡改方式。

其中最容易理解的有几类。

第一种是“凭空插入”。

原本系统里根本不存在某个上游 Agent，攻击者却试图伪造一条：

假 Agent X
↓
Agent B

如果 X 没有真的签名，这条关系就无法成立。

第二种是“删除中间人”。

原本调用链是：

A
↓
B
↓
C

攻击者想删除 B，伪造成：

A
↓
C

如果每个 Agent 只是给自己签名，那么 A 和 C 的签名仍然都是真的，系统可能发现不了问题。

但如果每条委托关系都需要双方签名，那么：

A
↓
C

必须拥有 A 和 C 针对这条具体关系共同生成的签名。

攻击者无法把原本：

A
↓
B

和：

B
↓
C

的签名直接拼成：

A
↓
C。

第三种是“移花接木”。

假设原本存在两条链：

A
↓
B
↓
C

以及：

X
↓
Y

攻击者试图把 C 接到另一条链后面：

X
↓
Y
↓
C

如果 C 和 Y 从来没有为这条新关系共同签名，验证就会失败。

这些攻击的共同点其实都是：

攻击者试图重新解释“谁授权了谁”。

而双签名设计的核心就是：

每一条授权关系都必须得到关系双方确认。

但有些事情，密码学永远解决不了

论文还讨论了一类非常有意思的问题。

假设 Agent A 合法地同时委托了三个 Agent：

A
↓
B

A
↓
C

A
↓
D

三条关系全部都有合法签名。

那系统应该接受吗？

这取决于业务规则。

如果系统规定：

一个 Agent 最多只能同时委托两个下级 Agent。

那么第三条委托就应该被拒绝。

但密码学无法替系统做这个判断。

因为从密码学角度看：

• A 的签名是真的
• B、C、D 的签名也都是真的
• 每条委托关系也确实发生过

密码学能证明：

发生了什么。

但它不能决定：

什么应该被允许发生。

后者依然需要策略系统。

这也是理解 Agent 安全架构一个非常重要的边界。

未来的 Agent 安全体系不可能只靠密码学，也不可能只靠模型护栏。

它需要很多层机制共同工作：

• 身份认证解决“你是谁”
• 权限系统解决“你能做什么”
• 内容安全解决“这个请求是否危险”
• 委托证明解决“是谁授权你的”
• 输出证明解决“你具体输出了什么”
• 审计系统解决“事情发生以后如何还原现场”

实验结果

很多人看到数字签名、哈希、双签名，第一反应可能是：

这样做会不会让 Agent 变得特别慢？

论文的实验结果表明，至少密码学操作本身并不是主要瓶颈。

作者在本地环境中测试了几种方案。

最安全的双签名 DAG 方案，完整验证大约需要不到 1 毫秒量级。

在 LangGraph 中集成后，单个节点的签名成本大约只有 0.17 毫秒，完整验证约 0.83 毫秒。

而一次真正的大模型推理通常需要数百毫秒，甚至几秒。

也就是说：

与模型推理相比，生成和验证这些安全证据本身的成本非常小。

作者还搭建了一个包含 A2A、MCP 和真实大模型调用的系统。

没有安全证明时，端到端延迟大约为 771 毫秒。

加入双签名责任链后，大约为 813 毫秒。

整体增加约 5.5%。

这里当然不能直接理解成：

“未来生产系统一定只增加 5.5% 成本。”

因为实验中还没有加入真实生产环境中的证书管理、密钥托管、TLS、复杂权限系统等。

但至少说明了一件事：

数字签名本身并不会成为 Agent 系统的主要性能瓶颈。

论文还把系统部署到了多个云节点

作者进一步在 AWS 的三个可用区之间部署了：

• 父级签名服务
• 子级签名服务
• 验证服务

然后进行了 1000 次实验。

正常调用全部能够成功验证。

同时作者还测试了：

• 重放旧请求
• 使用未注册的父级
• 使用已经撤销的子级密钥
• 父级拒绝签名

系统都能够拒绝相关请求。

这说明这套方案至少已经不是一个停留在纸面上的密码学设计，而是做到了真实多节点环境中的原型验证。

当然，它距离真正的生产系统仍然有明显距离。

局限性

理解这篇论文时，尤其不能把它夸大成：

“已经解决了多智能体安全问题。”

实际上，它解决的是非常明确的一小块：

责任证明。

它解决不了提示词注入。

也解决不了模型幻觉。

更不能判断 Agent 输出是否安全。

另外，这套系统还依赖一个非常重要的前提：

负责签名的运行环境本身必须可信。

如果攻击者已经控制了整个运行环境，甚至控制了签名密钥，那么它当然可以生成虚假证据。

这就像：

如果真正的公章已经被攻击者偷走，那么再精密的签章制度也无法完全解决问题。

因此，未来真正的系统很可能还需要结合：

• 硬件安全模块
• 密钥管理系统
• 可信执行环境
• 安全启动
• 远程证明

换句话说，这篇论文把“信任”从 Agent 本身移动到了底层安全基础设施。

它并没有让“信任”消失。

如果上下两级都被攻破，系统同样无能为力

双签名机制能够解决一种很重要的问题：

攻击者只偷到了下级 Agent B 的密钥。

此时攻击者仍然无法伪造：

A
↓
B

因为它没有 A 的签名。

但如果 A 和 B 的密钥同时被攻破，那么攻击者自然就可以生成双方签名。

这并不是论文方案的漏洞，而是密码学系统普遍存在的边界。

任何安全系统都需要一个最终的信任根。

如果所有信任根都已经被攻击者控制，系统自然无法继续区分真假。

所以真正部署时，密钥保护本身会成为非常重要的问题。

Agent 安全开始出现“责任基础设施”

如果只看论文表面，很容易觉得：

不就是给 Agent 加个数字签名吗？

但如果把它放到整个 Agent 产业的发展趋势中，意义就不一样了。

早期的大模型安全，大家主要关注：

• 越狱
• 提示词注入
• 有害内容
• 幻觉

后来 Agent 出现以后，安全问题开始逐渐向系统层移动：

• Agent 能调用什么工具
• Agent 能访问什么数据
• Agent 能不能继续委托其他 Agent
• Agent 的记忆是否可信
• 工具返回结果来自哪里
• 谁批准了一次高风险操作

而现在又进一步出现了一个新的问题：

发生事故以后，如何证明整条 Agent 行为链。

这和互联网安全的发展其实很像。

互联网早期也不是一开始就有今天成熟的：

• HTTPS
• 证书体系
• 代码签名
• 软件供应链证明
• 硬件可信根

这些能力都是随着互联网逐渐承载金融、政务、商业等高价值活动以后，一层层补出来的。

Agent 网络未来很可能也会经历类似过程。

当 Agent 只是在个人电脑上帮用户整理文档时，责任链可能并不重要。

但如果未来 Agent 能够：

• 代表企业采购
• 调用金融系统
• 修改生产环境
• 自动签署合同
• 操作工业设备
• 与其他公司的 Agent 协商业务

那么系统必须能够回答：

这个 Agent 是谁？

它有什么权限？

谁把权限委托给了它？

它具体做了什么？

最终输出了什么？

这条行为链有没有被修改？

这些问题最终很可能会变成 Agent 时代的基础设施。

从“Agent 身份”到“Agent 责任链”

如果把未来的 Agent 安全体系简单画成几层，大致可以理解成：

最上层是内容与行为安全：

这件事能不能做？

下面是运行时治理：

这个 Agent 有什么权限？

再往下是委托证明：

是谁授权它来做？

再往下是输出证明：

它最终到底说了什么、做了什么？

最底层则是：

身份、密钥、可信运行环境。

这几层解决的是完全不同的问题。

现在很多 Agent 安全方案仍然主要集中在前两层。

而这篇论文实际上是在补下面的：

委托证明 + 输出证明。

它们平时可能并不起眼。

但一旦 Agent 真正进入企业核心业务，这些能力的重要性会迅速上升。

未来的 Agent，可能需要像人一样“签字负责”

今天，当一个 Agent 调用另一个 Agent 时，我们很容易把它看成普通的软件接口调用。

但随着 Agent 开始跨公司、跨平台、跨系统自主协作，这种关系正在发生变化。

一次 Agent 调用，越来越像一次真正的“授权委托”。

一个 Agent 不仅需要证明：

“我是我。”

还需要证明：

“上级真的让我来。”

最终还要证明：

“我确实做了这些事。”

从这个角度看，这篇论文最重要的贡献并不是某一种签名结构，也不是 DAG 本身。

它真正提醒我们：

Agent 时代的安全，不能只关心模型有没有做错事，还必须建立一套能够追溯“谁授权、谁执行、谁输出”的责任基础设施。

因为未来真正复杂的 Agent 系统里，最麻烦的问题可能不再是：

“这个 Agent 有没有身份？”

而是：

“当所有 Agent 都说自己只是奉命行事时，我们到底拿什么证明，谁真的下过这个命令？”