Aegon 协议技术总结：基于账本绑定令牌与硬件证明的移动 AI 内容审计

1. 研究背景与问题陈述 (Problem)

随着大型语言模型（LLM）和检索增强生成（RAG）系统的快速发展，AI 平台对网络内容的依赖日益增加。然而，现有的内容许可和访问机制存在严重的协调失败：

• 缺乏可验证的许可机制：AI 平台无法以可验证的方式获取内容许可，导致大量未经授权的抓取（Scraping）和潜在的法律风险（数十亿美元的诉讼暴露）。
• 出版商的两难困境：出版商要么完全封锁 AI 流量，要么允许无补偿的访问，缺乏中间的可信路径。
• 审计缺失：现有的标准（如 RSL）仅能声明许可策略，但缺乏审计基础设施。没有系统能提供防篡改的交易记录，证明内容访问是合法的，且记录未被事后修改。
• 移动端空白：在设备端（如 Android 上的 Gemini Nano、Llama）运行的 AI 代理在推理过程中访问网络内容时，完全缺乏许可基础设施。

核心痛点：缺乏一个能够独立验证、防篡改且包含硬件证明的 AI 内容许可审计系统。

2. 方法论与系统设计 (Methodology)

Aegon 是一个协议设计，旨在通过两个核心层级解决上述问题：Web 协议层和Android 设备证明层。该系统不加密内容，而是专注于构建可审计的许可交易记录和来源证明链。

2.1 系统架构与参与者

• AI 平台：通过 SDK 或 MCP（Model Context Protocol）服务器请求许可，并在内容处理流程中报告事件。
• 出版商：在边缘（Edge）通过 JWKS 验证令牌，无需与许可代理进行实时交互即可交付内容。
• Aegon 代理 (Broker)：受信任的第三方，负责签发令牌、维护不可变账本和 Merkle 树。
• 移动 AI 代理 (Android)：在设备上运行，生成硬件证明的合规收据。

2.2 核心机制

A. Web 协议层 (Web Layer)

1. 扩展的 JWT 令牌：
   • 基于标准 JWT，但增加了特定于内容的许可声明（Claims），如 aegon_scope（范围）、aegon_training_allowed（是否允许训练）等。
   • 设计决策：令牌中不包含内容哈希，因为令牌在获取内容前签发。内容哈希由出版商在交付后计算并记录在账本中，与令牌 ID 关联，实现事后验证。
2. 基于证书透明度 (CT) 的审计账本：
   • 使用追加只写 (Append-only) 的账本（如 PostgreSQL）记录所有许可交易。
   • 构建 Merkle 树，定期发布签名的树头（Signed Tree Head, STH）。
   • 审计验证：第三方审计员可通过 Merkle 包含证明（Inclusion Proofs）独立验证特定交易是否被记录且未被篡改，无需信任代理的实时响应。
3. 签名来源事件日志 (Signed Provenance Event Log)：
   • 追踪内容在 AI 管道中的转换阶段（分块、嵌入、检索、引用）。
   • 每个事件都带有交易 ID (txn_id) 和平台签名，绑定到账本条目。
4. 边缘验证与无代理交付：
   • 出版商使用缓存的 JWKS 在 CDN 边缘验证 JWT，无需每次请求都联系代理，确保低延迟。

B. Android 设备证明层 (Android Attestation Layer)

1. 硬件证明合规收据：
   • 利用 Android StrongBox 安全元件（或 KeyMint TEE）生成硬件绑定的密钥。
   • 设备端 AI 代理在消费内容后，生成签名的合规收据（Compliance Receipts）。
   • 首次应用：这是首次将硬件证明收据应用于移动设备上的 AI 内容许可。
2. 离线批处理与重放防护：
   • 收据在本地加密存储（SQLite + SQLCipher），在网络恢复后批量提交。
   • 使用唯一的 receipt_id 和去重机制防止重放攻击。
   • 使用每出版商的伪匿名标识符 (publisher_scope_id) 防止跨出版商的设备追踪。
3. 代理验证：
   • 验证从设备公钥到 Google 硬件证明根 CA 的完整证书链。
   • 检查设备状态（如拒绝未解锁 Bootloader 的设备）和安全级别（StrongBox > KeyMint）。

3. 主要贡献 (Key Contributions)

1. 可审计的 Web 协议层：
   • 定义了扩展标准 JWT 的内容特定许可语义。
   • 首次将 证书透明度 (CT) 的 Merkle 树审计模型应用于内容许可领域，实现了第三方独立验证。
   • 建立了绑定到账本的签名来源事件日志，追踪 AI 转换阶段。
2. Android 证明层：
   • 提出了基于 StrongBox 安全元件 的硬件证明合规收据，用于设备端 AI 代理。
   • 设计了支持间歇性连接的离线证明批处理机制。
   • 实现了基于 Google 硬件证明 CA 的代理端证书链验证。
3. 参考架构与评估方法：
   • 提供了基于标准组件（FastAPI, Cloudflare Workers, Supabase）的参考实现。
   • 定义了详细的性能评估指标（如令牌验证延迟、账本吞吐量、电池影响等）。

4. 评估与结果 (Results & Evaluation Plan)

注：本文主要提出协议设计和参考架构，具体的实测数据将在后续论文中发布，但文中设定了明确的目标指标。

• 性能目标：
  • 令牌验证（边缘缓存 JWKS）：P95 < 10ms。
  • 令牌签发（100 req/s）：P95 < 50ms。
  • 来源事件开销：< 5ms/事件。
  • StrongBox 签名：P95 < 100ms。
  • 收据大小：< 4KB。
• 安全检测：
  • 能够检测令牌重放、伪造和未授权重用。
  • 通过 5% 的随机内容哈希抽查（Spot-check）机制，威慑出版商和内容平台的不诚实行为（类似于税务审计）。
• 成本效益：
  • 协议完全基于标准 HTTPS，利用现有基础设施，旨在实现“零摩擦”采用。

5. 意义与局限性 (Significance & Limitations)

意义

• 填补关键空白：Aegon 填补了从“策略声明”（如 RSL）到“可验证执行与审计”之间的空白。
• 信任模型创新：通过引入 Merkle 树审计和硬件证明，将信任从单一的代理扩展到了可独立验证的数学证明和硬件根信任。
• 移动 AI 赋能：为设备端 AI 代理提供了首个可审计的许可基础设施，解决了移动端离线场景下的合规难题。
• 法律与商业价值：为出版商提供了可审计的收入证明，为 AI 平台提供了合法的访问证据，有助于解决当前的版权诉讼危机。

局限性与未来工作

• 完整性限制：来源日志是“防篡改”的（Tamper-evident），但无法保证“完整性”（Completeness）。恶意平台可以选择不记录某些事件（如将数据用于训练但不报告）。目前 v1 版本依赖合同条款进行约束。
• 信任假设：代理（Broker）仍是一个受信任的第三方。虽然使用了 HSM 和审计机制，但并未完全去中心化（未来可探索 MPC）。
• 设备覆盖：StrongBox 在部分 Android 设备上不可用，需降级到 KeyMint（安全性稍低）。
• 应用完整性：硬件证明仅验证密钥生成环境，未验证应用本身的完整性（未来计划结合 Play Integrity API）。
• 训练预防：无法在密码学层面完全阻止内容被用于训练，主要依靠事后审计和合同约束。

总结：Aegon 提出了一种创新的、分层的方法来解决 AI 内容许可的可审计性问题。它通过结合标准的 Web 技术（JWT, CT）、区块链思想（Merkle 树）和移动硬件安全（StrongBox），构建了一个能够独立验证、防篡改且适应移动环境的许可生态系统，为 AI 时代的版权保护和商业化提供了重要的基础设施蓝图。