Apple、Meta 和 Google 如今会把部分 AI 请求交给特定的服务器处理。这些服务器在设计上连公司自己的员工也挡在门外，并通过远程证明报告自己加载了哪些软件[1, 6, 8]。Cohere 也通过旗下的 Model Vault 服务提供类似的安排[11]。从公开的设计看，外部人员能核查什么，与其说取决于硬件，不如说取决于建立在硬件之上的三项选择。这三项选择是：公开的软件版本日志、在用户设备上核查远程证明，以及向研究人员开放软件。各家服务商的选择不同，因此“可验证”在不同服务中意味着不同程度的外部核查。
每一项选择都填补了远程证明留下的一个缺口。可信执行环境（TEE）的设计目标是把软件与机器的运营方隔离开来。它的证明报告由芯片内的密钥签名，其中包含度量值，即已加载软件的密码学指纹[6, 7]。度量值能识别加载的是哪个构建版本，却不能说明这个版本如何处理请求[6, 11]。公开日志让设备能够确认该版本已列入外界可以查看的记录。由设备自己核查远程证明，服务商就不能单方面宣称其服务器已通过检验。向研究人员开放软件，则让外部人员能够检查这个版本做了什么。
Apple 公开每个构建版本及其运行工具
Apple 的 Private Cloud Compute（PCC）于 2024 年 6 月公布，三项选择全部采用。只有当服务器节点在远程证明中报告的度量值，与一份公开、只追加的透明日志中的某个版本相符时，用户设备才会把请求加密发送给该节点。Apple 还承诺，每个生产镜像（即服务器节点启动的软件）会在记入日志后 90 天内发布[1]。2024 年 10 月，Apple 推出虚拟研究环境（Virtual Research Environment，VRE），同时以有限使用许可公开了部分组件的源代码。借助 VRE，任何人只要有一台符合要求、搭载 Apple 芯片的 Mac，就能下载已记入日志的版本，并在虚拟机中启动。因此，设备核查过哪份软件的度量值，研究人员就能运行这份软件略经修改的副本[2]。
Apple 在 2026 年 6 月扩展 PCC，把新的 Apple Intelligence 工作负载转到 Google Cloud 上运行。这一部署使用 NVIDIA 机密计算 GPU、支持 Trust Domain Extensions（TDX）的 Intel CPU 和 Google 的 Titan 芯片。Apple 称，它为这批硬件维护一份只追加账本，并将公开全部二进制文件。Apple 还称，对于一旦被攻破就可能泄露用户数据的组件，其远程证明植根于至少两家独立厂商的信任根（系统中无须进一步核查即被信任的部分）[3]。外部核查仍然滞后。Apple 的发布说明把这一部署描述为预览版，称其正逐步具备 PCC 完整的安全、隐私和透明特性。发布说明还表示，VRE 要支持这一部署的远程证明和日志条目，有待 2026 年晚些时候推出的公开研究计划[3, 4]。
Meta 公开度量值，二进制文件按协议提供
Meta 于 2025 年为 WhatsApp 推出的 Private Processing 同样把核查放在设备上。应用在发送请求前，会与一台机密虚拟机（CVM）建立会话；CVM 是作为 TEE 运行的虚拟机。会话采用结合远程证明的传输层安全（RA-TLS），把加密连接与 CVM 的远程证明绑定在一起。应用还会将 CVM 的度量值与第三方账本交叉核对[5]。Meta 在 2026 年 9 月介绍面向 AI 眼镜的方案时称，该账本只追加、接受公开见证。介绍中还说，度量值是公开的，二进制文件则在签署协议后提供给参与 Meta 安全计划的研究人员。Meta 表示，部署的代码一旦与公开记录不符，客户端设备和外部监测方都能发现，并称这一性质为篡改可检测性（tamper-evidence）。但要确认已记录的镜像究竟做了什么，则需要二进制文件[6]。
Trail of Bits 在这套 WhatsApp 系统上线前做过审计，结果说明了这种访问权限为何重要。审计共报告 28 个问题，其中 8 个为高危[7]。有一个问题是，配置文件在度量完成之后才加载，内部人员本可借此注入代码，而远程证明依然能通过验证。还有一个问题是，向操作系统描述硬件的数据表没有纳入度量。由于这两类输入都在度量范围之外，篡改它们不会改变度量值，因此账本核对也照样会通过。Meta 已修复这两个问题。Trail of Bits 还指出，外部验证需要研究人员复现并检查 CVM 镜像，而要做到完全可复现仍有难度[7]。
Google 的设计把多数远程证明核查放在公司内部
Google 的 Private AI Compute 在经过加固的张量处理单元（TPU）平台上运行 Gemini 模型。Google 称，该平台提供的隐私与安全特性与典型的 TEE 相当。Private AI Compute 的 CPU 服务运行在采用 AMD Secure Encrypted Virtualization-Secure Nested Paging（SEV-SNP）的 CVM 中[8]。与 Apple 和 Meta 相比，更大的区别在于远程证明在哪里核查。按照 NCC Group 在 2025 年评估中描述的信任链，设备信任的是内置于客户端的一个公钥。Google 的密钥存储服务只为持有令牌的前端服务器解密请求。令牌由 Google 的中央编排系统 Borg Prime 在验证服务器的远程证明后签发[9]。
NCC 写道，只有 Google 以及获得其内部访问权限的外部审计方，才能验证组件是否已被攻破。NCC 还认为，Google 作为一个整体仍有能力泄露用户数据，尽管任何单个内部人员都做不到[9]。
Google 在 2026 年 9 月的更新中把一部分证据移到了公司外部。新推出的记忆存储按用户划分并经过加密，运行在开源的服务端程序和运行时之上。Google 通过两种方式，把公开的源代码与实际部署的安全飞地对应起来。一是可复现构建：任何人重新构建源代码，都能得到相同的二进制文件。二是一份只追加账本，记录经过背书的二进制文件摘要（即哈希值）[8]。在设备端，一个开源 Android 库会先验证记忆存储所在安全飞地的远程证明，再发送用户的密钥[10]。对于系统的其余部分，Google 公布了关键组件的摘要，并把两项内容列为后续工作：在设备端校验证明证据，以及由独立第三方共同签名的日志[8]。Trail of Bits 指出，Google 可以不经事先的外部审查就修改系统，而且系统包含大量闭源代码[10]。
Cohere 依靠 Intel 核查证明证据
在基于 Intel TDX 的部署中，Cohere 的 Model Vault Encrypted 依靠 Intel Trust Authority，这是 Intel 运营的远程证明服务。该服务对照 Cohere 登记的策略，核查每台 CVM 的 CPU 和 GPU 证据；策略中列明了预期的度量值。Cohere 的客户端代理会先验证 Intel 签名的令牌，再发送请求。Cohere 称，其 vault 镜像和工作负载均为开源，并采用可复现构建[11]。最终核查由客户自己的客户端完成。Intel 本身也是 CPU 的制造商，同时作为验证方处在客户与 Cohere 之间。
四种设计对比
| 设计 | 软件记录 | 由谁核查远程证明 | 外部检查 |
|---|---|---|---|
| Apple PCC（Apple 芯片）[1, 2] | 公开的只追加日志；二进制文件在登记后 90 天内发布 | 用户设备 | 公开的二进制文件、VRE、部分源代码、漏洞赏金计划 |
| Apple PCC（Google Cloud，预览版）[3, 4] | 同一份日志；VRE 暂时无法解析这些版本 | 用户设备；保护措施正逐步到位 | 研究计划预计 2026 年晚些时候推出 |
| Meta Private Processing[5, 6, 7] | 度量值记入接受公开见证的账本 | 用户设备 | 按协议提供的二进制文件、漏洞赏金计划、已公开的审计报告 |
| Google Private AI Compute[8, 9, 10] | 记录关键组件摘要的账本 | Google 基础设施；记忆存储由用户设备核查 | 具有内部访问权限的审计、开源的记忆存储服务器 |
| Cohere Model Vault Encrypted[11] | 在 Intel Trust Authority 登记的策略 | 客户的客户端，凭 Intel 签发的令牌 | Cohere 称其技术栈开源 |
四种设计仍需信任的环节
第一项需要信任的是硬件。2026 年 9 月，研究人员披露了 DDRop：这种装置用约 160 美元的零件搭成，能悄无声息地丢弃对服务器 DDR5 内存的写入。内存中于是留下过时的数据，而 Intel TDX 和 AMD SEV-SNP 的内存加密都无法察觉。在 TDX 上，研究人员用它让一台受自己控制的恶意 CVM 以合法工作负载的度量值通过了远程证明。在 SEV-SNP 上，他们用它复制了受害者的内存页。这种攻击需要一次短暂的现场物理接触，外加对宿主机软件的控制。Intel 和 AMD 把物理内存攻击视为当前产品防护范围之外的问题[12]。
Apple、Meta 和 Google 面对这一依赖的方式各不相同。Apple 增设了一份硬件账本和第二个独立的信任根[3]。Trail of Bits 发现，由于 SEV-SNP 不能完全防御高级物理攻击，Meta 需要额外的控制措施，限定哪些 CPU 可以信任[7]。NCC 指出，就 Google 的 TPU 而言，必须信任的硬件制造商就是 Google 自己[9]。
第二项是度量值没有覆盖的内容。除了 WhatsApp 的审计发现，Apple 的发布说明也披露：在后来的一个版本之前，系统读取某个配置值时并未经过远程证明。这个配置值决定某些智能体工具是否隔离运行[4]。NCC 发现，尚不清楚部分 Google 二进制文件是否依赖透明日志未追踪的配置包[9]。日志过滤器和出站规则（管控外发网络流量的规则）决定哪些内容会离开受保护的机器[1, 5, 8]。外部人员只能在看得到代码的范围内核查它们，而 Apple 公开了其过滤器的代码[2]。Trail of Bits 还发现，Google 为了检查响应是否复述受版权保护的内容，会把响应片段的截断哈希发送到可信边界之外。这个问题尚未解决，Trail of Bits 将其评为高危，但认为难以利用[10]。
第三项是记录本身。Apple 可以把已记入日志的构建版本推迟至多 90 天再发布，因此一个版本可能在外界能够下载之前就已开始处理请求[1]。验证代码同样需要审查。Trail of Bits 在 Google 的远程证明核查和账本核查中发现两个缺陷（现已修复）。这些缺陷本可让两名或更多未经授权的内部人员联手部署经过修改的服务，而账本上不会出现公开可见的条目[10]。
尚待回答的问题
第一个问题是，已承诺的核查能否兑现，例如 Apple 针对 Google Cloud 上 PCC 的研究计划，以及 Google 的设备端验证[4, 8]。
第二个问题是谁来监看日志。一个有害的构建版本即使按规定记入了日志，也只有监看日志、并且能检查该版本的人才能发现。对于 Meta 的二进制文件和 Google 的闭源代码，这种检查需要服务商授予访问权限[6, 10]。
第三个问题涉及存储的状态。Google 的记忆存储、Meta 为眼镜提供的加密存储，以及 Apple 在多轮对话之间复用加密的模型中间状态，都让用户数据保留到单次请求之后[4, 6, 8]。远程证明在设备连接时核查，描述的是服务器加载了什么软件。至于外界应当如何核查已存储的数据此后经历了什么，目前还没有定论。
来源
- Private Cloud Compute: A new frontier for AI privacy in the cloud
- Security research on Private Cloud Compute
- Expanding Private Cloud Compute
- Private Cloud Compute Security Guide: Release Notes
- Building Private Processing for AI tools on WhatsApp
- Bringing Private Processing to Meta AI Glasses
- What we learned about TEE security from auditing WhatsApp's Private Inference
- Google Private AI Compute: Enabled with Secure Server-Side Memory
- Private AI Compute in the Cloud: Assessment Overview
- Google Private AI Compute, Secure Server-Side Memory: Security Assessment
- Remote Attestation (Model Vault Encrypted documentation)
- DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes
核查或更正本页
- 更正
- 提交更正请求 · 在 GitHub 编辑源文件 · 更正政策
