Each language version is independently generated for its own context, not a direct translation.
这篇论文介绍了一个名为 AEX 的新系统，旨在解决大语言模型（LLM）在使用远程 API 时面临的“信任危机”。
为了让你轻松理解，我们可以把使用大模型 API 想象成在一家著名的餐厅点菜。
1. 背景：为什么我们需要 AEX？（“影子菜单”的危机）
想象一下，你走进一家名为“谷歌”或“OpenAI"的著名餐厅，点了一道招牌菜（发送了一个问题给 AI）。
- 理想情况：厨师（AI 模型）根据你的订单，亲手做了一道菜端上来。
- 现实问题：最近有人发现，有些“影子餐厅”（Shadow APIs）或者中间商，声称他们卖的是“谷歌招牌菜”，但实际上可能：
- 端上来的是隔壁小摊的廉价菜（模型不对）。
- 偷偷把菜里的肉换成了豆腐（内容被篡改）。
- 甚至根本没做菜，只是把以前的剩菜端上来（回复被缓存或伪造）。
目前的验证方法（比如“指纹识别”）就像是你尝一口菜，猜它是不是招牌菜。但这很不可靠，因为厨师可能换了一种做法，味道差不多但本质不同。
AEX 就是为了解决这个问题而生的“官方防伪标签”系统。
2. AEX 是什么？（“带签名的透明信封”）
AEX 的核心思想非常简单：在现有的 API 协议上，加一个“带数字签名的透明信封”，证明“你点的菜”和“端上来的菜”是严格对应的。
它不要求改变餐厅的厨房（不需要更换 AI 模型），也不要求你重新发明一种点菜方式（保持现有的 JSON 格式），它只是在端上来的盘子上贴了一张不可伪造的标签。
这个标签里写了什么？
- 订单快照：把你点菜时的原始要求（比如“要微辣”）加密成一个指纹。
- 菜品快照：把端上来的菜（回复内容）也加密成一个指纹。
- 厨师签名：餐厅老板（可信的发行方）用私钥给这个“订单 - 菜品”的配对签了名。
只要这个签名验证通过，你就知道：
- 这确实是这家餐厅端出来的。
- 这确实是按照你的要求（或者经过允许的修改）做出来的。
- 中间没有人偷偷换过菜。
3. AEX 的三大绝招（解决现实中的复杂情况）
在现实世界中，菜在送到你桌上之前，可能会经过很多环节。AEX 设计了三种巧妙的机制来处理这些情况：
绝招一：灵活的“订单绑定”模式（Request Binding）
- 场景：你点菜时说“要微辣”，但餐厅服务员（网关）为了系统稳定，偷偷在后台加了一个“默认辣度”的备注，或者加了一个“订单追踪号”。
- AEX 的做法：它允许你选择“严格模式”或“宽容模式”。
- 如果你选严格模式，任何额外的备注都会导致标签失效（证明菜被改了）。
- 如果你选宽容模式，系统会忽略那些被允许的“备注”，只验证核心内容。
- 比喻：就像你点外卖，如果外卖员只是贴了个“小心轻放”的贴纸，你依然能吃到原味；但如果他把“微辣”改成了“特辣”，标签就会报警。
绝招二：流式传输的“进度条”验证（Streaming Proofs）
- 场景：现在的 AI 回复是像流水一样一个字一个字蹦出来的（流式）。如果网络断了，或者中间有人插话、删字，怎么办？
- AEX 的做法：它给每一个蹦出来的字都打上了“连环锁”。
- 模式 A（源头直连）：如果菜是厨师直接端给你的，每端上来一块肉，就有一个小标签证明“这是第 1 块，第 2 块..."。如果中间少了一块，链条就断了，你立刻知道被篡改了。
- 模式 B（加工后交付）：如果菜经过了一个“中央厨房”（中间商）重新包装（比如把流式回复打包成一个完整的文档），那么之前的“进度条”就作废了。中央厨房会发一个新的“完整包装证明”，告诉你：“这盘菜虽然包装变了，但它确实源自那个厨师做的原菜。”
绝招三：可信的“中间商”链条（Trusted Transforms）
- 场景：有时候，为了安全，网关会帮你把回复里的敏感信息（比如电话号码）抹掉，或者把长文总结成短文。这算篡改吗？
- AEX 的做法：它不把这些视为“作弊”，而是视为“合法的加工”。
- 系统会生成一张**“加工收据”**。
- 比喻：就像你买了一块生牛肉（原菜），经过中间商（网关）加工成了牛排（新菜）。AEX 会给你一张收据，上面写着：“这块牛排确实源自那块生牛肉，只是经过了‘去骨’和‘煎制’处理，且处理过程由可信的厨师签名确认。”
- 这样，你既知道菜被加工了，又知道加工是合法的，而不是被坏人偷换的。
4. AEX 不能做什么？（诚实的局限性）
AEX 很诚实，它明确告诉你它不能证明什么：
- 它不能证明菜好吃：它只能证明菜是这家店做的，不能保证味道好（不能证明 AI 的回答是事实正确的）。
- 它不能证明厨师没偷看你的日记：它不能保证 AI 没有偷偷读取你的隐私数据（Hidden Prompts）。
- 它不能证明厨师没换人：如果餐厅老板自己就是坏人，签了假名字，那也没用（信任的根源在于你信任那个签名者）。
5. 总结：AEX 带来了什么？
简单来说，AEX 就像给大模型 API 的每一次对话都加了一个**“区块链级别的发票”**。
- 以前：你收到回复，只能猜：“这真的是 OpenAI 做的吗？还是被中间商篡改了？”
- 现在：你收到回复，附带一个**“带签名的透明信封”**。你打开信封，里面写着：“这是由 OpenAI 的厨师，根据你的订单（或经授权的修改），在特定的时间，经过特定的加工流程，最终生成的。”
这让开发者、审计员和普通用户都能放心地使用大模型 API，不再担心被“影子 API"欺骗，也不用担心数据在传输过程中被悄悄修改。它让大模型的“黑盒”多了一层透明的、可验证的“信任之墙”。
Each language version is independently generated for its own context, not a direct translation.
1. 问题背景 (Problem Statement)
随着 LLM 主要通过远程 API 被消费，信任边界已从本地执行转移到了 API 边界。然而，现有的 API 边界缺乏直接证据来证明返回的输出确实对应于客户端可见的请求。
- 影子 API (Shadow APIs) 的威胁： 近期审计发现，许多非官方或中间端点声称兼容官方模型，但实际上存在功能偏差（Utility Divergence）高达 47.21%，且指纹验证失败率高达 45.83%。
- 现有方案的局限性：
- 指纹识别与统计测试： 只能推断模型身份，无法证明特定请求与特定响应的绑定关系，且无法检测行为偏差。
- 可信执行环境 (TEE) 远程证明： 证明的是运行环境而非具体的 API 请求/响应对象，且通常具有侵入性。
- 可验证推理 (Verifiable Inference)： 往往要求暴露模型内部证据，难以在现有黑盒 API 上部署。
- 核心痛点： 现有的 LLM API 缺乏一种机制，能够以非侵入式的方式，提供在线、可验证的证据，证明特定的客户端请求与特定的响应对象（或流式输出序列）之间存在绑定关系，同时允许受信任的中间件进行合法的请求重写或输出转换。
2. 方法论与核心设计 (Methodology & Design)
AEX 提出了一种协议扩展层，通过添加一个签名的顶级 attestation 对象来绑定请求和输出，而不改变现有的 JSON 业务语义。
2.1 核心机制
- 非侵入式设计： 保持现有的请求/响应语义、工具调用、流式传输和错误处理不变。仅在 JSON 响应中添加一个顶层的
attestation 字段。
- 基于规范的哈希 (Canonicalization)： 使用 JCS (JSON Canonicalization Scheme) 将 JSON 对象转换为规范字节序列，确保即使传输格式（如空格、字段顺序）不同，哈希值依然一致。
- 密码学承诺 (Commitments)：
- 请求承诺 (Request Commitment)： 对客户端可见的请求投影进行哈希。
- 有效请求承诺 (Effective Request Commitment)： 对经过受信任中间件重写或规范化后的实际执行请求进行哈希。
- 输出承诺 (Output Commitment)： 对完整的非流式响应对象或完整的认证流式链进行哈希。
2.2 关键特性
- 显式请求绑定模式 (Explicit Request-Binding Modes)： 客户端可自主选择绑定严格度：
full：绑定整个请求对象。top_level_exclude：排除特定顶层字段（如追踪 ID）。top_level_include：仅绑定指定的顶层字段，并显式绑定缺失字段（防止中间件静默注入新字段）。
- 流式传输证明 (Streaming Proofs)：
- 源流前缀模式 (Source-Stream Prefix Mode)： 适用于未转换的原始流。使用双锚点哈希链（以请求承诺为种子），允许对前缀进行断点检查（Checkpoint），验证部分输出的完整性。
- 完整输出谱系模式 (Complete-Output Lineage Mode)： 适用于经过转换（如缓冲、聚合、重打包）的输出。禁止前缀检查，转而提供从源输出到最终输出的签名转换链（Origin-Output + Output-Transforms），确保最终输出的可追溯性。
- 受信任的转换链 (Trusted Transform Chains)：
- 请求转换收据 (Request-Transform Receipts)： 允许受信任的中间件（如网关）对请求进行重写，并生成签名收据，解释从原始请求到有效请求的变更。
- 输出转换收据 (Output-Transform Receipts)： 允许中间件对输出进行重写、脱敏或格式转换，通过签名链连接源输出承诺和最终输出承诺。
2.3 信任模型
- 签发者 (Issuer)： 签署证明的实体（可以是模型提供商、网关或中间件）。
- 验证者 (Verifier)： 客户端、SDK 或审计方，负责验证签名和承诺匹配。
- 密钥发现： 基于标准的 JWKS (JSON Web Key Set) 机制，通过
/.well-known/aex-keys.json 发现公钥。
3. 主要贡献 (Key Contributions)
- 问题定义： 明确了托管 LLM 服务在 API 边界处的证明问题，并指出影子 API 审计数据使其具有紧迫性。
- AEX 协议设计： 提出了一个非侵入式的协议扩展，包含请求承诺、完整输出承诺、显式绑定模式、签发者签名及输出模式感知的谱系元数据。
- LLM 专用机制：
- 双锚点流式哈希链（Dual-anchor streaming hash chain）。
- 显式的受信任请求转换链。
- 源输出/输出转换收据模型（Source-Output / Output-Transform Receipts）。
- 安全与隐私分析： 详细分析了重放攻击、静默篡改、信任根限制以及隐私影响（如低熵请求的字典攻击风险）。
- 原型实现与验证： 提供了一个 TypeScript 参考原型，包含 OpenAI 兼容的聊天完成配置，并进行了本地一致性测试和微基准测试。
4. 实验结果 (Results)
论文构建了一个包含网关、受信任代理（Proxy A/B）和模型模拟器的测试床，进行了以下验证：
- 功能验证：
- 通过了 29 个单元测试（覆盖请求绑定、证明签发/验证、谱系收据、流式验证等）。
- 通过了 25 个集成测试（覆盖端到端网关/代理/提供商流程、转换链、负路径状态如截断和篡改）。
- 通过了 6 个浏览器端到端测试。
- 性能基准 (微基准测试)：
- 非流式场景： 客户端完成中位延迟约 2.287 ms，网关验证时间约 0.495 ms。
- 流式场景（断点模式）： 首块延迟约 1.736 ms，完整验证时间约 0.843 ms（注：总延迟受模拟器固定延迟影响较大，主要体现验证开销极小）。
- 转换链场景： 引入请求转换和输出谱系后，验证时间略有增加（约 0.952 ms - 1.491 ms），主要开销在于 JWKS 获取和多重签名验证，但整体开销极低，适合生产环境。
5. 意义与局限性 (Significance & Limitations)
意义
- 填补空白： 为现有的 LLM API 提供了一种低摩擦、可部署的“请求 - 输出”绑定层，无需修改模型内部或传输协议。
- 平衡信任与灵活性： 既防止了中间件的恶意篡改，又允许受信任的中间件进行必要的业务逻辑转换（如 Prompt 优化、内容过滤、格式转换），并通过签名链保留溯源。
- 标准化路径： 提出了与 OpenAI 兼容的 Profile，易于集成到现有的 SDK 和网关中。
- 区分证明范围： 明确区分了“证明请求与输出的绑定”与“证明模型身份/事实正确性”，前者是 AEX 的核心，后者需结合 TEE 或指纹技术。
局限性与未来工作
- 不证明模型真实性： AEX 不证明输出是否真实、模型权重是否特定，也不证明没有隐藏提示词。
- 信任根依赖： 如果签发者本身是恶意的，或者验证者信任了错误的签发者，证明将失效。
- 前缀到前缀的转换限制： 在 v1 版本中，一旦输出被转换，不再提供前缀到前缀的证明，仅提供完整输出的谱系证明。
- 本地测试： 目前的性能数据基于单机模拟器，尚未在大规模生产 WAN 环境中验证。
- 跨语言互操作性： 目前缺乏公共的跨语言验证库和测试向量。
总结
AEX 通过引入一个轻量级的、基于签名的元数据层，解决了 LLM API 中请求与响应之间缺乏可验证绑定的问题。它巧妙地平衡了安全性（防篡改、防重放）、隐私性（可选的绑定模式）和部署可行性（非侵入式、兼容现有 JSON 格式），为构建可审计、可溯源的 LLM 生态系统提供了重要的基础设施。