AI 系统的可验证程度，取决于开发者以外的人在多大程度上能够依据证据，核查关于该系统的某项具体声明。声明是关于特定系统的精确陈述，例如是哪个模型回答了某个请求，或是哪些软件处理了这个请求。证据指开发者自身说法之外的材料，例如签名、由硬件签名的报告或数学证明。验证方是审查证据、判断声明是否成立的一方。每一次核查都建立在信任假设之上，即核查范围之外的组件或参与方，例如芯片制造商的签名密钥。
\n这一定义以 Brundage 等人 2020 年发表的一份报告为基础。报告把可验证声明定义为可证伪的陈述，证据和论证可以用来评估这类陈述为真的可能性[1]。因此，可验证性是一个程度问题。同一项声明也可能对一方而言可以核查，对另一方却不透明。
\n如果提出声明的一方是该声明唯一的信息来源，它的说法就无法判定声明是否成立。这一点很重要，因为云端 AI 服务会处理个人数据，AI 智能体的用户也依赖开发者对安全措施如何执行的说明[2, 11]。Apple 在 2024 年介绍 Private Cloud Compute（PCC）时提出了同样的观点。PCC 是 Apple 的云端系统，用于支撑要求更高的 AI 功能。Apple 指出，当一项云端 AI 服务声称不记录某些用户数据时，研究人员通常无法验证这一承诺[2]。
\nPCC 的设计也缩小了承诺与验证之间的差距。Apple 称，PCC 完成请求后会删除用户数据，返回响应后“不会以任何形式保留用户数据”[2]。用户无法亲眼看到删除过程，因此这套设计增加了一些范围更窄、可以由设备核查的声明。按照 Apple 的设计，用户设备只把数据发送给满足条件的 PCC 节点：节点必须能以密码学方式完成远程证明，表明自己运行的是公开列出的软件。Apple 还承诺把这些软件的度量值（即密码学哈希值）发布到一份只追加的透明日志中，并发布生产软件镜像供研究人员使用[2]。设备可以确认自己在与哪个软件通信。但这个软件是否保留数据，要留给分析这些镜像的研究人员判断。
\n本站把声明归入验证栈的各个层级。下层支撑上层：要知道是哪个模型作答，先要知道运行它的是哪些软件和硬件。
\n| 层级 | 典型声明 | 证据示例 |
|---|---|---|
| 硬件与算力 | 计算确实在真实硬件的受保护模式下运行。 | 由硬件签名的证明报告[3] |
| 软件与运行时 | 处理请求的正是这份代码和配置。 | 与公布的数值比对过的度量值[2, 3] |
| 模型与数据 | 这些就是发布的权重，签名之后没有改动。 | 经过签名的模型文件哈希清单[6] |
| 输出与内容 | 这一输出由该模型根据该输入生成。 | 推理证明或重新执行核查[4, 5] |
| 智能体与行动 | 所声明的护栏在该智能体作答之前已经运行。 | 基于硬件的远程证明，表明护栏代码已运行[11] |
| 评测与审计 | 这个分数来自所声明的模型和测试集。 | 在可信执行环境中运行的评测，或访问权限更深的审计[8, 10] |
| 政策 | 开发者或政府信守了关于训练算力的承诺。 | 拟议方案：监测大规模训练所用的芯片[12] |
每类证据回答的问题，都比读者关心的声明更窄。每类证据也都会把信任转移到别处。
\n密码学证明。零知识证明让服务商能够表明，某个输出是由给定输入和一个已承诺的模型计算得出的，同时不泄露模型权重。所谓对模型作出承诺，是指服务商公布一个由权重算出的密码学值，从而把自己绑定到这组权重上。在 zkLLM 中，模型架构是公开的，服务商对其权重作出承诺。作者报告，他们为一个 130 亿参数模型的推理生成证明，用时不到 15 分钟，证明大小不到 200 kB[4]。验证方仍要信任证明系统的可靠性（soundness），即虚假的命题无法得到证明。验证方还需要另外的证据，确认已承诺的权重就是对外宣传的那个模型的权重。
\n基于硬件的远程证明。可信执行环境（TEE）是处理器中一种由硬件隔离的执行模式。它会记录所加载软件的密码学哈希值（称为度量值），并把这些度量值写入证据，用植根于硬件的密钥签名后报告出来[10]。在互联网工程任务组（IETF）的远程证明架构中，验证方把这些证据与参考值和制造商的背书相比对。依赖方再根据结果决定是否信任这台机器[3]。远程证明能够确定真实硬件在受保护模式下加载了哪些软件。但硬件制造商以及所度量软件的行为仍然需要信任。
\n签名与透明日志。签名把特定的字节与签名者的密钥绑定在一起。Sigstore 的模型签名库会为模型的每个文件计算哈希值，汇总成一份清单，再为清单签名。用户因此可以核查，下载的模型是否就是某个已知身份签署的内容。如果通过 Sigstore 签名，签名事件会记录在一份只追加的透明日志中，签名者可以在日志里留意有没有并非自己所做的签名[6]。这类记录能够确定谁签署了什么，也让暗中替换变得可以察觉。至于所签名的模型好不好，这些记录什么也说明不了。
\n重新执行与抽样。核查方可以对每个请求或抽取的样本重复全部或部分计算，再比较结果。在 TOPLOC 中，服务商对模型中间激活值的紧凑哈希作出承诺；中间激活值是模型在各层内部计算出的数值。验证者重算这些哈希的速度快于原始生成。在作者的实验中，该方法检测出了模型、提示词和数值精度的改动，同时能容忍不同 GPU 之间的数值差异[5]。验证者必须持有所声明的模型。该方案也只覆盖它哈希过的内容。作者指出，如果服务商用更便宜的模型生成输出，再用所声明的模型计算用于哈希的激活值，该方案无法察觉[5]。
\n形式化证明。形式化验证力求在特定假设下，用数学证明表明某项技术声明为真[1]。“可保证安全的 AI”（guaranteed safe AI）框架提议把这一思路扩展到 AI 系统。在这一框架中，验证器组件将提供一份可审计的数学证明证书，表明系统相对于某个世界模型满足安全规约。世界模型是对系统如何影响外部世界的数学描述[7]。这份证书有多大用处，以它的规约和世界模型为限。
\n基于结构化访问的审计。关于开发者内部做法的声明，无法靠一次密码学核查来判定，因此审计方要凭借比公众更多的访问权限来审查这些声明。Casper 等人认为，黑盒访问（即向系统发出查询并观察其输出）不足以支撑严格的审计。他们还认为，访问权重以及代码等训练和部署信息，可以支持更深入的审查[8]。2026 年的一项提案把前沿 AI 审计定义为：第三方基于对非公开信息深入且安全的访问，严格核实开发者的安全与安保声明。该提案还描述了可信度逐级提高的四个 AI 保障等级[9]。拟议协议 Attestable Audits（基于远程证明的审计）在 TEE 中运行基准测试。这样做是为了让模型权重和测试数据保持机密，同时让用户能够验证与自己交互的是合规的模型[10]。审计把信任寄托于审计方的能力、独立性和访问权限。
\n验证结果只覆盖声明本身所陈述的内容，因此仍有三个缺口。
\n第一，远程证明表明加载了什么，却不能表明软件是安全的。例如，proof-of-guardrail 系统利用 TEE 远程证明，表明智能体的回复经过了某个特定的开源护栏。该系统的作者警告，开发者仍可能主动越狱这个护栏，也就是诱使它放行本应拦截的内容[11]。
\n第二，形式化证明的范围以其规约为限。如果规约或世界模型遗漏了某种危害，即使证明有效，它对这种危害也说明不了任何问题[7]。
\n第三，仍有一些参与方需要信任。IETF 的架构把没有任何证据描述的组件称为信任根，因此必须由背书为它们担保。就基于硬件的远程证明而言，验证方通常要信任芯片制造商及其硬件[3]。
\n借助模型签名，你可以在任何代码加载权重之前，核查磁盘上的文件是否正是某个已知发布者签署的文件。[1]这项检查的可靠程度取决于你拿来比对的签名者身份，而且它只覆盖已签名的文件。因此，下面每一步都给出一条命令，并说明它支持什么决定。本指南使用的工具是 model_signing，它是 model-signing 软件包的命令行工具，这个软件包来自 Sigstore 的 model-transparency 项目。[1, 2]截至 2026 年 10 月 20 日，Python 软件包索引（PyPI）上的当前版本是 1.1.1 版。[2]我们关于 1.0 版发布的简报介绍了背景。
当你收到一个已签名的模型，准备用它提供服务、对它做微调，或把它交给另一个系统时，就可以使用本指南。开源安全基金会（OpenSSF）的 AI/ML 工作组曾在 2025 年 4 月宣布 1.0 版发布。该工作组表示，每次使用模型时都应检查签名，包括选定模型用于部署时，以及模型成为另一个模型的输入时。[8]
\nmodel.sig。[1, 3]安装一个确切的版本，然后查看工具报告的版本号。
\npip install model-signing==1.1.1\nmodel_signing --version1.1.1 版有几个选项用下划线拼写，例如 --identity_provider。[3]一项尚未发布的改动把这些选项改为连字符写法，同时继续接受下划线写法。[7]因此，为后续版本编写的命令在 1.1.1 版上可能会失败。请以你所用版本对应标签下的 README 为准。[1]
使用 Sigstore 时，签名者用一张短期证书签名，这张证书对应签名者的 OIDC 身份。签名事件会记录在一份公开、只追加的透明日志中。[1, 9]身份和签发方是必填参数，如果二者与签名不符，验证就会失败。[3]
\nmodel_signing verify path/to/model \\\n --signature model.sig \\\n --identity "$EXPECTED_IDENTITY" \\\n --identity_provider "$EXPECTED_ISSUER"使用密钥签名时，请传入发布者的公钥；能把签名与发布者联系起来的只有这把公钥。[3]
\nmodel_signing verify key path/to/model \\\n --signature model.sig \\\n --public_key publisher.pub使用证书签名时，你必须自己确认签名者，因为命令会检查证书链，但没有参数可以指定预期的签名者名称。[3]如果不提供 --certificate_chain，命令会改用一组默认的根证书。[4]有些证书的扩展密钥用法字段不允许代码签名，1.1.1 版却会接受其中一部分，例如为 Web 服务器签发的证书。相应的修复尚未发布。[7]请传入发布者自己的证书链，并向发布者核实签名证书的 SHA-256 指纹，以此确认签名者；--log_fingerprints 会把这个指纹写入日志。[3]
model_signing verify certificate path/to/model \\\n --signature model.sig \\\n --certificate_chain publisher-chain.pem \\\n --log_fingerprints先看输出：命令成功时输出 Verification succeeded，失败时输出 Verification failed with error: 及失败原因，并以状态码 1 退出。[3]它会对目录计算哈希。如果某个已签名的文件发生改动或缺失，或者目录中多出了文件，验证就会失败，错误信息会指出是哪些文件。[4]
对于跳过的路径，验证通过说明不了任何情况；默认跳过的路径包括与 Git 有关的文件。[1]从 1.1.0 版起，签名还会记录发布者在签名时排除的路径，验证时会自动跳过这些路径。[7]另有两个选项会在此基础上扩大跳过的范围：--ignore-paths 跳过你指定的路径，--ignore_unsigned_files 则让多余的文件也能通过。[3, 7]只有对你的加载器从不读取的文件，才可以使用这两个选项。
不要开启 --allow_symlinks。开启后，如果某个符号链接指向目录，1.1.1 版会悄无声息地让这个符号链接之下的所有文件既不签名、也不检查。据变更日志，这一缺陷只在尚未发布的代码中得到修复。[7]
要查看签名覆盖了哪些内容，可以用 jq 工具解码其中经过签名的声明：[9]
\njq -r .dsseEnvelope.payload model.sig | base64 -d | jq .在输出中，predicate.resources 列出签名覆盖的每个文件，以及它的哈希算法和摘要（即哈希值）。predicate.serialization 字段记录哈希设置，包括签名时排除的路径。[6]如果 predicateType 为 https://model_signing/Digests/v0.1，说明这是 1.0 版之前的签名。工具可以验证这类签名，但不能创建；用变更日志的话说，它把 0.2 版的实验性行为“连 bug 一起”照搬了过来。[6, 7]
这一步只适用于 Sigstore 签名。这类签名记录在 Rekor 中，Rekor 是 Sigstore 的只追加透明日志。[1, 11]签名包中有一份收录证明，表明该条目在日志中；verify 命令已经检查过这份收录证明。[1, 9]签名包还包含该条目的日志索引和收录时间（integrated time），即该条目写入日志的时间。签名包中另有一个经过签名的时间戳，表明签名发生在短期证书的有效期内。因此，证书过期后，验证仍能成功。[9]
\njq '.verificationMaterial.tlogEntries[] | {logIndex, integratedTime}' model.sig\nrekor-cli get --rekor_server https://rekor.sigstore.dev --log-index <log-index>第二条命令用 Rekor 命令行客户端获取该条目。[10]它查询的服务器托管着 Rekor 的原始日志，这仍是 Sigstore 公共实例的默认日志。各生态系统可以选择改用第 2 版日志，这些日志位于其他地址。[11, 12]
\n保留足够的信息，让审计人员能够重复这项检查。
\n2026 年 5 月，七国集团（G7）成员国的网络安全机构发布了面向 AI 的软件物料清单（SBOM）最低要素。它们把这种清单描述为 AI 系统组件的结构化记录。对于每个模型，清单应给出权重或模型文件的哈希值以及所用的哈希算法，以便验证该组件的完整性。SBOM 本身应带有可归属于其作者的数字签名。[13]
\n经过验证的模型签名能提供这样的哈希值，而且它们出自已知的签名者。predicate.resources 中的每个条目都给出一个文件的算法和摘要。声明的主体（subject）则带有一个 SHA-256 摘要，它根据所有这些摘要计算得出。按照该项目的设计，其他元数据文档可以用这个摘要指代该模型。[6]请把这些值复制到该模型的 SBOM 条目中。如果你收到的 SBOM 对同一文件、同一算法给出了不同的摘要，它描述的就不是发布者签署的那个文件。模型签名把文件与发布者联系起来，SBOM 的签名则把组件清单与其作者联系起来。我们关于最低要素的简报列出了全部要素。
远程证明让一方在把数据或工作托付给另一台机器之前，先获得一份由硬件签名的证据，了解这台机器的软件状态[1, 2]。对 AI 工作负载而言，用户设备可能想在加密提示词之前，先知道哪些软件会接收它；模型所有者在交出用于解密权重的密钥之前，也可能需要同样的证据[1, 8]。这些证据来自可信执行环境（TEE）。TEE 是处理器中一种由硬件隔离的执行模式，它会记录自己加载的内容，并就此签署一份报告[2, 3]。一份有效的报告能让这一方知道机器加载了什么、运行在哪种硬件上。但它不能表明，所加载的软件会像运营方所说的那样运行。
\n互联网工程任务组（IETF）以 RFC 9334 的形式发布了 Remote ATtestation procedureS（RATS）架构。该架构定义的各个角色不依赖任何特定的处理器或协议[1]。表中第三列是我们给出的示例。
\n| 角色 | 职能 | AI 服务中的典型参与方 |
|---|---|---|
| 证明方 | 生成证据，即度量值、配置等声明 | 运行模型的机密虚拟机（VM）和图形处理器（GPU） |
| 验证方 | 对照参考值、背书和评估策略来评估证据，再生成证明结果 | 厂商提供的远程证明服务，或客户端中的程序库 |
| 依赖方 | 根据证明结果自行作出决定 | 用户的客户端，或保管模型密钥的密钥服务 |
| 背书方 | 为证明方的能力担保，例如为只保存在硬件中的签名密钥签发证书 | 芯片制造商 |
| 参考值提供方 | 提供与声明比对的预期值 | 软件发布方；固件方面则是硬件制造商 |
自行核查证据的客户端，既是验证方，也是依赖方[1]。
\n证据从度量值开始。度量值是代码和数据在加载时记录下来的密码学哈希值。在 RFC 9334 所说的分层远程证明（layered attestation）中，每个阶段都先度量下一个阶段，再启动它。任何阶段都不能改动关于自身加载过程的记录[1]。
\n机密虚拟机在启动时就采用这种做法。按设计，硬件会把它们的内存与宿主机隔离，也与虚拟机监控器（即管理虚拟机的软件）隔离。在 Intel Trust Domain Extensions（TDX）中，TDX 模块把虚拟机初始内存页的度量值记录在一个度量寄存器中。虚拟机内的软件之后加载代码和数据时，可以把它们的度量值扩展到运行时度量寄存器中[2]。在 AMD Secure Encrypted Virtualization with Secure Nested Paging（SEV-SNP）中，AMD Secure Processor 会度量虚拟机的初始内存页及其放置位置，形成一个启动摘要[3]。
\n接下来要为度量值签名。Intel 的设计把处理器生成的报告转换为 quote，并用证明密钥签名。这把密钥的证书链可以追溯到 Intel 的一个证书颁发机构，Intel 的目标是公布这条证书链上的证书和吊销列表[2]。AMD 的固件用版本化芯片背书密钥（Versioned Chip Endorsement Key，VCEK）为报告签名。每块芯片都有自己的 VCEK，它由芯片可信组件的版本号派生而来，因此有效的签名也能标明这些版本[3]。两种设计都允许虚拟机内的软件把自己的数据加入报告，例如它将用于通信的公钥，或该公钥的哈希值[2, 3]。
\n在发送任何敏感内容之前，验证方要逐项完成以下检查：
\n大模型运行在 GPU 上，推理期间模型和数据都存放在 GPU 中。因此，仅有中央处理器（CPU）的远程证明，对 GPU 什么也说明不了。NVIDIA 为 H100 GPU 提供的机密计算模式，与运行在 AMD SEV-SNP 或 Intel TDX 上的机密虚拟机协同工作[4]。传输的数据、命令缓冲区和 CUDA 内核在经过虚拟机与 GPU 之间的 PCI Express 总线之前都会加密。GPU 封装内的显存不加密。NVIDIA 称，这部分显存被认为能够抵御常见的物理攻击工具[4]。
\n虚拟机的信任边界圈定了它托付数据的那些组件。在把 GPU 纳入信任边界之前，虚拟机会对照 NVIDIA 的证书颁发机构，核查 GPU 身份密钥的证书，并确认证书未被吊销。这把身份密钥烧录在芯片的熔丝中。GPU 还会就自身的度量值生成一份签名的证明报告[4]。NVIDIA Remote Attestation Service（NRAS）或本地验证工具会把这些度量值与参考完整性清单（RIM）比对。RIM 是 NVIDIA 在构建驱动程序和 GPU 固件的过程中生成并签名的参考值[5, 6]。度量对象包括硬件配置、固件和驱动程序微码[6]。
\nCPU 的 TEE 和每块 GPU 都提供了证据，这台机器因此成为 RFC 9334 所说的复合设备（composite device）。每个组件生成自己的证据，再由一个主证明方（lead attester）汇总[1]。依赖方需要所有这些证据，而且要确认它们都与同一台机器绑定。
\n一份通过上述检查的报告表明：固件版本已知的真实硬件在受保护模式下加载了经过度量的软件，证据是新鲜的，而且与连接绑定。但仍有四个缺口。
\n软件行为和之后加载的输入不在报告范围内。度量值能够识别代码。但它不能表明代码执行了它的策略，也说明不了之后加载的输入。WhatsApp 审计发现，一些含有环境变量的配置文件在度量之后才加载。内部人员本可借此加载恶意代码，而远程证明依然能通过[7]。
\n度量值相符，只有在有人了解该构建版本的行为时才有用。Apple 承诺公开每一个生产环境的 PCC 镜像，让研究人员能够将其与日志中记录的度量值相对照[8]。Trail of Bits 指出，要让机密虚拟机镜像完全可复现，以便外部人员重新构建并检查，仍有难度[7]。
\n仍需信任硬件制造商。RFC 9334 把没有任何证据描述的组件称为信任根，因此必须由背书为它们担保[1]。威胁模型说明一项设计要防御什么、信任什么。例如，AMD 的 SEV-SNP 威胁模型就把芯片硬件及其安全处理器视为完全可信[3]。
\n物理攻击和侧信道往往不在防护范围内。AMD 把虚拟机运行期间针对内存总线的攻击列在防护范围之外。它还表示，硬件没有专门防范架构侧信道[3]。Intel 表示，TDX 并不能防范所有类型的硬件攻击[2]。2026 年 9 月，研究人员披露了 DDRop。这是一种内存总线插入器，即插在处理器与内存之间的设备。它的零件成本不到 200 美元。研究人员报告称，曾在 Intel TDX 上用它伪造证明报告中的度量值。Intel 和 AMD 告诉研究人员，针对主内存的物理攻击不在当前产品的防护范围之内[11]。
\n模型权重需要单独核查。启动度量值描述的是启动时内存中的内容。如果权重在启动后才加载，那么除非软件度量了这些权重，或在使用前验证了权重的签名，否则远程证明无法说明是哪个模型在提供服务。例如，软件可以把权重的度量值记入 TDX 的运行时度量寄存器[2]。Google 的 Confidential Space 会报告工作负载容器的镜像摘要[9]。这个摘要涵盖构建进镜像的权重，但不涵盖之后下载的权重。
\n远程证明也可以作为发放权重的前提条件。RFC 9334 描述了这样一种情形：模型所有者只把模型或解密模型的密钥交给通过远程证明的设备[1]。在 Anthropic 2025 年的设计构想中，权重保持加密，只有在密钥服务器核查远程证明之后，才会在一个小型可信加载程序中解密[10]。
\n可信计算基随推理软件栈一同扩大。机密虚拟机内的一切都属于工作负载的 TCB，因为 AMD 的威胁模型把虚拟机本身视为完全可信，并由它负责保护自身的接口[3]。使用 GPU 时，TCB 包括 NVIDIA 驱动程序[4]，以及操作系统和推理服务软件。Anthropic 的构想让可信部分保持精简。在其推理服务器中，只有一个小型加载程序能够访问解密后的数据。Anthropic 表示，其余部分可能频繁变动，但不会因此影响系统的安全性[10]。
\nRFC 9334 定义了完整的术语体系[1]；Trail of Bits 的审计则说明了一个实际部署的检查在哪些地方有所欠缺[7]。
三种主要方法中，没有一种能在核查托管模型的回答时，既做到成本低，又只需信任少数几方。零知识证明用密码学证据表明，回答是由一个事先固定的模型计算出来的，因此不必信任服务商的硬件。但本文考察的系统速度很慢，而且只在较小的模型上演示过。经过远程证明的安全飞地是由硬件隔离的执行环境，会报告自己加载了哪些软件。调优之后，它能以百分之几的开销运行大模型。代价是，依赖它的人必须信任芯片厂商、被度量的软件，以及核查度量值的一方。重新执行就是再运行一次模型，然后比较两次的回答。它的成本远低于生成零知识证明，但它的保证建立在容差、抽样或争议机制之上，也有赖于诚实的核查方。每一类方法回答的问题不同，付出的成本也不同。
\n可验证推理研究要核查的声明范围很窄：这个输出是用某个特定模型处理这个输入得到的。模型由其权重确定，运行时采用声明的设置，例如数值精度和解码方式[2, 9, 12]。服务商有偏离声明的动机：更小或精度更低的模型服务成本更低，而用户只能看到文本[9, 11]。机密性，即服务商能否读取提示词，是另一项独立的性质。
\n零知识机器学习（zkML）系统证明某个输出是用已承诺的权重计算出来的。权重事先由一个密码学指纹固定下来，这个指纹称为承诺，它不会泄露权重。验证方无须看到权重，就能核查证明[1]。2024 年，zkLLM 为 Llama 2 13B 的一次推理生成了证明：输入长 2,048 个词元（token），在一块 NVIDIA A100 GPU 上耗时 803 秒。验证这份 188 kB 的证明约需 4 秒[1]。2026 年的 DeepProve 论文报告了为回答中每个生成词元提供证明的速度：GPT-2 约为每分钟 174 个词元，Gemma 3 约为 86 个，采用分布式证明时最高可达 1,855 个[2]。
\n这样的证明表明，输出与某个承诺一致。只有当承诺与一个已知模型绑定时，这一点才有意义。在 zkLLM 的设定中，开发者公布一次承诺，之后针对它为每个回答生成证明[1]。
\n此外，被证明的计算是模型的整数版本。zkLLM 把计算映射到有限域（一种只含有限个数值的数系）中，DeepProve 则默认把权重和激活值（模型计算出的中间值）量化为 12 位[1, 3]。DeepProve 的证明还要求每个词元都是模型得分最高的预测，与贪心解码一样[3]。零知识性质让验证方看不到权重，但服务商仍然能看到提示词[1]。
\n可信执行环境（TEE）是由硬件隔离的执行环境，设计目标是让宿主机操作系统和虚拟机监控器无法接触其内存。虚拟机监控器是管理虚拟机的软件。机密虚拟机是作为 TEE 运行的虚拟机，可以基于 Intel Trust Domain Extensions（TDX），并搭配处于机密计算模式的 NVIDIA GPU。随后，远程证明会给出启动时所加载软件的度量值，也就是一个由硬件签名的密码学哈希[4]。Confidential.ai 的作者在一篇预印本中做了测试：在 NVIDIA B200 GPU 上，为一个 2290 亿参数的模型提供以生成为主的服务。使用调优后的软件栈时，他们测得吞吐量开销约为 1% 至 3%；换用现成的推理软件栈，吞吐量则下降 30% 至 40%[4]。
\n安全飞地的设计目标是不让运营方接触提示词和权重，远程证明则是关于加载了哪些软件的证据[4]。两者都不能说明软件正确计算了所宣称的模型，因此信任输出，就意味着信任被度量的推理软件栈。
\n按照互联网工程任务组（IETF）的远程证明架构，验证方把证据与参考值比对，例如已知良好的度量值[5]。这种比对只覆盖已度量、并且与当前会话绑定的内容。Trail of Bits 在 WhatsApp 基于 TEE 的 AI 处理功能上线前做过审计，发现了这两类缺口。度量之后才加载的配置可能让内部人员运行恶意代码，而远程证明照样通过。此外，证明报告缺少客户端提供的新鲜值，因此任何曾经攻破过一次安全飞地的人都能重放这些报告，把旧报告当作新报告出示。Meta 已修复这两个问题[6]。
\n审计人员的规则是，每个加载的输入要么经过度量，要么按恶意输入对待[6]。照此规则，启动后才加载的权重，只有经过已度量代码的检查（例如与公开的哈希值比对），才在覆盖范围之内。
\n物理接触也能让远程证明失效。2026 年 9 月，研究人员披露了 DDRop：这种装置的制作成本不到 200 美元，能悄无声息地丢弃服务器的内存写入。凭借一次短暂的现场接触和对宿主机软件的控制，研究人员让一台恶意的 Intel TDX 虚拟机以合法工作负载的度量值通过了远程证明。Intel 和 AMD 认为，针对服务器内存的物理攻击不在当前产品的防护范围之内[7]。
\n重新执行的核查方式是用同一输入再运行一次模型，然后比较结果，但 GPU 推理往往无法复现。Thinking Machines Lab 用一个 2350 亿参数的 Qwen3 模型，把同一个提示词运行了 1,000 次，温度设为 0；这一设置会去除选择词元时的随机性。这些运行得到了 80 种不同的补全结果。该实验室把差异追溯到 GPU 内核（执行模型运算的程序）的运算顺序。这一顺序随批大小（同时处理的请求数）变化，因而也随服务器负载变化[8]。
\nTOPLOC 的做法是容忍噪声。服务商对中间激活值的局部敏感哈希作出承诺，这类指纹的设计目的就是吸收微小的数值差异。持有权重的验证者对全部词元做一遍计算即可重算这些哈希，速度比生成更快。在作者的测试中，它识别出了所有改动过的模型、提示词和精度，没有出现误报。但如果服务商用更便宜的模型生成词元，再用所声称的模型计算哈希，TOPLOC 无法察觉。要发现这种情况，需要核查选出每个词元的采样步骤[9]。
\nVerde 则选择消除噪声。它的 RepOps 库固定了浮点运算的顺序。两家服务商结果不一致时，由仲裁方把争议缩小到单个算子，即计算中的一个步骤，只重算这一步。因此，只要至少有一家服务商诚实，客户端就能得到正确结果。作者报告，在 A100 GPU 上，与 PyTorch 相比，RepOps 在 10 亿参数和 80 亿参数 Llama 模型推理中的开销分别为 58% 和 98%。它目前只覆盖单 GPU 运行。每项任务都要运行两次，成本因此至少翻倍。作者认为这一开销仍不到一个数量级，密码学证明的开销则至少达到四个数量级[10]。
\nIMMACULATE 采用抽样核查。审计方发送看起来与普通流量无异的请求，然后要求服务商证明：它对这些请求给出的下一词元得分，与所声称的全精度模型的得分相差多少。作者报告的吞吐量开销不到 1%。他们的保证假定审计方诚实，而且服务商无法把审计请求单独挑出来。这一保证还假定服务商至少在 10% 的查询上作弊[11]。因此，它不涵盖偶发的作弊。此外，如果没有人执行核查，本文讨论的每种方案都会失效。
\n| 比较项 | 零知识证明 | 经远程证明的安全飞地 | 重新执行与抽样 |
|---|---|---|---|
| 核查通过表明 | 在被证明的计算下，输出由已承诺的权重得出 | 真实的硬件启动了与所报告度量值相符的软件 | 重新运行的结果或经审计的样本相符，完全一致或在容差之内 |
| 需要信任的对象 | 证明系统的假设；与模型架构相符的被证明计算；与已知模型绑定的承诺 | 芯片厂商；被度量的软件；参考值与验证方；物理安全 | 诚实且确实执行核查的核查方；复现方法或阈值 |
| 已报告的成本 | 13B 模型每个证明 803 秒[1]；每分钟 86 至 174 个词元，分布式证明最高 1,855 个[2] | 调优后吞吐量损失 1% 至 3%，现成软件栈损失 30% 至 40%[4] | 每次核查对全部词元计算一遍[9]；在 A100 GPU 上相对 PyTorch 的推理开销为 58% 至 98%，外加一次重复运行[10]；采用抽样时开销不到 1%[11] |
| 成熟度 | 研究系统；DeepProve 的代码标注为尚不能用于生产[3] | 商用硬件[4]；WhatsApp 的 AI 功能，上线前经过审计[6] | 研究协议；有一个部署据称已上线[12] |
| 典型失效方式 | 承诺未与实际提供服务的模型绑定；被证明的计算与实际运行的计算不同 | 未度量的输入；可重放的报告；能伪造远程证明的物理攻击 | 漏掉细微改动的阈值[9]；未经核查的词元采样；偶发作弊；核查方缺位 |
Eigen Labs 称 EigenAI 已于 2026 年 1 月上线。这一系统结合了其中两类方法：重新执行和经过远程证明的安全飞地。运营方执行逐位一致的确定性推理，随机种子作为输入固定下来。结果只要在争议窗口期内无人挑战，即获接受。一旦有人挑战，就由一个验证者委员会在经过远程证明的安全飞地中重新执行。结果不一致时，从运营方质押的资金（即它锁定的抵押品）中扣除罚金。Eigen Labs 报告延迟增加 1.8%。它要求运营方和验证者使用同一型号的 GPU，因为它跨架构测试的结果从未一致。确定性把核查简化为逐字节比对。该公司还称，请求只在验证期间、在安全飞地内部解密[12]。IMMACULATE 的原型同样在 Intel TDX 安全飞地中运行审计计算。这比 GPU 推理慢数百倍，因此原型依靠抽样，让成本保持在可以忽略的水平[11]。
\n每种组合都保留了各组成部分的假设。EigenAI 仍需要有挑战者在争议窗口期内采取行动。重新执行的请求，其隐私保护不会强于安全飞地硬件本身，面对 DDRop 这类物理攻击时也是如此[7, 12]。
\n\nApple、Meta 和 Google 如今会把部分 AI 请求交给特定的服务器处理。这些服务器在设计上连公司自己的员工也挡在门外，并通过远程证明报告自己加载了哪些软件[1, 6, 8]。Cohere 也通过旗下的 Model Vault 服务提供类似的安排[11]。从公开的设计看，外部人员能核查什么，与其说取决于硬件，不如说取决于建立在硬件之上的三项选择。这三项选择是：公开的软件版本日志、在用户设备上核查远程证明，以及向研究人员开放软件。各家服务商的选择不同，因此“可验证”在不同服务中意味着不同程度的外部核查。
\n每一项选择都填补了远程证明留下的一个缺口。可信执行环境（TEE）的设计目标是把软件与机器的运营方隔离开来。它的证明报告由芯片内的密钥签名，其中包含度量值，即已加载软件的密码学指纹[6, 7]。度量值能识别加载的是哪个构建版本，却不能说明这个版本如何处理请求[6, 11]。公开日志让设备能够确认该版本已列入外界可以查看的记录。由设备自己核查远程证明，服务商就不能单方面宣称其服务器已通过检验。向研究人员开放软件，则让外部人员能够检查这个版本做了什么。
\nApple 的 Private Cloud Compute（PCC）于 2024 年 6 月公布，三项选择全部采用。只有当服务器节点在远程证明中报告的度量值，与一份公开、只追加的透明日志中的某个版本相符时，用户设备才会把请求加密发送给该节点。Apple 还承诺，每个生产镜像（即服务器节点启动的软件）会在记入日志后 90 天内发布[1]。2024 年 10 月，Apple 推出虚拟研究环境（Virtual Research Environment，VRE），同时以有限使用许可公开了部分组件的源代码。借助 VRE，任何人只要有一台符合要求、搭载 Apple 芯片的 Mac，就能下载已记入日志的版本，并在虚拟机中启动。因此，设备核查过哪份软件的度量值，研究人员就能运行这份软件略经修改的副本[2]。
\nApple 在 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]。
\nMeta 于 2025 年为 WhatsApp 推出的 Private Processing 同样把核查放在设备上。应用在发送请求前，会与一台机密虚拟机（CVM）建立会话；CVM 是作为 TEE 运行的虚拟机。会话采用结合远程证明的传输层安全（RA-TLS），把加密连接与 CVM 的远程证明绑定在一起。应用还会将 CVM 的度量值与第三方账本交叉核对[5]。Meta 在 2026 年 9 月介绍面向 AI 眼镜的方案时称，该账本只追加、接受公开见证。介绍中还说，度量值是公开的，二进制文件则在签署协议后提供给参与 Meta 安全计划的研究人员。Meta 表示，部署的代码一旦与公开记录不符，客户端设备和外部监测方都能发现，并称这一性质为篡改可检测性（tamper-evidence）。但要确认已记录的镜像究竟做了什么，则需要二进制文件[6]。
\nTrail of Bits 在这套 WhatsApp 系统上线前做过审计，结果说明了这种访问权限为何重要。审计共报告 28 个问题，其中 8 个为高危[7]。有一个问题是，配置文件在度量完成之后才加载，内部人员本可借此注入代码，而远程证明依然能通过验证。还有一个问题是，向操作系统描述硬件的数据表没有纳入度量。由于这两类输入都在度量范围之外，篡改它们不会改变度量值，因此账本核对也照样会通过。Meta 已修复这两个问题。Trail of Bits 还指出，外部验证需要研究人员复现并检查 CVM 镜像，而要做到完全可复现仍有难度[7]。
\nGoogle 的 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]。
\nNCC 写道，只有 Google 以及获得其内部访问权限的外部审计方，才能验证组件是否已被攻破。NCC 还认为，Google 作为一个整体仍有能力泄露用户数据，尽管任何单个内部人员都做不到[9]。
\nGoogle 在 2026 年 9 月的更新中把一部分证据移到了公司外部。新推出的记忆存储按用户划分并经过加密，运行在开源的服务端程序和运行时之上。Google 通过两种方式，把公开的源代码与实际部署的安全飞地对应起来。一是可复现构建：任何人重新构建源代码，都能得到相同的二进制文件。二是一份只追加账本，记录经过背书的二进制文件摘要（即哈希值）[8]。在设备端，一个开源 Android 库会先验证记忆存储所在安全飞地的远程证明，再发送用户的密钥[10]。对于系统的其余部分，Google 公布了关键组件的摘要，并把两项内容列为后续工作：在设备端校验证明证据，以及由独立第三方共同签名的日志[8]。Trail of Bits 指出，Google 可以不经事先的外部审查就修改系统，而且系统包含大量闭源代码[10]。
\n在基于 Intel TDX 的部署中，Cohere 的 Model Vault Encrypted 依靠 Intel Trust Authority，这是 Intel 运营的远程证明服务。该服务对照 Cohere 登记的策略，核查每台 CVM 的 CPU 和 GPU 证据；策略中列明了预期的度量值。Cohere 的客户端代理会先验证 Intel 签名的令牌，再发送请求。Cohere 称，其 vault 镜像和工作负载均为开源，并采用可复现构建[11]。最终核查由客户自己的客户端完成。Intel 本身也是 CPU 的制造商，同时作为验证方处在客户与 Cohere 之间。
\n| 设计 | 软件记录 | 由谁核查远程证明 | 外部检查 |
|---|---|---|---|
| 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]。
\nApple、Meta 和 Google 面对这一依赖的方式各不相同。Apple 增设了一份硬件账本和第二个独立的信任根[3]。Trail of Bits 发现，由于 SEV-SNP 不能完全防御高级物理攻击，Meta 需要额外的控制措施，限定哪些 CPU 可以信任[7]。NCC 指出，就 Google 的 TPU 而言，必须信任的硬件制造商就是 Google 自己[9]。
\n第二项是度量值没有覆盖的内容。除了 WhatsApp 的审计发现，Apple 的发布说明也披露：在后来的一个版本之前，系统读取某个配置值时并未经过远程证明。这个配置值决定某些智能体工具是否隔离运行[4]。NCC 发现，尚不清楚部分 Google 二进制文件是否依赖透明日志未追踪的配置包[9]。日志过滤器和出站规则（管控外发网络流量的规则）决定哪些内容会离开受保护的机器[1, 5, 8]。外部人员只能在看得到代码的范围内核查它们，而 Apple 公开了其过滤器的代码[2]。Trail of Bits 还发现，Google 为了检查响应是否复述受版权保护的内容，会把响应片段的截断哈希发送到可信边界之外。这个问题尚未解决，Trail of Bits 将其评为高危，但认为难以利用[10]。
\n第三项是记录本身。Apple 可以把已记入日志的构建版本推迟至多 90 天再发布，因此一个版本可能在外界能够下载之前就已开始处理请求[1]。验证代码同样需要审查。Trail of Bits 在 Google 的远程证明核查和账本核查中发现两个缺陷（现已修复）。这些缺陷本可让两名或更多未经授权的内部人员联手部署经过修改的服务，而账本上不会出现公开可见的条目[10]。
\n第一个问题是，已承诺的核查能否兑现，例如 Apple 针对 Google Cloud 上 PCC 的研究计划，以及 Google 的设备端验证[4, 8]。
\n第二个问题是谁来监看日志。一个有害的构建版本即使按规定记入了日志，也只有监看日志、并且能检查该版本的人才能发现。对于 Meta 的二进制文件和 Google 的闭源代码，这种检查需要服务商授予访问权限[6, 10]。
\n第三个问题涉及存储的状态。Google 的记忆存储、Meta 为眼镜提供的加密存储，以及 Apple 在多轮对话之间复用加密的模型中间状态，都让用户数据保留到单次请求之后[4, 6, 8]。远程证明在设备连接时核查，描述的是服务器加载了什么软件。至于外界应当如何核查已存储的数据此后经历了什么，目前还没有定论。
\n\n证明报告是一份证据：在任何数据离开你的系统之前，你都必须对照自己的要求核查它。在远程证明中，一台机器就自身的软件和配置生成经硬件签名的证据，供远程的一方决定是否信任它。厂商工具可以确认报告是真实的、平台固件是最新的。但评判报告所记录的软件，仍是你自己的任务。例如，Intel 为 Trust Domain Extensions（TDX）提供的验证库，把一件事留给了验证方：比对 quote（Intel 对其签名报告的称呼）中的度量值与预期值。[5]下面的九项检查以 Intel TDX 和 AMD Secure Encrypted Virtualization-Secure Nested Paging（SEV-SNP）的字段名为例。
\n如果一项服务提供证明证据，而你要决定是否向它发送提示词、文档或模型权重，就可以使用本指南。这类服务运行在可信执行环境（TEE）中，按设计由硬件把工作负载与宿主机隔离。本指南中的工作负载是一整台虚拟机（VM）。例如，AMD SEV-SNP 会用每台虚拟机专属的密钥加密其内存。[3]每当服务发布新软件，或厂商提高最低固件版本要求，都要重新做这些检查。
\nRFC 9334 是互联网工程任务组（IETF）制定的远程证明架构。按照它的术语，这项服务是证明方（attester）。验证方（verifier）对照参考值评估它的证据。你是依赖方（relying party），按自己的策略评判验证方给出的结果。[1]
\n先确定每个证明方及其采用的 TEE 技术，因为每种技术都有自己的证据格式和验证工具。[2, 5] AI 服务还可能附上来自图形处理器（GPU）的证据。NVIDIA 的验证工具把 GPU 证据与签名清单中的参考度量值比对，另有一项在线证书状态协议（OCSP）服务检查证书是否已被吊销。[6]
\n检查报告的签名能否沿证书链追溯到厂商掌控的密钥。做不到这一点，报告就不能算作证据。SEV-SNP 报告的 SIGNING_KEY 字段标明签署该报告的密钥，例如芯片自身的版本化芯片背书密钥（Versioned Chip Endorsement Key，VCEK）。[2] AMD 的密钥分发系统（KDS）提供 VCEK 证书以及签发这些证书的证书链：AMD 根密钥（ARK）签发 AMD SEV 密钥（ASK），ASK 再签发 VCEK 证书。[3]对于 TDX，Intel 的验证库会检查预配认证密钥（Provisioning Certification Key，PCK）的证书链和 quote 的签名。[5]
\n检查可信计算基（TCB）的版本。TCB 指保护机制所依赖的全部组件。AMD 把 TCB 版本定义为 SNP 固件、处理器微码等组件版本的组合。AMD 修复漏洞时，会提高最低补丁级别。每个 VCEK 都专属于某颗芯片，而且只对应它运行的某个特定 TCB 版本。[3]报告的 REPORTED_TCB 字段标明派生签名密钥时所依据的版本。[2] AMD 的指南会把这些值与 VCEK 证书中的值比对。[4]
\nTrail of Bits 发现，WhatsApp 的 Private Processing 系统起初信任固件自称的补丁级别。Meta 的修复改为从 VCEK 证书中读取补丁级别，并强制执行最低要求。[7]
\n对于 TDX，Intel 的验证库会返回 OK、OUT_OF_DATE 或 REVOKED 等验证结果。Intel 还介绍了在宽限期内接受过时平台的策略。[5]
\n把度量值与公布的参考值比对。度量值是代码或数据加载时记录下来的密码学哈希值。SEV-SNP 的 MEASUREMENT 是一个哈希值：虚拟机启动时，虚拟机监控器（管理虚拟机的软件）向虚拟机内存载入数据，固件在此过程中计算出这个值。[2] TDX 把受保护的虚拟机称为信任域（trust domain）。MRTD 涵盖信任域的初始内容。按照惯例，RTMR0 至 RTMR3 这四个运行时度量寄存器，存放虚拟固件、操作系统和运行时随后记录的度量值。[5]
\n参考值把每个哈希值对应到一个具体版本，你或他人可以检查这个版本。在 Apple 的 Private Cloud Compute 设计中，设备只为特定节点加密请求：这些节点经远程证明的度量值，必须与一份公开、只追加的透明日志中的某个版本相符。[8]
\n发送一个随机数（nonce），即只使用一次、无法预测的值，并确认签名报告中包含它。上周生成的有效报告，说明不了这台机器今天的状态。按照 RFC 9334 中的随机数方法，负责评估的一方发出随机数，证明方把它写入签名证据。如果证据中的随机数与发出的一致，就说明这些声明是在随机数生成之后签署的。[1]
\n两种技术都提供一个 64 字节的字段来存放这类数据。在 SEV-SNP 中，这个字段是 REPORT_DATA，固件不解析其内容。[2]在 TDX 中则是 REPORTDATA，Intel 建议可以用它存放验证方的随机数。[5] WhatsApp 的报告起初不含任何由客户端提供的值。因此，攻击者若攻破过某个 TEE 一次，本可以无限期地重放它的远程证明。[7]
\n确认报告与你即将使用的连接绑定。新鲜性表明报告是最近生成的。绑定则表明，你的连接终止于经过远程证明的环境之内。Intel 指出，报告数据可以携带一把在信任域内部生成的公钥，用于建立安全会话。[5] Meta 为 WhatsApp 做的修复，把传输层安全（TLS）握手中的 client_random 值写入每份报告，使每份报告都绑定到一个连接。[7]还要问清楚 GPU 证据如何与你的会话绑定。没有这层绑定，GPU 证据可能来自另一台机器。
\n即使报告真实、新鲜，也要检查调试标志和策略标志，因为它描述的仍可能是宿主机能够查看的环境。SEV-SNP 的 POLICY 字段包含一个 DEBUG 位。该字段还有一项设置，规定能否为这台虚拟机关联迁移代理（migration agent，即协助把虚拟机迁移到另一台机器上的软件）。[2]在 TDX 中，设置 TDATTRIBUTES 里的 DEBUG 位后，宿主机就能访问信任域的处理器状态和私有内存。Intel 建议，不要把生产环境的机密交给设置了任何调试标志的信任域。[5]
\n列出服务在启动后读取的输入。除非经过度量的代码记录了这些输入，或者把它们与预期值比对过，否则它们始终未经验证。Trail of Bits 在 WhatsApp 的系统中发现了两处这样的缺口。第一，环境变量来自度量完成后才读取的配置文件。内部人员本可借此加载恶意代码，而证明报告不会有任何变化。第二，高级配置与电源接口（ACPI）表负责向操作系统描述硬件，却没有纳入度量。恶意的虚拟机监控器本可借此声明能访问受保护内存的虚假设备。[7]对于 AI 服务，要询问模型权重、适配器、系统提示词和服务配置。
\n保留记录，让你自己或审计人员日后能够还原当时的决定。这是因为证明结果反映的是它生成时有效的策略、背书（通常由厂商就硬件签署的声明）和参考值。[1]
\n服务商说自己的模型输出可以验证，这一说法有多大用处，取决于它背后的具体声明。原因在于，归在可验证推理名下的各种机制，核查的对象各不相同。零知识证明除了所确立的命题之外，不泄露任何信息。它可以表明，某个输出与服务商已承诺的权重一致。[1]抽样审计只核查部分请求，其设计目标是以高概率发现大规模作弊。[6]这份核查清单把笼统的声明拆解为十个问题，每个问题都附有核查表。
\n如果你准备依据服务商或协议“输出可验证”的声明行事，应先使用这份清单。例如，你可能要依据这类声明为某个特定模型付费，或让智能体根据这些输出采取行动。需要准备的材料有：书面声明及其所依据的论文或规范、验证工具，以及你自己的要求，其中要包括单个错误输出会让你付出多大代价。
\n把声明完整地写下来，写明模型、输入、输出、解码设置以及运行发生的时间。解码设置决定模型如何选出每个词元（token）。每种机制只覆盖上述要素中的一部分。zkLLM 的零知识证明表明，对于给定的提示词和服务商已承诺的保密模型，返回的结果是正确的。[1] Gong、Liu 和 Li 认为，这类证明并不约束实际投入的计算量。在他们提出的 Hollow-LLM 攻击中，服务商保留所声明的架构和参数量，使用的权重却把计算量降到一个小得多的模型的水平。这些证明依然能通过验证。[3] TOPLOC 核查的是模型内部激活值的哈希。其作者指出，它无法发现推测解码（speculative decoding），即由一个更便宜的模型生成词元的做法。不过在作者的测试中，模型、提示词或数值精度的每一次改动，它都识别了出来。[4]
\n写明声明所依赖的机制。每类机制依据的证据和假设各不相同。
\n| 机制 | 示例 | 核查通过表明 | 主要假设 |
|---|---|---|---|
| 零知识证明 | zkLLM、DeepProve[1, 2] | 输出与公开架构在已承诺权重上的运行结果相符[3] | 承诺对应的正是预期的那组权重 |
| 硬件远程证明 | 在可信执行环境（TEE）中提供推理服务[7, 9] | 真实的硬件加载了哪些软件 | 硬件厂商和经过度量的软件 |
| 激活指纹 | TOPLOC[4] | 重算的激活值与服务商提供的哈希在设定阈值内相符 | 有能力重新运行模型的验证者 |
| 仲裁式委托 | Verde[5] | 结果正确，前提是至少有一家服务商诚实 | 模型算子在不同硬件上给出逐位相同的结果 |
| 乐观重新执行 | EigenAI[8] | 争议窗口期内无人挑战，或重新执行的结果一致 | 有人发起挑战；验证者使用相同的硬件 |
| 抽样审计 | IMMACULATE[6] | 受审计的请求与所声称的模型一致 | 审计请求与普通请求无法区分 |
查明验证程序需要哪些数据和硬件，因为这决定了你或你信任的人能否运行它。零知识证明原则上可以公开验证。[3] DeepProve 报告的验证时间为 1 至 3.7 秒。[2] TOPLOC 的验证者要在已生成的词元上重新运行模型，以重算激活值。[4]因此，它需要模型权重和合适的硬件。EigenAI 要求验证者与运营方（即运行推理的一方）使用相同型号的图形处理器（GPU），因为 A100 和 H100 GPU 执行相同的运算会得出不同的结果。[8]
\n逐一列出这样的参与方或组件：其中任何一个出问题，错误的输出就能通过核查。每种机制都至少依赖一个，上表最后一列列出了最主要的那个。外部测试也无法消除这种依赖。Cai 等人的结论是，不经服务商配合的测试无法可靠地发现模型替换。针对文本输出的统计检验需要大量查询，而且会漏掉细微的替换；针对对数概率的检验则会失效，因为生产环境中的推理是非确定性的。[7] Cai 等人转而提议使用 TEE。TEE 把信任转移到硬件厂商和经过度量的软件上。我们的远程证明报告解读指南介绍了这些检查。
\n查明方案核查的是每个输出、抽取的一部分输出，还是只有存在争议的结果。IMMACULATE 的审计方会发送少量随机请求，这些请求看起来与普通流量无异。审计方随后要求服务商证明自己是如何响应这些请求的。作者的推理是，服务商只有在不可忽略的一部分请求上偏离声明，作弊才划算。他们据此认为，这种抽样能以压倒性概率发现大规模偏离。[6]在 EigenAI 的乐观设计中，结果只要在争议窗口期内无人挑战，就维持有效。[8]两种设计针对的都是系统性作弊。它们都不能保证你收到的某个具体输出经过了核查。
\n检查证据是否指向你的请求，这样它才无法挪用到别的请求上。证据还必须涵盖决定输出的每一项输入。EigenAI 把它的输出描述为模型、提示词、随机种子和解码设置的纯函数，即输出只取决于这四项输入。因此，这四项都必须记录下来，重新执行的结果才能一致。[8]会话绑定同样重要。在 WhatsApp 基于 TEE 的系统中，证明报告起初不含任何由客户端提供的值，因而本可能遭到重放。Meta 的修复把每份报告绑定到一个传输层安全（TLS）连接上。[9]如果智能体根据输出采取了行动，就把证据与该行动的记录保存在一起。这样就能把这一行动追溯到经过验证的结果。
\n检查模型承诺。模型承诺是公开发布的权重密码学指纹，后续的数学证明都以它为参照。在 zkLLM 中，服务商为一个模型生成承诺最多需要 20 分钟，公布的承诺约为 10 MB。[1]承诺固定了一组权重，却不说明这是哪一组权重。除非服务商把承诺与一个你能检查或评测的发布版本关联起来，否则数学证明只能表明输出与某组固定的权重一致。Hollow-LLM 的研究结果还表明，权重即使符合所声明的大型架构，实际完成的也可以只是一个小得多的模型的计算。[3]
\n查明核查失败会带来什么后果。没有明确的后果，发现错误也改变不了什么。在 EigenAI 中，重新执行时发现结果不一致会导致罚没，即从运营方的质押中扣除资金。[8]在 Verde 中，争议会缩小到模型计算中的单个算子。仲裁方重新执行这个算子，找出出错的服务商。[5]如果依靠密码学证明或远程证明，后果由你自己的客户端决定，因此要确认客户端会拒绝未通过核查的输出。
\n记录验证的成本，因为成本决定了服务商负担得起验证多少流量。zkLLM 报告，为一个 130 亿参数模型的一次推理生成零知识证明，用时不到 15 分钟。[1] DeepProve 报告，GPT-2 每分钟约可证明 174 个词元，Gemma 3 约为 86 个。[2] IMMACULATE 只对受审计的请求运行可验证计算，报告的吞吐量开销不到 1%。[6] EigenAI 报告，在其自身测试中开销低于 2%。[8] Verde 让每项任务至少在两家服务商上运行，因此总成本至少翻倍。此外，它的可复现算子相对 PyTorch 还有额外开销：作者报告，在 A100 GPU 上，10 亿参数 Llama 模型的推理开销为 58%，80 亿参数模型为 98%。[5]
\n寻找针对机制本身及其部署的外部审查。zkLLM 获 2024 年 ACM Conference on Computer and Communications Security（CCS）录用；DeepProve 的 ePrint 条目则标注为 CCS 2026 小修（minor revision）。[1, 2]学术分析还可能揭示一整类声明的缺口，Hollow-LLM 论文针对零知识推理提出的正是这样的论点。[3]具体部署也需要单独审查。Trail of Bits 在 WhatsApp 基于 TEE 的系统上线前做了审计，发现 28 个问题，其中 8 个被评为高危。[9]仅由服务商自己测量的数字，例如 EigenAI 的可复现性结果，在其他人复现之前都应视为声明。[8]
\n通过验证的内容凭证（Content Credentials）能说明，哪个证书持有者签署了关于某个文件的一组声明，以及这些声明覆盖文件的哪些字节。声明是否属实，仍要由依赖这些声明的人判断。[1]内容凭证是一种清单（manifest），规范由内容来源与真实性联盟（C2PA）制定。清单中关于资产的陈述称为断言（assertion）；这些断言列在一份声明（claim）中，由签名者签署。[1]如果你要依据凭证发布、引用或标注一张图片或一段视频，请先完成下面六项检查。
\n.c2pa 清单文件；c2patool 用 --external-manifest 读取这类文件。[2]重新编码或调整过尺寸的副本，无法与清单的硬绑定相符。硬绑定是根据原始资产的字节计算出的密码学哈希。[1]规范为清单定义了三种状态，每一种都以前一种为前提：[1]
\n| 状态 | 验证已确认的内容 |
|---|---|
| 格式正确（Well-formed） | 清单及其断言符合规范的要求 |
| 有效（Valid） | 签名验证通过；证书处于有效期内，且未被报告为已吊销 |
| 可信（Trusted） | 证书还能沿证书链追溯到信任锚，即验证器接受的 CA 证书；或者用户已把这张证书加入验证器的私有凭证库 |
只有哈希覆盖的字节也没有改变，资产才算有效。如果清单有效，你可以把其中的声明归属于声明生成器（claim generator），即 claim_generator_info 中列出的硬件或软件。[1]在 c2patool 中，--info 报告清单是否通过验证，不加选项的命令则输出清单数据。[2]
c2patool image.jpg --info\nc2patool image.jpg先找出签名者，即签名证书的持有者，由证书的主体（subject）标识。[1]在 C2PA 符合性计划（Conformance Program）中，签名者总是某个生成类产品的一个实例；生成类产品指生成资产并为其附上清单的系统。C2PA 信任列表上的 CA 只能向符合规范的产品颁发签名证书。[4]每张证书都写明产品名称，并记录一个保障等级（目前为 1 级或 2 级），反映该产品满足了哪些安全要求。[4]因此，如果凭证对照这份列表判定为可信，它指明的是一个产品，例如一款相机应用。
\n--certs 选项输出证书链，trust 子命令则对照 --trust_anchors 传入的列表检查证书链。[2]如果证书链追溯不到验证器接受的任何信任锚，验证器会报告 signingCredential.untrusted。[1]
c2patool image.jpg --certs\nc2patool image.jpg trust --trust_anchors='https://raw.githubusercontent.com/c2pa-org/conformance-public/refs/heads/main/trust-list/C2PA-TRUST-LIST.pem'符合性计划和符合规范的验证器都存在有据可查的缺陷。2026 年 4 月，马里兰大学巴尔的摩县分校（UMBC）研究人员牵头发表了一项安全分析，称该计划 0.1 版不经技术审查就认证产品。[6]自 2026 年 10 月 9 日起，0.2 版成为唯一接受申请的版本。它要求提交样本输出文件，每条记录还须经第二名审批人批准。[4] UMBC 牵头的作者团队还发现，Nikon 于 2025 年 11 月吊销一台相机的证书后，有两个符合规范的验证器没有报告这次吊销。[7]按照规范，在线验证器应当尝试检查吊销状态。[1]
\n先给验证器显示的内容分类，因为其中只有一部分归属于签名者。创建型断言（created assertion）归属于签名者。收集型断言（gathered assertion）来自工作流程的其他环节，例如有人手动输入的细节。这类断言作为声明的一部分一同签名，但不归属于签名者。[1]清单以外的元数据，例如可交换图像文件格式（EXIF）字段，即使在哈希覆盖范围内，也不归属于签名者。只有复制到创建型断言中的 c2pa.metadata 断言里，这些元数据才归属于签名者。[1]
操作断言（actions assertion）列明对资产做过哪些操作。新资产的第一个操作是 c2pa.created，并带有数字来源类型（digital source type），例如生成式 AI 模型的输出标为 trainedAlgorithmicMedia。经过编辑的资产，第一个操作是 c2pa.opened，并有一条成分断言（ingredient assertion）描述原始资产。[1]规范 2.4 版新增了 c2pa.ai-disclosure 断言，用于记录模型类型等细节。[1]除非 allActionsIncluded 为 true，否则可能还有其他操作没有记录在内。[1]
哈希匹配只能保护它覆盖的字节，因此要列出排除范围（exclusion range），即哈希没有覆盖的字节区间。其中一个排除范围存放清单；除此之外，规范只允许把排除范围用于资产元数据。声明生成器必须确保，攻击者无论在这些区间写入什么，都不能实质性地改变对资产的解读。[1]如果存放清单的区间里还有其他数据，验证器必须拒绝该清单。遇到额外的排除范围，验证器必须用信息类代码标出，例如 assertion.dataHash.additionalExclusionsPresent。[1]
UMBC 牵头的作者团队报告，一部 Pixel 10 Pro 把位置数据存放在一个排除范围内。他们还报告，自己改动了这些数据，一个符合规范的验证器却没有发现。[7]安全研究人员 David Buchanan 于 2026 年 10 月 2 日发布了一张图片，图片中只有一个排除范围，覆盖了整个文件。他说，图片的签名有效，却保护不了文件的任何部分，而且他能找到的验证工具都没有对这张图片发出提示。他还用 c2patool 的详细报告展示了这个排除范围。[2, 5]
\nc2patool image.jpg -d查找 TSA 时间戳，它是清单可信时间的唯一来源。TSA 在声明签名之上再加一层签名，表明该签名在时间戳载明的时间已经存在。声明生成器写入的时间，例如某个操作的 when 字段，都不可信。[1]验证器必须能把 TSA 的证书沿证书链追溯到自己的 TSA 信任锚，其中包括 C2PA 的 TSA 信任列表。如果做不到，验证器会报告 timeStamp.untrusted，并忽略这个时间戳。[1]
有了可信时间戳，验证器会按时间戳载明的时间判断证书是否有效。因此，即使证书后来过期或被吊销，凭证仍能通过验证。[1, 3]没有可信时间戳的话，即使文件没有改动，证书一过期，验证也会失败。[1, 7]
\n即使是可信时间戳，也只能说明签名的时间。Buchanan 称，彩票开奖之后，他把中奖号码编辑进了自己的图片。据他介绍，图片附带的可信时间戳比开奖早几个小时，却依然有效，因为签名没有覆盖图片的任何部分。[5] UMBC 牵头的作者团队补充说，签名数据中没有任何内容指向时间戳，因此时间戳可以被移除和替换，而不会被发现。[7]
\n不要把缺少清单当作关于文件来源的证据，因为元数据可能被有意或无意地删除。[9]通过软绑定可以追溯到清单。软绑定是一种标识符，要么根据内容计算得出（例如指纹），要么以不可见的数字水印形式嵌入内容。因此，即使副本的字节与原件不同，软绑定也能与之匹配。[1]
\n如果原始清单记录了软绑定，而清单的副本存放在某个清单存储库中，软绑定就能找到这份副本。随后，匹配方必须确认，找回的清单中每个软绑定都与检索时使用的软绑定相符。[1] CAI 还加上了一道指纹检查，确认内容与找回的清单相符。它指出，水印可能被去除或伪造，指纹匹配也从来不是确定无疑的。[9]
\n水印检测工具只能覆盖嵌入了其水印的生成工具。Google 于 2026 年 10 月 7 日向所有人开放 SynthID Detector。Google 称，这款工具可以检查图像、视频或音频文件是否由 Google 或其合作伙伴的 AI 制作，合作伙伴包括 OpenAI、NVIDIA 和 Kakao。[10]因此，未检出水印的结果说明不了其他生成工具的任何情况，我们关于这款检测工具的简报也指出了这一点。
\n2026 年 10 月 16 日，美国三家机构发布了十项自愿性关键实践，用于管理超级智能（SI）智能体在训练和评测期间发生的事件。发布方是美国国家标准与技术研究院（NIST）下属的 Center for Advancing Innovation and Standards for Super Intelligence（CAISSI）、美国国家安全局的 Super Intelligence Security Center（NSA SISC），以及美国网络安全和基础设施安全局（CISA）。[1, 2]NIST 的 CAISSI 网页上还列有 NIST 下属 Center for AI Standards and Innovation（CAISI）发布的成果。[4]
\n文件对 SI 智能体的定义是：与环境交互、为达成指定目标而自主执行行动的系统。文件称，这类系统通常是一个生成式模型，加上为它提供工具的脚手架软件。文件关注的是 SI 控制事件（SI control incident）。在这类事件中，智能体未经指示采取重大行动，破坏了运营方为界定任务或确保人类监督而设定的策略、控制措施或安全措施。如果行动源于对抗性提示注入，即攻击者把指令植入智能体的输入，则算作“受指示”的行动。如果模型被蓄意植入了后门，由此引发的行动也算作受指示。这些实践分为从准备到报告的五个阶段。[2]CISA 表示，这份文件尤其针对部署前、安全防护有所削减的智能体。[3]
\n其中几项实践涉及供事后审查的证据。实践 5.3 要求采用带可靠时间戳的防篡改日志，其详细程度应足以重建智能体的行动轨迹、工具调用、推理记录和安全控制决策。实践 3.3 指出，智能体应无法访问或干扰监控进程和日志。实践 5.1 要求各机构根据调查事件的需要，保存模型权重和运行环境。[2]
\n按照实践 2.4，各机构应与独立的外部审计方和评测方合作，核实控制和监控系统是否按预期运行。实践 10.2 则要求向第三方提供足以开展独立分析的访问权限。[2]实践 2.5 建议公布评测和智能体的标识，帮助防御方理解预料之外的流量。不过作者也指出，公布互联网协议（IP）地址段可能让部署方面临攻击。[2]
\n\nAnthropic 于 2026 年 10 月 15 日表示，已开始向 METR 的一个团队开放其所称的“类似员工的访问权限”。METR 是一家评测前沿 AI 模型的非营利机构。文章开头先提到，Anthropic 在 9 月承诺加强第三方评估，又提到公司签署了 White House Accord on Super Intelligence。签署企业在这份协议中承诺与独立审计方或评测方合作。[1]
\n据 Anthropic 介绍，六名 METR 员工配有公司硬件和办公空间，能访问的内部工具和系统与公司自己的风险评估团队大致相当。Anthropic 鼓励自己的员工像对待同事一样与他们分享信息。少数明确划定的类别除外，例如客户数据、律师与委托人之间受特权保护的材料，以及模型架构信息。[1]
\nAnthropic 称，METR 将发布自己的分析，内容涉及 Anthropic 的风险水平、事件或做法。公司表示自己无权否决发布，但可以要求删减预先划定类别的内容，例如重现机密知识产权的内容。哪些信息属于这些类别由 Anthropic 决定。不过，METR 保留权利，可以就自己获得的访问权限和信息作出某些陈述。该团队受可强制执行的协议约束，METR 的其他员工与该团队的工作相隔离。[1]
\n文章称，这是三个访问层级中的第三级。在第一级，评测方获得哪些访问权限由 Anthropic 决定，发布内容也须经其批准。在第二级，评测方获得更多信息。他们无须批准即可发布，还可以一并说明自己认为 Anthropic 要求的删减是否合理。[1]
\n在 Anthropic 的其他评测方中，SecureBio 正在审阅 Anthropic 8 月版 Risk Report 中关于化学和生物武器的章节。[1]10 月 20 日，METR 就该报告中关于未对齐（misalignment）的部分发布了评审。这份评审的作者在新安排出台前就已接受委托，并不具备新安排所述的访问权限。按照他们的委托条款，Anthropic 可以否决发布。METR 表示，评审未经任何删减。[2]
\n\n2026 年 10 月 14 日，新加坡资讯通信媒体发展局（IMDA）发布了《智能体系统安全与可靠性测试入门工具包》（Starter Kit for Testing Agentic Systems for Safety and Reliability）。同一天，AI Verify 基金会面向代他人测试 AI 系统的公司推出了认可计划。[1]IMDA 还成立了一个工作组，关注新加坡资讯通信与媒体行业面临的 AI 赋能网络威胁。[1]
\n工具包的出发点是：智能体在人类参与有限的情况下作用于所处环境，一旦出现故障，就可能造成实际影响。[2]它把测试分为四个步骤，从识别错误操作或未经授权的操作等风险，到持续监测和重新测试。[1]
\n由于智能体的行动跨越多个步骤，工具包建议除了测试最终输出，还要测试智能体的完整轨迹，包括推理过程和行动。[1, 2]工具包要求记录智能体的行动、工具调用和状态变化，以便重建并评估其行为。它还提出了工具使用准确率、交接准确率等智能体专用指标。[2]IMDA 称，工具包是在征询政府机构以及 20 多家部署方和测试方意见的基础上编写的。IMDA 还说，工具包将作为动态文件持续更新。[1]
\n申请基金会 AI 测试方认可计划（AI Tester Accreditation Programme）的公司，需要接受技术、运营和财务评估。首批五家获得认可的公司是 AIDX Tech、Knovel Engineering、PwC Singapore、Resaro 和 Vulcan。认可有效期为一年。[1]
\n根据基金会的计划页面，技术评估会对照若干指南检查公司声称提供的测试服务，其中包括 IMDA 早先发布的大语言模型应用测试入门工具包。页面称，认可表示一家公司已表明自己能够在特定且有书面记录的风险范围内评估 AI 系统。页面还说，认可并不是对 AI 系统完全安全或没有任何风险的保证或认证。[3]
\n\n2026 年 10 月 14 日，欧盟委员会在《欧盟官方公报》上刊登了 EN 18286:2026 标准的引用信息。该标准全称为 Artificial intelligence – Quality management system for EU AI Act regulatory purposes。这一引用信息载于实施决定 (EU) 2026/2274。委员会于 10 月 12 日通过该决定，决定自公布当日起生效。[1]欧洲标准化委员会（CEN）和欧洲电工标准化委员会（CENELEC）应欧盟委员会 2025 年提出的一项标准化请求起草了这项标准。它对应该请求中关于 AI 系统提供者质量管理体系的条目，其中包括上市后监测流程。[1]
\nCEN-CENELEC 于 10 月 15 日宣布该标准已获引用，并称 EN 18286 是首个支持欧盟《人工智能法》（AI Act）的协调标准。CEN-CENELEC 表示，该标准把第 17 条的质量管理要求转化为切实可行、可供审计的要求，适用于高风险 AI 系统的提供者。它还表示，标准获得引用后，提供者即可就该法的相应条款获得符合性推定。[2]实施决定写明：协调标准的引用信息在《欧盟官方公报》上公布后，符合该标准的系统自公布之日起即推定满足该标准所涵盖的要求。[1]
\n第 17 条要求高风险 AI 系统的提供者建立一套以文件形式记录的质量管理体系。体系必须涵盖的方面包括测试与验证程序、数据管理、风险管理、上市后监测以及严重事件报告。[3]第 17 条位于《人工智能法》高风险系统一章的第 3 节。根据 Digital Omnibus on AI，该章第 1 至 3 节对附件 III 所列系统自 2027 年 12 月 2 日起适用。对附件 I 涵盖的系统，这几节自 2028 年 8 月 2 日起适用。[3, 4]
\n\n机密 AI 公司 OPAQUE Systems 于 2026 年 10 月 13 日宣布，其团队将加入 Anthropic，继续 OPAQUE 的工作。OPAQUE 起步于加州大学伯克利分校 RISELab 的一个研究项目。[1]公司主页现在显示，OPAQUE Systems 正在逐步结束运营。[2]
\nOPAQUE 在公告中回顾了自己的发展历程：从机密 AI 走向它所说的“可验证 AI”。机密 AI 指在硬件强制实施的保护下，用敏感数据运行 AI 工作负载。按 OPAQUE 的说法，可验证 AI 则是为运行了什么、在哪里运行、遵循哪些策略提供密码学证据。OPAQUE 称，它通过 AgenTrust 和若干开源项目与更广泛的社区合作，为 AI 智能体和模型面临的信任与安全问题寻求开放的解决办法。[1]
\n据主页介绍，OPAQUE 的开源工作将在 AgenTrust 继续，Confidential MCP 和 TRACE 等项目仍按原有许可证提供。OPAQUE 创办的行业活动 Confidential Computing Summit 将在 Linux 基金会继续举办。[2, 3]
\nOPAQUE 的两个页面都没有披露这项安排的条款。据 The New Stack 10 月 15 日报道，Anthropic 向 The Information 表示，它正在获取 OPAQUE 的技术授权，并聘用其部分工程师。报道补充说，除此之外，Anthropic 没有公布更多信息。The New Stack 援引 The Information 称，加入的人员包括首席执行官 Aaron Fulkerson 和首席技术官 Rishabh Poddar，但并非 OPAQUE 的全部员工。该报道还称，两家公司都没有就 OPAQUE 开源项目的维护承诺发表声明。[3]
\nThe New Stack 引述了两位外部人士的看法。应用 AI 研究员 Arjun Jaggi 认为，前沿实验室的资源可以帮助加固这类工具，使其能够投入生产使用。0G Labs 首席执行官 Michael Heinrich 则提醒，生成验证证据的工具如果归属于一家本身正在接受核查的模型厂商，可能产生利益冲突。[3]
\n\nGoogle DeepMind 的 Pushmeet Kohli 发文称，Google 于 2026 年 10 月 7 日向所有人开放 SynthID Detector，该工具已在全球推出英文版。[1]SynthID 是 Google 的数字水印系统，用于给 AI 生成的媒体加上不可察觉的水印。Google 表示，这款检测工具可以核查图像、视频或音频文件是否由 Google 或其合作伙伴的 AI 制作。Google 列出的合作伙伴包括 OpenAI、NVIDIA 和 Kakao，Apple 也在名单上，标注为“即将推出”。[1]
\nGoogle 于 2025 年 5 月以验证门户的形式推出这款检测工具。它先向早期测试者开放，并为记者、媒体从业者和研究人员开设了候补名单。[2]
\n10 月的文章称，自 2023 年推出 SynthID 以来，Google 已为超过 1800 亿个图像和视频以及总时长 24 万年的音频添加了水印。文章还说，Google 搜索、Gemini 应用和 Chrome 内置的验证功能目前每天处理超过 100 万次请求。[1]
\n\n2026 年 10 月 7 日，英国 AI 安全研究所（AISI）发布了 Transect。这是一个开源 Python 包，用于分析长时程智能体评测的运行记录（transcript）。Transect 以运行记录分析库 Inspect Scout 为基础。Inspect Scout 的开发方 Meridian Labs 也支持了 Transect 的开发。[1, 2]运行记录包含智能体的消息、工具调用和工具响应。AISI 表示，随着智能体执行更长的任务并与其他智能体协作，这类记录可达数十亿个词元（token，即语言模型读写的文本片段）。AISI 说，这超出了人类专家能够完整审阅的范围。[1]
\n用户向 Transect 提供一份运行记录、任务背景，以及希望区分的活动类别，例如编程或数据分析。Transect 直接从运行记录中提取记载的事件，包括人类发出的消息和子智能体的启动。随后，它调用评判模型，即用户选定的语言模型，为一段段活动打上标签。它生成的报告把标签、词元用量和事件放在同一条时间线上，时间线以智能体轮次计。每个标签都链接到它所描述的运行记录片段。[1, 2]AISI 指出，子智能体的标签描述的是它们接到的任务，这可能与它们实际做的事情不同。[1]
\nTransect 会保存每个标签和每一次模型判断，因此审阅者重新打开一项分析时无需再次调用模型。如果一项分析使用了多个评判模型或重复判断，报告会标出它们的分歧所在。AISI 提醒，判断一致并不意味着标签正确。它还说，重新运行分析时，新的判断可能与之前不同。[1]
\n随附的论文以一项 AI 研发评测演示了这一工作流程，该评测产生了近 1300 万个词元。[2]代码以 MIT 许可证发布在 GitHub 上。[3]AISI 还以自己今年早些时候遭遇的一起安全事件为例：当时有智能体在评测中采取了未经批准的行动。AISI 表示，系统地审阅运行记录帮助查明了这些智能体做了什么。[1]
\n\n安全研究人员 David Buchanan 于 2026 年 10 月 2 日报告，签名者可以生成这样一种内容凭证（Content Credentials）：签名和可信时间戳都保持有效，却不覆盖文件的任何内容。[1]内容凭证是内容来源与真实性联盟（C2PA）制定的溯源格式。它为文件附加一份经过签名的记录，称为清单（manifest），对文件的来源作出声明。清单常常包含由独立时间戳机构签发的时间戳，用以表明签名在某一时刻已经存在。[1]
\n这种方法利用的是排除范围（exclusion range）：签名者可以把某些字节区间排除在签名所覆盖的密码学哈希之外。Buchanan 只设置了一个排除范围，覆盖整个文件，这样声明签名覆盖的就只是空字符串的哈希。他说，自己在签名之后修改了图片，签名和时间戳仍然有效。[1]他的示例是一张彩票照片。他说，照片上是 2026 年 8 月 28 日 EuroMillions 彩票开奖的中奖号码，附带的可信时间戳却比开奖早了几个小时。他还称，他能找到的 C2PA 验证工具都没有提示任何异常。[1]
\nC2PA 规范 2.4 版规定，创建清单的软件必须把排除范围限制在清单存储区或资产元数据之内。规范还要求，如果容纳清单的排除范围内含有其他数据，验证器应拒绝该清单；任何额外的排除范围，验证器都应以信息类代码报告。[2]
\nBuchanan 写道，覆盖整个文件的排除范围很容易发现，较小的排除范围则较难判断。他补充说，排除范围不能简单地取消，因为某些文件格式含有校验和，这些校验和在签名之后必须更新。因此，他建议针对每种格式规定哪些字节可以排除，并要求验证工具强制执行这些限制。[1]
\n马里兰大学巴尔的摩县分校（UMBC）、Hacker Factor 和美国国家安全局的研究人员在 4 月发表的一项分析中就已指出，排除范围可用来做出无法察觉的改动。[3]
\n\n美国乔治城大学安全与新兴技术中心（CSET）于 2026 年 9 月 29 日发布报告，评估了用位置验证来执行美国 AI 芯片出口管制的做法。作者 Jacob Feldgoise、Kyle Miller 和 Hanna Dohmen 从可验证性、准确性、安全性和可重复性几个方面比较了不同方法。他们的结论是，建立一个集中式的基于 ping 的位置验证（PLV）系统，再辅以实地检查来追查线索，将是最稳健、最可行的做法。至于决策者是否应强制推行位置验证，他们没有提出建议。[1, 2]美国众议院一个委员会通过的《芯片安全法案》（Chip Security Act）版本，把基于 ping 的位置验证列为一种可接受的机制。[3]
\n在 PLV 中，位于已知地点的可信地标服务器向芯片发送信号，并根据信号的往返时间估算芯片的位置。作者建议，每块芯片都在其可信执行环境（TEE）的固件中为响应签名。TEE 是处理器中一块隔离的区域。他们认为，这种做法在安全性、成本和实施难度之间取得了最佳平衡。他们给出的一个理由是，固件更新可以推送到已经投入使用、配备 TEE 的芯片上。他们补充说，任何一种实施方案都不太可能抵御有国家背景的攻击者。[1]
\n报告估计，如果地标服务器为自有，PLV 系统每年的成本为 310 万至 2880 万美元。如果租用服务器，估计成本为每年 260 万至 7240 万美元。在超过 1000 万个模拟情景中，按每美元查出的被转移芯片数量计算，实地检查从未胜过 PLV。即使作者特意选用了对实地检查有利的模型参数，结果也是如此。[1, 2]
\n作者还指出了 PLV 的固有局限。PLV 只能在事后发现转移。芯片停止响应，可能是处于存放状态，也可能是有人故意断开了连接。PLV 的精度很可能不会好于 20 英里左右，因此无法可靠地区分相距不远、由不同运营方管理的数据中心。由于 PLV 核实的是位置而不是使用者，它无法察觉芯片在同一数据中心内转给受限制公司的情况。[1]
\n\nMeta 于 2026 年 9 月 23 日表示，正将 Private Processing 扩展到旗下 AI 眼镜。Private Processing 是 Meta 于 2025 年为 WhatsApp 和 Meta AI 应用推出的机密计算基础设施。该平台在机密虚拟机（CVM）中运行 AI 模型，机密虚拟机的设计目标是让内存保持加密，并与宿主机隔离。Meta 称，平台的设计使得连它自己也无法访问用户数据。Meta 列举了该系统设计用来卸载的几类工作负载：流式转写、情境搜索和长期记忆。[1]
\n据 Meta 介绍，眼镜在发送任何上下文信息之前，会先验证服务器。设备通过结合远程证明的传输层安全（RA-TLS）会话，从服务器的可信执行环境（TEE）获取一份由硬件签名的证书。设备会检查签名能否沿证书链追溯到芯片厂商公布的根密钥。它还会检查所度量的软件镜像是否与一个只追加账本中的某个条目相符，该账本由独立第三方见证。任何一项检查不通过，设备都不会连接。为避免请求与账户关联，Meta 称设备使用匿名凭证，并通过 Fastly 或 Cloudflare 运营的第三方不经意 HTTP（OHTTP）中继访问 Meta 的网关。[1]
\n在记忆功能方面，Meta 称已在 TEE 内部构建存储引擎，并用用户提供的密钥加密存储的数据。Meta 称，公开账本使针对部署的篡改能够被发现。它还表示，其安全计划中的研究人员依协议可以访问二进制文件，借此确认账本记录的镜像按描述的方式运行。Meta 也正在把漏洞赏金计划扩展到眼镜上的 Private Processing，并计划向研究人员提供工具、CVM 二进制文件和文档。[1]
\nTrail of Bits 曾在上线前审计过 WhatsApp 版本。该公司在 2026 年 4 月发文称，审计共发现 28 个问题，其中 8 个为高危，包括证明报告缺乏新鲜性保证。它还称，Meta 通过加入 TLS 随机数（nonce）修复了这一问题。[2]我们在另一篇简报中报道了这次审计。
\n\nGoogle 于 2026 年 9 月 23 日表示，将为 Private AI Compute 增加一个持久的、按用户划分的记忆层，而此前它在每项任务结束时都会清除上下文。Private AI Compute 是 Google 在硬件隔离的云端环境中处理 AI 请求的平台。Google 称，解锁记忆的密钥将只保存在用户设备上。公司还称，处理请求时，会由安全飞地临时解密记忆。安全飞地就是上述硬件隔离环境的一种。[1]
\n根据更新后的技术简报，记忆存储是一个按用户划分的数据库，位于可信执行环境（TEE）之内。简报称，只有当飞地的远程证明与经过背书的记忆二进制文件相符时，密钥才会释放给该飞地。远程证明是一份签名记录，载明飞地加载了哪些软件。Google 称，记忆服务器及其运行时都已开源。公司还称，这些代码通过可复现构建和一份只追加账本，与已部署的二进制文件对应起来，账本中记录着二进制文件的摘要。由于每个请求都必须送达特定用户的存储，简报称记忆系统并不宣称具备网络层面的不可定向性，即请求无法与用户关联的性质。[2]
\nGoogle 的博客文章称，设备将能够在发送个人数据之前验证其服务器软件。[1]简报把设备端对证明证据的验证列为未来工作，由独立第三方联合签署的账本也是如此。简报没有给出时间表。[2]
\n简报链接了 Trail of Bits 一份日期为 2026 年 9 月 21 日的评估报告。报告列出 10 项发现，Google 解决了其中 8 项，另外 2 项仍未解决。未解决的发现中，评为高危的一项是：模型回复文本的哈希值会发往可信计算基（TCB）之外。可信计算基指系统安全所依赖的那些组件。发出这些哈希值，是为了检查回复是否复述了受版权保护的内容。Google 计划在飞地内加入过滤器，使大部分哈希值不会离开飞地。Trail of Bits 称，这能降低风险，但不能消除风险。另一项未解决的发现评为低危：已删除的记忆可能恢复到活动数据库中。Google 接受了这一风险。Trail of Bits 还指出，Google 可以在没有事先外部审查的情况下更改系统，而且系统包含大量闭源代码。[3]
\n\n2026 年 9 月 16 日，Cohere 在 X 上发帖，宣布在 Model Vault 中引入机密计算。Cohere 称，包括它自己在内的任何人都无法访问客户的工作负载。[1]Model Vault 为客户提供专用的单租户模型部署。Cohere 的文档把这一新选项称为 Model Vault Encrypted，并说明它目前以测试版形式向联系该公司的客户提供。[3]
\n根据文档，推理在基于硬件的机密虚拟机（VM）中运行，并搭配处于机密计算模式的 NVIDIA GPU。在机密虚拟机中，硬件会加密虚拟机的内存，并按设计将其与宿主机隔离。在文档举的例子中，虚拟机采用 Intel Trust Domain Extensions（TDX）或 AMD Secure Encrypted Virtualization-Secure Nested Paging（SEV-SNP）。[3]客户端使用不经意 HTTP（OHTTP）加密请求，加密所用的密钥在经过远程证明的环境内生成，因此负载均衡器和网络传输的只有密文。[2]
\n文档描述了一种基于 Intel TDX 的部署。在这种部署中，Intel 的远程证明服务 Intel Trust Authority 依据已批准的策略评估来自 CPU 和 GPU 的证据，并签发一个签名令牌。在发送任何数据之前，Cohere 的客户端代理会验证 Intel 的签名，以及令牌所报告的度量值（即所加载代码和配置的哈希值）。它还会检查加密密钥是否与经过远程证明的环境绑定；只要有一项检查未通过，就会拒绝连接。[2]
\n每个推理响应还附带一份远程证明证书，客户可以保存下来，作为处理该请求的环境的记录。Cohere 称，已批准的度量值来自开源代码的可复现构建，因此独立第三方可以重新构建这些制品并加以比对。[2, 3]
\n文档的常见问题（FAQ）页面还列出了哪些信息在受保护环境之外仍然可见：模型名称等路由元数据、运行指标，以及网络时序和传输字节量。它指出的残余风险包括硬件侧信道（通过耗时等效应间接泄露信息）、需要深度物理接触的攻击，以及运营方停止或重启该环境的能力。[3]
\n\n