AI 跨组织互发消息出了事，怎么让涉事两边都赖不掉账？

两个医院的 Agent 互发消息，出了事该信谁

把镜头对准一条再普通不过的医疗流水线：A 医院的 AI 主治 Agent 把病人转诊给 B 医院（转诊 refer_patient），B 医院回开核磁检查单（order_mri）、传回检查结果（send_result），A 医院最后提交保险理赔（submit_claim）。四个动作，两个机构，全程没有人类盯着。现在假设出了事：B 医院收到的转诊单被人改过、A 医院咬定自己没收到结果、或者那条理赔请求干脆是某个越权的 Agent 发出的。事故调查开始，双方坐在桌子的两头，各执一词。该信谁的话？本文要回答的正是这一个问题：跨组织的 Agent 之间出了事故，如何靠双方都能独立检验的离线证据，把事情问责清楚。接下来的场景、难点、现实性和论文给出的答案，都是同一个问题的不同侧面。

先说难处在哪，就在「跨组织」三个字上。组织内部的通信好办：企业有统一 IT、统一日志、统一权限，出事找运维拉日志就行，因为存在一个大家都认的可信方。跨组织不是这样，A 医院不归 B 医院管，B 医院的日志 A 医院没有理由相信，反过来也一样。没有任何一方天然可信，所以任何一方的说法都必须拿双方都能独立检验的东西来对。没有共同信任方，既是场景里的死局，也是离线证据问责要跨过的第一道坎：正因为谁都不信谁，才必须有一份双方都拿得出的证据。

这个问题为什么偏偏在现在变得要紧？先看现实性：论文转引 Cloud Security Alliance 的报告指出，53% 的组织观察到 AI Agent 至少偶尔超越预期权限行事，47% 报告过涉及 Agent 行为的安全事故，这是外部调查的转引，不是作者自己的测量。再看时机：Agent 互操作协议正在把 AI 之间的对话搬上真实网络，MCP 让 Agent 能调用外部工具，跨组织工作流让一个机构的 Agent 能直接给另一个机构发请求、传文件。过去的 Agent 互发消息是实验室里的编排演示，今天是真实企业的真实业务链路，而这条链路的两端站着两个互不信服的机构。问责不再是一个理论兴趣，它决定这套东西能不能真正上线。要回答它，不能指望让 Agent 变得更诚实，只能让 Agent 说过的每句话都留下可验证的足迹。

针对这个问题，2026 年 8 月提交到 arXiv 的预印本《Offline-Verifiable Accountability for Cross-Organization Agent Messaging: A Preserved Evidence-Bundle Approach》（arXiv:2608.28542）给出了一套完整答案。作者是 Adil Alshammari 与 Hayretdin Bahsi，署名机构含美国北亚利桑那大学、沙特 Majmaah 大学与爱沙尼亚塔林理工大学。答案分两步：在消息发生的当场，把证据冻结下来、打包保存；事后由一个完全离线的验证器独立复核，不依赖任何一方的实时配合。当场冻结，是为了让证据不依赖任何一方事后补交；完全离线，是为了让判决不依赖任何一方在线配合。下面这张图是这套体系的五角色全景。

图注：五角色体系架构。发方 Agent 的消息经接收侧决策点校验后，记入 append-only 日志；按策略需要时，checkpoint witness 对日志快照背书；最终汇编成保留证据束，供离线验证器复核。验证器不参与在线环节，证据流单向。保留证据束

但方案要对，先得回答一个前置问题：要防的对手到底是谁。下一章就从威胁模型讲起。

把对手想清楚：一个能改证据、能赖账的人

想清楚要防谁，方案才有准头。论文把对手建模得非常克制：不假设对手能控制整个运行时，那等于假设对方是神；只假设对手能操控证据。他可以把证据改掉、漏掉、换成另一份、把旧的重新播放、把签名从一条消息重新绑到另一条消息上。这个「证据操控者」（evidence manipulator）模型把全部火力集中到一个目标：让证据在事后可以被独立复核，而且只能依据当场保存下来的物件复核。

为什么不能再验证？用同一个场景想一遍就懂。出事后去找发送方，等于去问犯罪嫌疑人：他可能不在线、可能不配合，而且他本来就是被怀疑的对象。去查一份中央日志？跨组织场景根本不存在大家都认的中央日志，每一方都只会指认对方手里的那份是假的。所以事后问责只能建立在双方当时都拿得出来的东西上，也就是当场保存下来的证据，而不是任何人的实时配合。这个结论把「事后必须靠证据、不能靠配合」钉死，下一章的证据束方案就是顺着它长出来的。

那么证据可能在哪些环节被动手脚？论文的 Table 2 列出六条证据控制边界（Evidence-Control Boundaries），它们标记了六个可能被篡改的位置：

这张表同时划清了方案的界线：它防的是「证据被操控」，不防「Agent 本身被攻陷」。把端点被攻破、密钥泄露、双方串谋这些统统放进保证范围，等于承诺自己做不到的事。论文很诚实，它们都在证据级保证之外。保留证据束 这个分寸感是整篇论文的底色，也会在最后一章再收一次口。

当场打包：证据束里装什么，怎么发行

方案的核心是一个保留证据束（Preserved Evidence Bundle）：围绕一次消息交互，在事件发生的当场，该签的都签了、该记的都记了，然后打包保存。它分两层。核心证据是两条：发送方对规范消息的签名，证明「这条消息是哪个 Agent 发的」；以及把消息摘要记入 append-only 日志后拿到的日志承诺，也就是带签名的树头 STH（Signed Tree Head）加 Merkle 包含证明，证明「这条消息确实被日志记录在案」。这两条每个事件都必须有。

第二层叫策略受控证据，是否附加由所选策略轮廓决定，包括 witness 背书的 checkpoint、checkpoint 上下文、追加性扩展证明（AOEP）、能力链（capability chain）和显式接收方签收回执。AOEP 是一种数学证明，用来表明两个连续日志快照之间，日志只允许追加、不允许改删。作者的前一站工作已经把这个思路做到过单条消息级：2026 年 IEEE CCWC 上的 Authenticated and Offline-Verifiable Agent-to-Agent Messaging for LLM Agents 用「签名消息 + Merkle 日志 + 树头 + 极简身份注册表」造出了消息级的 proof-carrying receipt，中位离线验证约 0.4 秒，证明大小随日志大小做对数增长。CCWC 消息级 这篇论文要做的，是把同样的思路从「单条消息」升格到「工作流事件级」。下图演示了四个事件是怎么逐个发行证据的。

图注：四事件时序图。refer_patient、order_mri、send_result 走同一条「签名消息、校验、记入日志、存证据」流水线；submit_claim 额外叠加委托链与工作流前置证据，引用前序事件。保留证据束

发行路径本身不复杂，论文把步骤写成了算法：接收侧先校验发送方签名、算出消息摘要，把摘要记入 append-only 日志，换回包含证明和签名 checkpoint；然后按策略逐项附加受控证据，witness 该请则请、上下文该锚则锚、委托链该查则查；最后把这一摞东西组装成束、落盘保存。整条路径都发生在消息流通的当口，没有一步是出事之后补做的，这正是它日后能当证据用的原因。

四个事件里，最后一步 submit_claim 明显更重。它要额外携带委托链和工作流前置证据，也就是引用前序事件的证据。为什么？因为离线验证器要回答一个棘手的资格问题：这条理赔消息，真的是「有资格替 A 医院说话」的那个 Agent 发出来的吗？A 医院的主组织把发言权一级一级委托下来，中间可能经过平台、经过子 Agent，验证器面前只有一个没法上线询问的发件方。要离线判断资格，消息里就必须带着从主组织一路委托到它的整条能力链，每一级凭证都带签名、作用域约束和有效期。下图把这条链画了出来。

图注：能力链三阶段。主组织对中间平台签发首张委托凭证（授权），平台把收窄了范围的凭证下发给执行 Agent（委托），Agent 把绑定整条委托链的 submit_claim 消息发给接收方（行使），每个链接带校对标记。

机制上，能力链验证就是逐环核对：每一环的「谁发出、发给谁」要一致，委托范围逐级收窄或保持一致，时间窗有效，消息绑定到委托上下文，各环节签名有效。这个思路很有来头。跨机构医疗数据共享里，委派既要灵活、又要可撤销可审计，DAMFSD 这类方案在数据访问层解决「谁能看哪份病历」；医疗委托 论文把同一道题的答案搬到了消息层：谁有资格替组织发这条消息。而在工业物联网方向，Ferretti 等人的委托审计方案早已证明「授权可追溯、可归因、验证不依赖单一可信方」工程上可行，能力链不过是把这个原则用在了 Agent 工作流上。IIoT 委托审计

一句话总结这一章：方案不是在出事后再去搜集证据，而是在纠纷发生之前，就把事后问责需要的原始材料按事件逐个冻结好了。普通步骤配基础证据，关键步骤要更厚的证据（委托链、回执）。但「有证据」不等于「证据什么都能证明」。下一章看验证器到底怎么判、判到什么程度为止。

事后离线复核：不靠在线服务，也不夸大结论

验证器被设计成一台「只要输入对，不看任何人脸色」的机器。它的输入有两类：一类是保存下来的证据束本身，另一类是本地信任输入，包括策略轮廓、可信公钥、witness 与 checkpoint 上下文引用、密钥解析输入。其中密钥解析输入解决一个现实问题：验证器不联网，怎么拿到发方公钥？验证器的本地输入包含论文所称的密钥解析引用（key-resolution references），离线密钥发现采用的极简 DID 注册表源自作者前作（2026 年 IEEE CCWC 消息级基线），把身份解析结果作为本地材料喂给验证器，不查询任何在线服务。它不访问任何在线服务，不联系发送方、接收方、日志服务器里的任何一台。下图给出了输入、检查、判决的完整结构。

图注：离线验证器输入与检查。左侧是证据束组件（发送签名、签名 checkpoint、witness 签名、AOEP、checkpoint 上下文、能力链、显式回执），中间是验证器，右侧是谓词输出汇入 Accept/Reject；本地输入含策略轮廓 P 与可信公钥。保留证据束

验证器的检查被组织成一个谓词宇宙，共十个谓词。谓词（predicate）可以理解成一项检查函数，返回「过」或「不过」：消息格式、载荷哈希绑定、发送签名、Merkle 包含证明、树头签名，这五项是核心检查，每个证据束必查；witness、上下文、追加性、能力链、回执，这五项由策略轮廓决定要不要查。接受的定义用大白话说就是一句：该策略要求查的所有谓词全部返回「过」，验证器就给出 Accept。不多一分，不少一分。

这正是全篇最容易被误读的地方，值得慢下来看。论文给每一类证据同时挂上「支持」和「不建立」两个标签，下图把它们排成了七张卡片。

图注：七张证据卡片，每张同时标注「支持」与「不建立」两个标签。例如签收回执支持「收到声明」，但不建立投递。横幅点明：离线验证器只担保检查通过的那几条有界声明。

逐张读过去，会发现每一类证据都很克制。签收回执支持「接收方声称收到了这条消息」，但不建立「消息真的投递成功」，更不建立「接收方执行了消息里的要求」。HTTP 传输成功、转发、日志收录，都不构成回执。AOEP 支持「两个检查点之间日志只增不改」，但不建立「系统全局一致」，也不建立「实时防止分叉」。发送方签名支持「这条消息出自这个 Agent」，但不建立「消息进了日志、对方收到了」。验证器给出的 Accept，就是这组担保的合取，仅此而已。

论文在形式化层面把这个姿态钉死：如果验证器接受，证据束只支持那些「必需谓词都已通过」的证据级声明，任何更强的结论都不能从 Accept 推出；策略要求得越多，接受就越难，一个宽松策略的接受推不出严格策略下也会接受；策略没要求回执检查、或回执检查没过，证据束就不支持「收到」声明。保留证据束 这种「证据驱动判决」的姿态在协议验证社区并不新鲜，MoMEP 用 Tamarin 形式化验证的判决函数就是同一种思路：判定责任靠可独立检查的证据项，不靠在线信任。MoMEP

证据束里的两个陌生件也各有血缘。Certificate Transparency 社区的 LogPicker 很早就用多 witness 见证加 commit-then-reveal 来防日志作恶，论文把这条思路搬到了跨组织场景；LogPicker 而「树头加包含证明」在生产 Key Transparency 系统 Parakeet（NDSS 2023）里也是标准形态，只不过它证的是「用户名映射到哪个密钥」的目录一致性，论文证的是「哪个 Agent 在哪个事件里说了什么」，两者的设计意图并不相同。Parakeet

三个实验：这套机制真的跑得动吗

三个实验分别回答三个不同的问题，别把它们当成同一个指标的三种测法。原型跑在一台 Microsoft Surface Laptop Studio 2 上，Windows 11、Python 3.9.13，是单机原型测量，不是生产基准，这一点论文自己在局限里说得很清楚。

第一个实验问的是：每种证据类的代价有多大？做法是拿同一批 300 条合法的 submit_claim 证据束，单控变量地关掉某一类证据检查。全开的 ALL_ON 中位 785.52 毫秒；关掉 witness 检查只省 5.1%，关掉 AOEP 省 3.0%，关掉能力链省 3.0%；但关掉与 checkpoint 上下文锚定相关的检查（NO_EPOCH），直接把中位延迟打到 183.04 毫秒，省了 76.7%。这说明在当前原型里，上下文锚定才是验证器延迟的主力，其余证据类相对便宜。300 条证据束在每种策略下都全数通过。

第二个实验换一个问法：同一个工作流里，哪个事件需要最厚的证据？300 条配对工作流，前三个事件的中位验证时延都贴在 400 毫秒上下，彼此没有显著差异；submit_claim 明显拉开，中位 680.21 毫秒，P95 高达 712.70 毫秒，统计检验给出 Friedman χ²=536.740、p=5.20e-116。原因就是上一章说的：submit_claim 走完整委托链，还要引用前序事件的证据，负担自然最重。

第三个实验问的是：证据被篡改时，检查真的会拦住吗？论文构造了 17 个定向篡改案例：改载荷、伪造 Merkle 包含证明、篡改签名 checkpoint、破坏 AOEP 连续性、能力链错绑、缺 witness、工作流前置证据缺失或错绑、上下文锚定被改、发送方身份被仿冒等等。这 17 个案例贴着六大类威胁属性布置，包括身份仿冒、日志篡改、签名重绑、抵赖、篡改遗漏、越权委托。结果全部在预期的「第一个该失败的检查点」处被拒，零假接受。它证明「有界声明不是空话」：检查不是摆设，证据一被动手脚，验证器就在预定的地方亮红灯。保留证据束

这三个数字的正确读法：E1 和 E2 回答不同的问题，不可交叉比较；绝对时延是原型的，不是普适常数。实验的价值在机制层面：每类证据都有可量化的代价、每个工作流事件有可区分的证据需求、每个负样本都在预料的检查点被拒，主张与评估是对齐的。这套机制在原理上跑得通。

保证不了什么，以及下一步去哪

论文主动承认六条局限。与其说是短板，不如说是边界感：单主机原型，绝对延迟不能当通用常数；E1、E2 不可交叉比较；checkpoint 上下文锚定是当前验证器端延迟的主力，也是下一步优化瞄准的地方，方向包括索引 WCL 条目、缓存已验证上下文、预校验 WCL 材料；工作流评估用的是固定四步医疗例，更长、带分支、多跳委托的工作流还没测；负证据套件是定向诊断，不是穷尽式模糊测试。

更重要的是划清证据级之外的线。端点被攻陷、密钥泄露、双方串谋、Agent 决策里的语义错误，全在保证范围之外。运行时 LLM 侧的攻击更不归它管：多 Agent LLM 流水线的研究显示，prompt injection、共识投毒、计划劫持、Agent 替换这四类结构性攻击在基于真实生产轨迹的受控流水线评估中，成功率可以达到 0.6 到 0.86，这些是「Agent 脑内」的问题，证据束管不到。多 Agent 攻击面 而且担心的这个问题域不是纸面威胁：对公网 MCP 服务器的规模化测量发现，动态审计的服务器里 91.8% 缺 OAuth 认证，41.6% 的服务器在三天内就消失，跨组织 Agent 通信的真实暴露面在 2026 年已经是普遍现象。MCP 暴露面

那么下一步往哪走？方向恰好是第一章那张五角色图里「没画出来」的部分。图里默认 Agent 已有可信身份，但「这个 Agent 到底是谁、在跑哪段代码」本身就需要基础设施：BAID 用本地生物特征加链上身份加 zkVM 代码级认证，把责任绑定到具体的人和代码，这是证据束成立的前置条件。BAID 平台层是否可信，光靠软件签字说服不了任何人，因为签名的运行时本身就是嫌疑方；Sokolov 的 RATS 组合把硬件级远程证明与软件 action evidence 绑在一起，补的是平台这一层。平台层证明 静态的 witness 名单也可以换成动态的链上见证：D-MUTRA 用私有许可链按「最近通过证明的 Agent」顺位轮换验证者，把对 witness 名单的信任换成对链上共识的信任。D-MUTRA 论文自己的路线图里还有一个更轻的方向：设计减少披露的证据视图，让验证只暴露必需的几条谓词结果，而不是把整份证据束摊开给所有参与方。

把这篇论文放进更大的图景，它最有价值的地方，是把「跨组织事件的事后问责」从「该信谁」改写成了「证据够不够」。这不是把问题变小，而是把它变成了一个可以工程化、可以精确划定保证边界的形态。证据再厚也只支持经策略检查的有界声明，但这种克制恰恰是它可信的原因：一份只敢说它该说的证据，比一份什么都能证明的证书值钱得多。

想深入可以读原文：Offline-Verifiable Accountability for Cross-Organization Agent Messaging: A Preserved Evidence-Bundle Approach — arXiv:2608.28542

参考文献

1. Alshammari, A., & Bahsi, H. Offline-Verifiable Accountability for Cross-Organization Agent Messaging: A Preserved Evidence-Bundle Approach. arXiv:2608.28542. https://arxiv.org/abs/2608.28542
2. Alshammari, A., Assiri, S., & Bahsi, H. Authenticated and Offline-Verifiable Agent-to-Agent Messaging for LLM Agents. 2026 IEEE CCWC. https://doi.org/10.1109/CCWC67433.2026.11393740
3. Dirksen, A., et al. LogPicker: Strengthening Certificate Transparency Against Covert Adversaries. PoPETs 2021(4). https://petsymposium.org/popets/2021/popets-2021-0066.pdf
4. Malvai, H., et al. Parakeet: Practical Key Transparency for End-to-End Encrypted Messaging. NDSS 2023. https://eprint.iacr.org/2023/081
5. Ferretti, L., et al. Verifiable and auditable authorizations for smart industries and industrial Internet-of-Things. JISA 2021. https://doi.org/10.1016/j.jisa.2021.102848
6. Li, M., et al. DAMFSD: A decentralized authorization model with flexible and secure delegation. Internet of Things 2024. https://doi.org/10.1016/j.iot.2024.101317
7. Haque Bappy, F., et al. Adversarial Attacks in Multi-Agent LLM Pipelines: Unveiling Structural Vulnerabilities in Agentic AI Architectures. arXiv:2608.00718. https://arxiv.org/abs/2608.00718
8. Falanji, R., Asplund, M., & Carlsson, N. MoMEP: A formally verified protocol with modifiable signed messages. JISA 2026. https://doi.org/10.1016/j.jisa.2026.104378
9. Lin, 等. Binding Agent ID: Unleashing the Power of AI Agents with accountability and credibility. arXiv:2512.17538. https://arxiv.org/abs/2512.17538
10. Padilla, N. Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale. arXiv:2608.00150. https://arxiv.org/abs/2608.00150
11. Sokolov, A. Hardware-rooted attestation for AI-agent evidence: composing IETF RATS with action evidence packages. arXiv:2608.00801. https://arxiv.org/abs/2608.00801
12. Zahir, A., et al. D-MUTRA: DLT-based MUTual Remote Attestation for Multi-Agent Systems. arXiv:2608.01938. https://arxiv.org/abs/2608.01938