Google Private AI Compute 新增服务器端记忆：第三方审计里 8 项已修、2 项未修

2026 年 9 月 23 日，Google DeepMind 上线了一篇技术更新：Private AI Compute 平台将支持持久化的服务器端记忆，让 AI 助手跨会话、跨设备记住用户。博客称解锁这份记忆的密钥「只保存在你自己的设备上」，因此数据「对任何其他人不可访问，包括 Google」1。

同一天更新的还有一份 15 页的《Private AI Compute Technical Brief》，把密钥体系、持久数据的威胁模型和外部可验证性逐条写开2。两天前的 9 月 21 日，安全公司 Trail of Bits 交付了针对这次新功能的公开评估，列出 10 项发现，其中 8 项已修复、2 项未修复3。三份材料互相对得上，也互相补得上。

Private AI Compute 在 2025 年 11 月 11 日就已经发布过，当时 Google 把它描述成一个把 Gemini 云模型的算力拿出来用、同时保持设备端隐私保证的 AI 处理平台，署名作者是负责 AI 创新与研究的副总裁 Jay Yagnik4。那个版本严格无状态。所以这次要回答的问题是：这些隐私主张里，有多少今天就能被外部核实，有多少还写在官方自己的「下一步」里。

无状态的 Private AI Compute 把请求放进云端隔离环境处理，处理完即丢弃。技术简报把这套设计写成「ephemeral by design」：输入、模型推理和中间计算只在完成这次查询所需的时间内保留，攻击者拿不到过去的数据2。

坎出在连续体验上。一个记得你长期项目、记得它替你做过的决定、记得你过去几次会话里流露的偏好的助手，需要上下文活过单次调用。官方举的例子是在笔记本上打开之前通过智能眼镜看过的装配说明，或者在手机和网页之间接着一段复杂对话1。简报还把三条替代方案否掉：本地存储在物理容量上有上限、跨设备同步有摩擦、把海量历史上下文反复通过网络传给云端前沿模型，带宽和延迟都难以承受2。

补上的是一块持久层。「记忆」在评估报告里的定义是文本块加上配套的向量与元数据，以加密形态存在 Google 的服务器上，只在机密计算环境内部还原3。

架构的核心是把「能不能解密」这一步绑在「这个 enclave 是不是被背书的那个二进制」上。记忆记录用按用户绑定的密钥加密，密钥材料只在已证明的可信执行环境内以明文出现；向记忆服务器放行密钥以证明为门，拿不出与已背书记忆二进制匹配的有效证明的 enclave，包括被改过或未授权的构建，都拿不到密钥2。Trail of Bits 的措辞与之吻合：密文存在 Google 的基础设施里，但除了在机密虚拟机内的单次请求上下文里，任何地方都取不到3。

硬件分成两条线。CPU 工作负载跑在基于 AMD 硬件可信执行环境的机密虚拟机里，内存加密、与宿主机隔离，代码通过证明核验；TPU 工作负载跑在 Google 自己的加固 TPU 平台，官方的说法是它提供「与典型可信执行环境相当的隐私与安全属性」，产品名是 Titanium Intelligence Enclave2。这两条线要分开看：加固 TPU 平台是 Google 自己的设计，评估报告也写明本次没有深入验证它。

承载记忆的是一个叫 memory Oak Server 的有状态、按用户划分的数据库，跑在硬件 TEE 内部；新记忆通过一个编排器在 AI 模型与记忆库之间流转，确保数据路由、模型调用与存储操作都不越过受保护边界2。这套东西开源了：memory Oak Server 与 Oak Containers 运行时都在 Google 的 Oak 项目里，用 Rust 写，官方的理由是持久化状态的固有风险远高于临时计算，所以要把内存服务开放给独立公众审查25。仓库是 Apache-2.0 许可，2019 年建仓，发布当天的 2026 年 9 月 23 日仍有推送记录6。

无状态那一代有一条少见的保证。技术简报写明，Private AI Compute 用第三方运营的 IP 遮蔽中继把所有流量隧道转发，使攻击者无法把你的 IP 地址或其他网络标识信息与某次查询对上，另有 Anonymous Tokens 把设备认证与限流从推理路径上隔离出去2。

有状态这一代把这条撤了，而且是官方自己写的。同一份简报在「持久数据的威胁模型」一节给出理由：一次请求必须到达某个用户的库，系统就得解析一个稳定的、按用户划分的标识符，因此「the stateful system does not claim network-level non-targetability」；换来的是即便有人瞄准了某个用户的记忆，拿到的也只是不透明密文，没有用户密钥就不可读2。Trail of Bits 独立复述了同一件事：无状态的请求保留匿名路由带来的不可定位保证，而服务器端记忆下，用户在 enclave 之外的系统运行期间是已知的3。

博客正文写的是「keeping your information private as if it never left your device」，也就是「和没离开你的设备一样」。这句话在无状态那条路径上有两层支撑（内容加密加网络层不可定位），在有状态这条路径上剩下内容加密这一层。对有状态的请求，Google 的前端和路由系统在运行期间知道是谁在请求。

这一条线上有两份公开审计。2025 年那份由 NCC Group 做，覆盖架构评审与若干组件的密码学评估，动员 10 名顾问、共 100 人日，工作期是 2025 年 4 月到 9 月7。这次这份由 Trail of Bits 做，重点是新加的服务器端记忆、客户端证明校验与 Noise 加密连接逻辑，4 名顾问、5 工程师周，审查期 2026 年 6 月 4 日到 7 月 17 日，8 月 7 日完成修复复核，9 月 21 日交付最终报告3。

10 项发现按严重度与状态摊开是这样的：

两条未修复的值得单独说。第 1 项指向一个能力缺口：删除请求执行之后，系统在密码学上无法保证记录不可恢复，报告给的严重度是低。第 9 项更值得留意：为了阻止模型复述受版权保护的内容，回应片段会算出确定性哈希并发给非机密服务，哈希因此落在受信计算基之外；报告把它定为高严重度、未修复，同时注明利用它需要特权内部访问、并且「技术上难以稳定利用」，Google 正在把大部分这类哈希收回受信计算基内。

已修复的那 8 项里，有两项直接指向这次发布最核心的说法。第 4 项与第 6 项合在一起，本可以让两个或更多内部操作者串谋部署被修改过的服务，而在公开的透明账本里不留下可见条目3。博客说的「防篡改的服务器软件公开记录」，其自身的校验逻辑正是这批发现里被修掉的一处。第 2 项则涉及内部操作者可以改变记忆被访问时的上下文。报告在被审代码里没有找到任何允许 Google 员工访问用户数据的机制3。

评估报告的覆盖范围写得比官方摘要更清楚：团队没有对 PAIC 全系统、加固 TPU 平台或 Oak 基础设施做完整代码审查——这三块由 NCC 2025 那次覆盖；本次也没有把物理安全与 Google 内部主机安全作为重点3。所以这份审计的落点是「按 Google 自己列出的四条隐私主张逐条核对」，覆盖范围止于这四条。

技术简报的「外部可验证性」与「下一步」两节，把同一件事拆成了两档，正好是一张可核性对照表。

这张表里最该先看的是第一行。简报在前一节写「客户端会在传输任何数据前核验这把密钥」，又把「从 Google 断言的合规走向客户端密码学验证」列进下一步2；两句话描述的是同一件事的两个档位。Trail of Bits 审查的对象里恰好包含客户端证明校验逻辑，也恰好在这条链上留下了第 6 项发现3。

今天能自己动手的部分还有一处：在受支持的 Pixel 与 Android 设备上，Private AI Compute 的网络请求可以直接在 Network Logs 里检视2。这是全篇唯一一个不需要第三方、也不需要读代码就能做的验证动作。

带走的：记忆这次是被放进硬件隔离的持久库，用与用户绑定的密钥加密，密钥放行以证明为门——能不能解密取决于这个 enclave 是不是被背书的那个二进制，这是这次发布里最实的一层2。有状态这条路撤掉了无状态那一代的网络层不可定位，官方技术简报与第三方评估都写了这件事，读博客正文时容易漏23。审计的 10 项发现里 8 项已修、2 项未修，其中第 9 项是高严重度且未修，第 1 项说明记忆删除没有密码学保证3。

还没有的，得列清楚。三份材料一个字都没提跨设备与密钥位置之间怎么自洽：如果解锁密钥只存在你的设备上，换机、丢机、多设备同步、账号恢复时密钥怎么到达新设备？博客承诺的是跨设备连续性，答案不在公开材料里。整批材料里也没有任何性能与容量读数——没有时延、没有每用户记忆量上限、没有成本、没有上线日期、没有支持设备的范围。产品侧的边界同样没写：这套平台记忆与设备侧已有的个人上下文如何分工，哪些 Google AI 体验会先用上它，官方只说了是「下一代 agentic 与依赖长期上下文的体验」。