💻 computer science

Evidence-Bound Gateway-Path Provenance for Third-Party LLM Inference

本文提出了一种证据绑定（evidence-bound）的大语言模型（LLM）网关架构，该架构利用一个经证明的执行平面（attested execution plane）对所有路由、回退及流式传输决策进行加密验证与签名，从而使客户端能够独立检测并防止第三方网关运营商实施的策略违规、路由替换及流操纵。

原作者： Fei Wang, Zebai Tian

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Fei Wang, Zebai Tian

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

以下是关于论文《Evidence-Bound Gateway-Path Provenance for Third-Party LLM Inference》（面向第三方大模型推理的证据绑定网关路径溯源）的解释，已将其转化为通俗易懂的日常类比。

问题所在：“黑盒”中间人

想象一下，你想从一家烘焙店订购一个定制蛋糕，但你不想直接和面包师打交道。于是，你雇佣了一家快递服务公司（即“网关”）来处理订单。你告诉快递公司：“请帮我从 A 面包店买一个巧克力蛋糕。”

在当今的 AI 世界中，这家快递服务公司就是“第三方 LLM 网关”。它位于你和大型 AI 公司（如 OpenAI、Anthropic 等）之间。

信任危机：
问题在于，一旦你的订单离开你的手，快递服务公司就拥有了绝对控制权。他们可能会：

在不告知你的情况下，把 A 面包店换成一家更便宜、质量更差的店，并完成订单。
在把订单发给面包店之前，偷偷把你的请求从“巧克力蛋糕”改成“香草蛋糕”。
把店里买的现成蛋糕送过来，却声称是为你定制的。
稍后更改账单，把原本的小蛋糕改成巨大的多层蛋糕。

因为快递服务公司负责写收据并控制运输车，你根本无法证明他们没有作弊。你只能选择信任他们。

解决方案：“密封、见证的保险库”

这篇论文提出了一种新的运行这些快递服务的方式，即使用一个安全保险库（称为“受验证网关运行时”，简称 AGR）和一个公证员系统。

以下是这个新系统的运作步骤：

1. 密封保险库（AGR）

快递服务公司不再是在开放的办公室里处理你的订单，而是将订单处理过程放在一个高科技、坚不可摧的玻璃保险库（即“可信执行环境”，简称 TEE）中。

规则： 只有这个特定的保险库被允许打开你的密封订单、读取你写的内容、决定使用哪家面包店，并与面包店进行沟通。
限制： 快递服务公司的管理者（“业务平面”）可以看到货车在移动以及包裹正在装载，但他们无法看到保险库内部。他们不能更改订单，也不能在制作蛋糕的过程中窥视。

2. 公证检查（远程验证）

在你发送订单之前，你不仅仅是盲目相信保险库的存在。你会要求查看公证员的印章（远程验证）。

保险库会向你展示一张数字身份证，证明：“我是正确的、未被篡改的保险库，并且正在运行你所批准的精确软件版本。”
如果快递服务公司试图用一个假的保险库来替换它，公证员的印章将无法匹配，你也就不会发送订单。

3. “证据链”（收据）

一旦保险库处理完你的请求并拿到了蛋糕（AI 的响应），它并不会直接交给你。它会创建一个防篡改的数字收据（推理证据链）。

这份收据由保险库本身签名。
它证明了：“我是这个保险库。我收到了你的特定请求。我获准前往 A 面包店。我从 A 面包店获取了响应。我将这段完全相同的文本交付给了你。”
如果快递服务公司试图更换蛋糕或更改收据，签名就会失效，收据也会变得无效。你会立即知道出问题了。

这个系统实际做了什么（以及没做什么）

它解决了什么问题：

不再有隐蔽的替换： 你确切知道使用了哪种 AI 模型。
不再有秘密修改： 快递服务公司无法偷偷更改你的提示词（Prompt）或答案。
不再有虚假账单： 发生的一切记录都由保险库签名，而不是由快递经理签名。
故障安全机制： 如果保险库被篡改或缺少证明，系统会停止工作（故障关闭），而不是给你一个错误的答案。

它没有解决的问题（论文的局限性）：

它无法阻止“面包师”： 如果面包店（AI 提供商）本身决定给你一个糟糕的蛋糕或危险的配方，保险库也无法阻止。保险库只能证明递送路径是诚实的，不能证明面包师是诚实的。
它无法隐藏时间信息： 快递服务公司仍然可以看到货车在路上跑了多久，或者包裹有多大，即使他们看不见里面的内容。
它无法阻止拒绝服务攻击（DoS）： 如果快递服务公司决定干脆不运你的货车，他们是可以做到的。

“试驾”结果

作者构建了一个工作的原型（一个“Rust 原型”）来测试这个想法。

他们使用了一个“模拟”AI 提供商和一个真实的提供商（GPT）进行了测试。
速度： 它非常快。额外的安全步骤（检查保险库和签署收据）只增加了极少的时间（毫秒级），几乎察觉不到。
安全性： 当他们尝试通过更换模型、隐藏备选方案或更改收据来“黑”进系统时，系统捕捉到了每一次尝试并拒绝了它们。

核心结论

这篇论文引入了一种让第三方 AI 网关设计上即诚实的方法。你不再需要信任运行网关的公司，而是迫使网关通过密码学数学来证明自己严格遵守了规则。

你可以把它想象成针对每一次 AI 交互的密封、经过公证的合同。你不需要信任中间人；你只需要信任签名收据的数学逻辑和硬件。

技术摘要：面向第三方 LLM 推理的证据绑定网关路径溯源

1. 问题陈述

第三方大语言模型（LLM）网关已成为利用多个外部 LLM 提供商的应用的关键基础设施。这些系统处理路由、模型选择、回退机制、流式传输和计费。然而，存在一个根本性的信任边界问题：网关算子既控制着推理路径的中介过程，又控制着描述该路径的记录的编写权。

在传统的部署中，虽然传输层安全性（TLS）保护了网络跳数，但网关会在明文状态下终止客户端请求。这使得网关能够：

读取提示词并重写上游请求。
在客户端不知情的情况下替换端点或模型。
修改流式响应或注入内容。
伪造使用情况、计费或溯源记录。

仅接收答案和网关编写日志的客户端，无法区分是诚实的中介行为，还是隐藏的模型替换、未声明的回退、端点重写或流操纵。这种风险在智能体（Agentic）系统中被放大，因为返回的文本可能会触发工具调用或代码编辑。核心问题不仅在于谁能读取提示词，而在于谁拥有编写网关路径记录的权利。

2. 方法论：证据绑定架构

本文提出了一种证据绑定网关（Evidence-Bound Gateway）架构，将由算子控制的业务平面与远程证明的执行平面分离。其核心组件是受验证网关运行时（Attested Gateway Runtime, AGR），它运行在可信执行环境（TEE）中。

关键架构组件

业务平面（Business Plane）： 处理客户端认证、配额强制执行、流量转发和日志记录。它转发不透明的密文，但无法解密请求或访问流密钥。
受验证网关运行时（AGR）： 运行在 TEE（如 AWS Nitro Enclaves）内的安全关键执行平面。它是唯一允许执行以下操作的组件：
- 解密客户端请求。
- 执行请求范围内的路由和回退策略。
- 构建对上游提供商的调用。
- 加密响应流。
- 签署推理证据链（Inference Evidence Chains, IEC）。

协议流程

注册与证明： 发布机构签署一份经过批准的运行时度量和策略的注册表。客户端验证此注册表并向 AGR 请求新鲜的证明。AGR 提供一个硬件证词（Quote），将其度量值、策略哈希以及加密/证据签名密钥进行绑定。
携带策略的合约： 客户端发送包含**推理合约（Inference Contract, IC）**的加密请求，该合约缩小了全局策略在特定请求上的范围（例如，允许的模型、回退边）。AGR 计算有效策略（ $P_{eff} = P \cap IC$ ）。
安全执行： AGR 解密请求，验证策略，选择路由/端点，并调用上游提供商。它加密响应流，并在加密块上维护一个滚动承诺（Rolling Commitment）。
证据生成： AGR 签署推理证据链（IEC）。该对象绑定了：
- 运行时证明和身份。
- 有效策略和合约哈希。
- 路由和回退决策。
- 观测到的端点身份（TLS 验证）。
- 加密流转录承诺（StreamEv）。
- 完成元数据。
验证： 客户端针对受验证的运行时身份验证 IEC，并重新计算流承诺，以确保收到的密文与签署的证据相匹配。

3. 主要贡献

本文做出了四个主要贡献：

问题识别： 识别了第三方 LLM 网关中的多权威信任边界问题，即路由、回退、端点准入和证据编写权都集中在单一的算子控制服务中。
架构设计： 提出了一种拆分平面的架构，将解密、策略执行、上游构建和证据签名移至受验证的运行时（AGR），同时保留业务平面的功能。
机制实现： 引入了携带策略的推理合约和推理证据链，将运行时证明、请求范围策略、路由决策和加密流转录绑定在一起，实现可验证的溯源。
实现与评估： 使用 Rust 在 AWS Nitro Enclaves 上实现了一个原型，并评估了机制开销、路由强制执行和失效关闭（Fail-closed）行为。

4. 实验结果

作者使用带有本地模拟提供商和实时 GPT 端点的 Rust 原型对系统进行了评估。

开销： 在本地确定性模拟环境（并发度 16）中，证据绑定网关（B2）的 p95 延迟为 38.72 ms。
Nitro Enclave 性能： 当运行时置于 Nitro Enclave（B3）中时，p95 延迟略微增加至 46.2 ms（约为本地运行时的 1.1 倍），吞吐量保持了本地基准的 95%。开销主要由传输引起，而非加密操作。
证据成本： 对于 100 个分块的转录，StreamEv 的构建和重计算成本分别为约 130 µs 和 120 µs (p95)。IEC 的签名和验证发生在数十微秒量级。
失效关闭验证： 系统在所有负向控制场景中成功拒绝了篡改尝试，包括：
- 证明/注册表篡改（PCR、随机数、注册表修改）。
- 通道完整性违规（密钥/密文篡改）。
- 路由和回退替换（模型切换、省略回退）。
- 端点约束违规。
- 证据元数据重写和流转录操纵（删除、重排序、重放）。
- 网关投毒（注入的工具调用被拒绝）。

5. 意义与声明

本文声称该架构建立了网关路径溯源真实性。它允许客户端验证：

请求是由特定的、经过度量的运行时中介的。
路由、回退和端点选择遵循了签署的策略。
交付的加密流转录与签署的承诺相匹配。
证据未被伪造，也未从不同的请求上下文中转移。

范围与局限性：
作者明确指出该系统并未声称能做到以下事项：

它并不隐藏流量元数据（时间、数据包大小、频率）。
它并不防止拒绝服务攻击（DoS）。
它不能证明上游 LLM 提供商执行了正确的模型或生成了安全的内容（提供商仍处于 TCB 之外）。
它不保护针对恶意 LLM 提供商、中毒的 RAG 上下文或智能体层级策略违规的攻击。
它依赖于 TEE 平台的可靠性、证明根以及发布签署过程的安全性。

其意义在于改变了信任模型：客户端不再需要信任网关算子既作为路径中介又作为记录编写者。相反，客户端依赖于与度量运行时绑定的密码学证据，从而确保未经授权的路由、隐藏的回退、流操纵和伪造的计费记录能够被检测并拒绝。