An AI system is verifiable to the extent that someone other than its developer can check a specific claim about it against evidence. The claim is a precise statement about a particular system, such as which model answered a request or which software handled it. The evidence is something other than the developer's word, such as a signature, a hardware-signed report or a mathematical proof. The verifier is whoever examines the evidence and decides whether the claim holds. Every check rests on trust assumptions: the components or parties that the check does not examine, such as a chip maker's signing keys.
\nThis definition builds on a 2020 report by Brundage and colleagues. The report defines verifiable claims as falsifiable statements for which evidence and arguments can bear on how likely they are to be true.[1] Verifiability is therefore a matter of degree. A claim can also be checkable for one party and opaque to another.
\nWhen the party making a claim is the only source of information about it, its statement cannot settle whether the claim holds. This matters because cloud AI services process personal data, and users of AI agents rely on developers' accounts of how safety measures are enforced.[2, 11] Apple makes the same point in its 2024 description of Private Cloud Compute (PCC), the cloud system behind its more demanding AI features. When a cloud AI service says it does not log certain user data, Apple notes, researchers generally have no way to verify the promise.[2]
\nPCC's design also narrows that gap. Apple says PCC deletes a user's data after fulfilling a request and that \"no user data is retained in any form\" once the response is returned.[2] Users cannot watch that deletion, so the design adds narrower claims that a device can check. In Apple's design, a user's device sends data only to PCC nodes that can cryptographically attest to running publicly listed software. Apple also committed to publishing the measurements (cryptographic hashes) of that software in an append-only transparency log, together with production software images for researchers.[2] The device can confirm which software it is talking to. But whether that software retains no data is left to researchers who analyze the images.
\nThis site sorts claims into a verification stack. Lower layers support higher ones: knowing which model answered depends on knowing which software and hardware ran it.
\n| Layer | Typical claim | Example of evidence |
|---|---|---|
| Hardware and compute | The computation ran on genuine hardware in a protected mode. | A hardware-signed attestation report[3] |
| Software and runtime | This exact code and configuration handled the request. | Measurements compared with published values[2, 3] |
| Models and data | These are the released weights, unchanged since they were signed. | A signed manifest of the model's file hashes[6] |
| Outputs and content | This output came from this model and this input. | A proof of inference or a re-execution check[4, 5] |
| Agents and actions | The stated guardrail ran before this agent responded. | A hardware attestation that the guardrail code ran[11] |
| Evaluations and audits | This score came from the stated model and test set. | An evaluation run in a trusted execution environment, or an audit with deeper access[8, 10] |
| Policy | A developer or government kept a commitment about training compute. | Proposed monitoring of the chips used for large training runs[12] |
Each kind answers a narrower question than the claim a reader cares about. Each also moves trust somewhere else.
\nCryptographic proofs. A zero-knowledge proof lets a provider show that an output was computed from a given input and a committed model without revealing the model's weights. To commit to a model, the provider publishes a cryptographic value derived from its weights, which binds the provider to those weights. In zkLLM, the provider commits to the weights of a model whose architecture is public. The authors report proving a 13-billion-parameter model's inference in under 15 minutes, with proofs under 200 kB.[4] The verifier still trusts the proof system's soundness, the property that a false statement cannot be proved. It also needs separate evidence that the committed weights are those of the advertised model.
\nHardware attestation. A trusted execution environment (TEE) is a hardware-isolated execution mode of a processor. It records cryptographic hashes, called measurements, of the software it loads and reports them in evidence signed with a hardware-rooted key.[10] In the attestation architecture of the Internet Engineering Task Force (IETF), a verifier compares that evidence with reference values and manufacturer endorsements. A relying party then uses the result to decide whether to trust the machine.[3] Attestation establishes which software was loaded on genuine hardware in a protected mode. The hardware maker and the behavior of the measured software remain trusted.
\nSignatures and transparency logs. A signature ties specific bytes to a signer's key. Sigstore's model signing library hashes every file of a model into a manifest and signs the manifest. A user can therefore check that a downloaded model is what a known identity signed. When signing goes through Sigstore, the event is recorded in an append-only transparency log, where signers can watch for signatures they did not make.[6] Such records establish who signed what and make quiet replacement detectable. They say nothing about whether the signed model is good.
\nRe-execution and sampling. A checker can repeat all or part of a computation, for every request or a sample, and compare the results. In TOPLOC, the provider commits to compact hashes of the model's intermediate activations, the values the model computes inside its layers. A validator recomputes these hashes faster than the original generation. In the authors' experiments, the method detected changed models, prompts and numeric precision while tolerating numerical differences across graphics processors.[5] The validator must hold the claimed model. The scheme also covers only what it hashes. Its authors note that it cannot catch a provider that generates its output with a cheaper model and computes the hashed activations with the claimed one.[5]
\nFormal proofs. Formal verification seeks a mathematical proof that a technical claim is true, subject to certain assumptions.[1] The guaranteed safe AI framework proposes extending this idea to AI systems. In the framework, a verifier component would provide an auditable proof certificate that a system satisfies a safety specification relative to a world model. A world model is a mathematical description of how the system affects the world.[7] The certificate is only as useful as its specification and world model.
\nAudits with structured access. Claims about a developer's internal practices cannot be settled by one cryptographic check, so auditors examine them with more access than the public has. Casper and colleagues argue that black-box access, meaning querying a system and observing its outputs, is insufficient for rigorous audits. They also argue that access to weights and to training and deployment information, such as code, allows more scrutiny.[8] A 2026 proposal defines frontier AI auditing as rigorous third-party verification of developers' safety and security claims, based on deep, secure access to non-public information. The proposal also describes four AI Assurance Levels of increasing confidence.[9] A proposed protocol called Attestable Audits runs benchmarks inside TEEs. The aim is to keep model weights and test data confidential while letting users verify that they interacted with a compliant model.[10] Audits place trust in the auditor's competence, independence and access.
\nA verification result covers only the claim as stated, so three gaps remain.
\nFirst, an attestation shows what was loaded. It does not show that the software is safe. For example, the proof-of-guardrail system uses TEE attestation to show that an agent's response passed through a specific open-source guardrail. Its authors warn that a developer could still actively jailbreak the guardrail, that is, trick it into letting through content it should block.[11]
\nSecond, a proof covers its specification. If the specification or the world model leaves out a harm, a valid proof says nothing about that harm.[7]
\nThird, some parties must still be trusted. The IETF architecture uses the term roots of trust for components that no evidence describes, so endorsements must vouch for them. For hardware attestation, the verifier typically trusts the chip manufacturer and its hardware.[3]
\nA model signature lets you check that the files on your disk are the ones a known publisher signed, before any code loads the weights.[1] The check is only as strong as the signer identity you compare it against, and it covers only the signed files. Each step below therefore pairs a command with the decision it supports. The guide uses model_signing, the command-line tool of the model-signing package from Sigstore's model-transparency project.[1, 2] Version 1.1.1 was the current release on the Python Package Index (PyPI) on 20 October 2026.[2] Our brief on the 1.0 release gives the background.
Use it when a signed model arrives and you are about to serve it, fine-tune it or hand it to another system. The AI/ML working group of the Open Source Security Foundation (OpenSSF) announced the 1.0 release in April 2025. The group says signatures should be checked each time a model is used, including when it is selected for deployment and when it becomes input to another model.[8]
\nmodel.sig by default.[1, 3]https://accounts.google.com and the GitHub Actions issuer, https://token.actions.githubusercontent.com.[1, 3]Install one exact version, then check the version the tool reports.
\npip install model-signing==1.1.1\nmodel_signing --versionVersion 1.1.1 spells several flags with underscores, such as --identity_provider.[3] An unreleased change switches to hyphens and keeps accepting the underscore forms.[7] Commands written for a later release may therefore fail on 1.1.1. Follow the README at the tag of your release.[1]
With Sigstore, the signer uses a short-lived certificate for its OIDC identity. The signing event is recorded in a public, append-only transparency log.[1, 9] The identity and issuer are required arguments, and verification fails if they do not match the signature.[3]
\nmodel_signing verify path/to/model \\\n --signature model.sig \\\n --identity "$EXPECTED_IDENTITY" \\\n --identity_provider "$EXPECTED_ISSUER"For a key signature, pass the publisher's public key, which is your only link to the publisher.[3]
\nmodel_signing verify key path/to/model \\\n --signature model.sig \\\n --public_key publisher.pubFor a certificate signature, you must identify the signer yourself, because the command checks the chain but takes no expected signer name.[3] Without --certificate_chain, it falls back to a default set of root certificates.[4] Version 1.1.1 accepts some certificates whose extended key usage field does not permit code signing, such as certificates issued for web servers. The fix has not been released.[7] Pass the publisher's own chain, and identify the signer by confirming the signing certificate's SHA-256 fingerprint with the publisher; --log_fingerprints logs it.[3]
model_signing verify certificate path/to/model \\\n --signature model.sig \\\n --certificate_chain publisher-chain.pem \\\n --log_fingerprintsRead the output: the command prints Verification succeeded, or Verification failed with error: followed by the reason. On failure it exits with status 1.[3] It hashes the directory and fails if a signed file has changed or is missing, or if an extra file is present. The error names the files.[4]
A pass says nothing about skipped paths, which include Git-related files by default.[1] Since version 1.1.0, a signature also records the paths the publisher excluded at signing, and verification skips them automatically.[7] Two flags add to these: --ignore-paths skips paths you name, and --ignore_unsigned_files lets extra files pass.[3, 7] Use them only for files your loader never reads.
Leave --allow_symlinks off. With it on, version 1.1.1 silently leaves every file under a symbolic link to a directory unsigned and unchecked. The changelog lists this flaw as fixed only in unreleased code.[7]
To see what the signature covers, decode its signed statement with the jq tool:[9]
\njq -r .dsseEnvelope.payload model.sig | base64 -d | jq .In the output, predicate.resources lists each covered file with its hash algorithm and digest (the hash value). The predicate.serialization field records the hashing settings, including any paths excluded at signing.[6] A predicateType of https://model_signing/Digests/v0.1 marks a pre-1.0 signature. The tool can verify such a signature but not create one, replicating version 0.2's experimental behavior \"bug for bug,\" as the changelog puts it.[6, 7]
This step applies only to Sigstore signatures, which are recorded in Rekor, Sigstore's append-only transparency log.[1, 11] The verify command has already checked the bundle's proof that the entry is in the log.[1, 9] The bundle also holds the entry's log index and its integrated time, the time the log recorded the entry. A signed timestamp in the bundle shows that signing happened while the short-lived certificate was valid. Verification can therefore succeed after the certificate expires.[9]
\njq '.verificationMaterial.tlogEntries[] | {logIndex, integratedTime}' model.sig\nrekor-cli get --rekor_server https://rekor.sigstore.dev --log-index <log-index>The second command fetches the entry with the Rekor command-line client.[10] The server it queries hosts Rekor's original log, which is still the default for Sigstore's public instance. The version 2 logs that ecosystems can opt into have other addresses.[11, 12]
\nKeep enough for an auditor to repeat the check.
\nIn May 2026, cybersecurity agencies of the Group of Seven (G7) countries published minimum elements for a software bill of materials (SBOM) for AI. They describe such an SBOM as a structured record of an AI system's components. For each model, the record should give a hash of the weights or model file and the hash algorithm, so that the component's integrity can be validated. The SBOM itself should carry a digital signature attributable to its author.[13]
\nA verified model signature supplies such hashes from a known signer. Each entry in predicate.resources gives a file's algorithm and digest. The statement's subject carries one SHA-256 digest over all of them. The project intends that digest for referring to the model from other metadata documents.[6] Copy these values into the model's SBOM entry. If an SBOM you receive gives a different digest for the same file and algorithm, it describes a different file from the one the publisher signed. The model signature ties the files to the publisher, while the SBOM's signature ties the inventory to its author. Our brief on the minimum elements covers the full list.
Remote attestation lets one party obtain hardware-signed evidence about another machine's software state before trusting it with data or work.[1, 2] For AI workloads, a user's device may want to know which software will receive a prompt before encrypting it, and a model owner may want the same evidence before releasing the key that decrypts its weights.[1, 8] The evidence comes from a trusted execution environment (TEE). A TEE is a hardware-isolated execution mode of a processor that records what it loads and signs a report about it.[2, 3] A valid report tells that party what was loaded and on which hardware. It does not show that the loaded software behaves as its operator says.
\nThe Internet Engineering Task Force (IETF) published the Remote ATtestation procedureS (RATS) architecture as RFC 9334. The architecture names the roles independently of any processor or protocol.[1] The third column is our illustration.
\n| Role | What it does | Typical party in an AI service |
|---|---|---|
| Attester | Produces evidence: claims such as measurements and configuration | The confidential virtual machine (VM) and the graphics processing units (GPUs) that run the model |
| Verifier | Appraises evidence against reference values, endorsements and an appraisal policy, then issues an attestation result | A vendor's attestation service, or a library in the client |
| Relying party | Uses the attestation result to make its own decision | The user's client, or a key service that holds model keys |
| Endorser | Vouches for the attester's capabilities, for example by certifying a signing key held only in hardware | The chip maker |
| Reference value provider | Supplies the expected values that claims are compared with | The software publisher, and the hardware maker for firmware |
A client that checks evidence itself is both verifier and relying party.[1]
\nEvidence starts with measurements, cryptographic hashes of code and data recorded as they are loaded. In what RFC 9334 calls layered attestation, each stage measures the next one before starting it. No stage may alter the record of its own loading.[1]
\nConfidential VMs apply this pattern at launch. The hardware is designed to isolate their memory from the host and from the hypervisor, the software that manages virtual machines. In Intel Trust Domain Extensions (TDX), the TDX module records a measurement of the VM's initial memory pages in a measurement register. Software inside the VM can extend runtime measurement registers with measurements of code and data it loads later.[2] In AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP), the AMD Secure Processor measures the VM's initial memory pages and their placement into a launch digest.[3]
\nThe measurements are then signed. Intel's design converts a report generated by the processor into a quote, signed with an attestation key. The key's certificate chain leads to an Intel certification authority, and Intel aims to publish the certificates and revocation lists for that chain.[2] AMD's firmware signs reports with a Versioned Chip Endorsement Key (VCEK). Each chip has its own VCEK, derived from the version numbers of its trusted components, so a valid signature also identifies those versions.[3] Both designs let software inside the VM add its own data to the report, such as a public key it will use to communicate, or a hash of that key.[2, 3]
\nBefore anything sensitive is sent, a verifier works through these checks:
\nLarge models run on GPUs, which hold the model and the data during inference. An attestation from the central processing unit (CPU) alone therefore says nothing about the GPUs. NVIDIA's confidential computing mode for H100 GPUs works with a confidential VM on AMD SEV-SNP or Intel TDX.[4] Data transfers, command buffers and CUDA kernels are encrypted before they cross the PCI Express bus between the VM and the GPU. The GPU's on-package memory is not encrypted. NVIDIA says this memory is considered secure against everyday physical attack tools.[4]
\nThe VM's trust boundary encloses the components it trusts with the data. Before including the GPU in it, the VM checks the certificate for the GPU's identity key against NVIDIA's certificate authority and confirms that the certificate has not been revoked. That identity key is burned into the chip's fuses. The GPU also produces a signed attestation report of its measurements.[4] NVIDIA's Remote Attestation Service (NRAS), or a local verifier, compares those measurements with reference integrity manifests (RIMs). RIMs are reference values that NVIDIA generates and signs as part of its driver and GPU firmware builds.[5, 6] The measured components include hardware configuration, firmware and driver microcode.[6]
\nWith evidence from the CPU's TEE and from each GPU, the machine is what RFC 9334 calls a composite device. Each component produces its own evidence, and a lead attester collects it.[1] A relying party needs all of it, tied to one machine.
\nA report that passes these checks shows that genuine hardware at known firmware versions loaded the measured software in a protected mode, with fresh evidence tied to the connection. Four gaps remain.
\nBehavior and later inputs are outside the report. A measurement identifies code. It does not show that the code enforces its policy, and it says nothing about inputs loaded afterward. The WhatsApp audit found configuration files with environment variables that were loaded after measurement. An insider could have used them to load malicious code while attestation still passed.[7]
\nA matching measurement helps only if someone knows what the build does. Apple committed to publishing every production PCC image so that researchers can check it against the logged measurements.[8] Trail of Bits notes that it remains challenging to make confidential VM images fully reproducible, so that outsiders can rebuild and examine them.[7]
\nThe hardware maker stays trusted. RFC 9334 uses the term roots of trust for components that no evidence describes, so endorsements must vouch for them.[1] A threat model states what a design defends against and what it trusts. AMD's SEV-SNP threat model, for example, treats the chip's hardware and its secure processor as fully trusted.[3]
\nPhysical attacks and side channels are often out of scope. AMD lists attacks on the memory bus while a VM is running as out of scope. It also says hardware does not specifically prevent architectural side channels.[3] Intel says TDX does not prevent all types of hardware attacks.[2] In September 2026, researchers disclosed DDRop, a memory-bus interposer: a device inserted between the processor and its memory. Its parts cost less than $200. The researchers report using it on Intel TDX to forge the measurement in an attestation report. Intel and AMD told them physical attacks on main memory are out of scope for current products.[11]
\nModel weights need their own check. A launch measurement describes what was in memory at start-up. If weights are loaded afterward, the attestation says nothing about which model is serving, unless the software measures the weights or verifies a signature over them before use. It can measure them into a TDX runtime measurement register, for example.[2] Google's Confidential Space reports the image digest of the workload container.[9] That digest covers weights built into the image, but not weights downloaded later.
\nAttestation can also be a condition for releasing the weights. RFC 9334 describes a model owner that releases a model, or the key to decrypt it, only to a device that passes attestation.[1] Anthropic's 2025 design sketch keeps weights encrypted and decrypts them only in a small trusted loader, after a key server has checked attestation.[10]
\nThe trusted computing base grows with the inference stack. Everything inside a confidential VM belongs to the workload's TCB, because AMD's threat model treats the VM itself as fully trusted and responsible for protecting its own interfaces.[3] With GPUs, the TCB includes the NVIDIA driver,[4] along with the operating system and serving software. Anthropic's sketch keeps the trusted part small. Within its inference server, only a small loader can access decrypted data. Anthropic says the rest might change frequently without affecting the system's security.[10]
\nRFC 9334 defines the full vocabulary,[1] and the Trail of Bits audit shows where one deployment's checks fell short.[7]
None of the three main approaches checks a hosted model's answer both cheaply and with few parties to trust. Zero-knowledge proofs give cryptographic evidence that the answer was computed by a model fixed in advance, so they avoid trusting the provider's hardware. But the systems examined here are slow and have been demonstrated only on smaller models. Attested enclaves are hardware-isolated environments that report which software they loaded. When tuned, they can run large models at a few percent overhead. In exchange, anyone relying on them must trust the chip vendors, the measured software and whoever checks the measurements. Re-execution reruns the model and compares the answers. It costs far less than proving, but its assurance rests on tolerances, sampling or disputes, and on an honest checker. Each family answers a different question at a different cost.
\nVerifiable-inference work checks a narrow claim: this output came from running a specific model on this input. The model is identified by its weights, and the run uses stated settings such as numeric precision and decoding method [2, 9, 12]. Providers have a motive to deviate: a smaller or lower-precision model costs less to serve, and users see only text [9, 11]. Confidentiality, whether the provider can read the prompt, is a separate property.
\nZero-knowledge machine learning (zkML) systems prove that an output was computed from committed weights. The weights are fixed in advance by a cryptographic fingerprint, the commitment, which hides them. A verifier checks the proof without seeing the weights [1]. In 2024, zkLLM proved inference over a 2,048-token input for Llama 2 13B in 803 seconds on one NVIDIA A100 GPU. Verifying the 188 kB proof took about 4 seconds [1]. The 2026 DeepProve paper reports proving every generated token of a response: about 174 tokens per minute for GPT-2 and 86 for Gemma 3, and up to 1,855 with distributed proving [2].
\nSuch a proof shows that the output is consistent with a commitment. That matters only if the commitment is tied to a known model. In zkLLM's setting, the developer publishes the commitment once and proves each response against it [1].
\nThe proven computation is also an integer version of the model. zkLLM maps it into a finite field (a number system with finitely many values), and DeepProve quantizes weights and activations (the intermediate values the model computes) to 12 bits by default [1, 3]. DeepProve's proofs also require each token to be the model's top-scoring prediction, as in greedy decoding [3]. The zero-knowledge property hides the weights from the verifier, but the provider still sees the prompt [1].
\nA trusted execution environment (TEE) is a hardware-isolated environment designed to keep its memory from the host operating system and the hypervisor, the software that manages virtual machines. A confidential virtual machine, one that runs as a TEE, can use Intel Trust Domain Extensions (TDX) and be paired with NVIDIA GPUs in confidential computing mode. Remote attestation then supplies a measurement of the software loaded at launch: a cryptographic hash that the hardware signs [4]. A preprint by Confidential.ai authors tested generation-heavy serving of a 229-billion-parameter model on NVIDIA B200 GPUs. With a tuned software stack, they measured about 1% to 3% throughput overhead; stock inference stacks lost 30% to 40% [4].
\nThe enclave is designed to keep prompts and weights from the operator, while attestation is evidence about which software was loaded [4]. Neither shows that the software computes the advertised model correctly, so trusting the output means trusting the measured inference stack.
\nUnder the attestation architecture of the Internet Engineering Task Force (IETF), a verifier compares the evidence with reference values, such as known-good measurements [5]. That comparison covers only what was measured and tied to the current session. Trail of Bits' pre-launch audit of WhatsApp's TEE-based AI processing found gaps of both kinds. Configuration loaded after the measurement could let an insider run malicious code while attestation still passed. And because reports lacked a fresh value from the client, anyone who had compromised an enclave once could replay them, presenting old reports as new. Meta fixed both [6].
\nThe auditors' rule is that every loaded input must be measured or treated as hostile [6]. By that rule, weights loaded after launch are covered only if measured code checks them, for example against a published hash.
\nPhysical access can also defeat attestation. In September 2026, researchers disclosed DDRop, a device that costs under $200 to build and silently drops a server's memory writes. With one brief physical visit and control of the host software, they made a rogue Intel TDX virtual machine pass attestation using a legitimate workload's measurement. Intel and AMD consider physical attacks on server memory out of scope for current products [7].
\nRe-execution checks an answer by rerunning the model on the same input and comparing, but GPU inference is often not reproducible. Thinking Machines Lab ran one prompt 1,000 times on a 235-billion-parameter Qwen3 model at temperature zero, a setting that removes randomness from token selection. The runs produced 80 distinct completions. The lab traced the differences to the order of operations in GPU kernels, the programs that perform the model's arithmetic. That order shifts with batch size, the number of requests processed together, and therefore with server load [8].
\nTOPLOC tolerates the noise. The provider commits to locality-sensitive hashes of intermediate activations: fingerprints designed to absorb small numeric differences. A validator with the weights recomputes the hashes in one pass over all tokens, faster than generation. In the authors' tests, it caught every changed model, prompt and precision without false alarms. But it cannot catch a provider that generates tokens with a cheaper model and hashes them with the claimed one. Catching that requires checking the sampling step that picks each token [9].
\nVerde removes the noise instead. Its RepOps library fixes the order of floating-point operations. When two providers disagree, a referee narrows the dispute to one operator, a single step of the computation, and recomputes only that. The client therefore gets the correct result if at least one provider is honest. On A100 GPUs, the authors report that RepOps adds 58% overhead relative to PyTorch for inference with a 1-billion-parameter Llama model and 98% with an 8-billion-parameter one. So far it covers only single-GPU runs. Running each job twice at least doubles the cost. The authors still put this cost under one order of magnitude, compared with at least four for cryptographic proofs [10].
\nIMMACULATE checks a sample. An auditor sends requests that look like ordinary traffic. The auditor then asks the provider to prove how far its next-token scores for those requests stray from the claimed full-precision model's. The authors report under 1% throughput overhead. Their guarantee assumes an honest auditor whose requests the provider cannot single out. It also assumes a provider that cheats on at least 10% of queries [11]. So the guarantee does not cover rare cheating. Every scheme here also fails if no one runs the check.
\n| Property | Zero-knowledge proofs | Attested enclaves | Re-execution and sampling |
|---|---|---|---|
| A passing check shows | The output follows from the committed weights under the proven computation | Genuine hardware launched software matching the reported measurements | A rerun or audited sample matched, exactly or within a tolerance |
| What must be trusted | Proof-system assumptions; a proven computation faithful to the model's architecture; a commitment tied to a known model | Chip vendors; the measured software; reference values and the verifier; physical security | An honest checker who runs the check; the reproducibility method or threshold |
| Reported cost | 803 seconds per proof for a 13B model [1]; 86 to 174 tokens per minute, up to 1,855 distributed [2] | 1% to 3% throughput loss when tuned, 30% to 40% stock [4] | One pass over all tokens per check [9]; 58% to 98% inference overhead relative to PyTorch on A100 GPUs, plus a duplicate run [10]; under 1% overhead with sampling [11] |
| Maturity | Research systems; DeepProve's code is marked not production ready [3] | Commercial hardware [4]; WhatsApp AI features, audited before launch [6] | Research protocols; one deployment reported live [12] |
| Typical failure modes | Commitment not tied to the served model; proven computation differs from the served one | Unmeasured inputs; replayable reports; physical attacks that forge attestation | Thresholds that miss subtle changes [9]; unchecked token sampling; rare cheating; absent checkers |
EigenAI, which Eigen Labs says launched in January 2026, joins two of the families: re-execution and attested enclaves. Operators run bit-exact deterministic inference, with the random seed fixed as an input. Results are accepted unless someone challenges them within a dispute window. A challenge triggers re-execution by a committee of verifiers inside attested enclaves. A mismatch triggers a penalty drawn from the operator's staked funds, the collateral it has locked up. Eigen Labs reports 1.8% added latency. It requires the same GPU model for operators and verifiers, because its tests across architectures never matched. Determinism reduces the check to a byte comparison. The company also says requests are decrypted only inside the enclaves during verification [12]. IMMACULATE's prototype likewise ran its audit computations in an Intel TDX enclave. That was hundreds of times slower than GPU inference, so the prototype relied on sampling to keep the cost negligible [11].
\nEach combination keeps its parts' assumptions. EigenAI still needs a challenger to act within the dispute window. The privacy of re-executed requests is only as strong as the enclave hardware, including against physical attacks such as DDRop [7, 12].
\n\nApple, Meta and Google now send some AI requests to servers designed to keep the companies' own staff out. The servers use remote attestation to report which software they loaded [1, 6, 8]. Cohere offers a similar arrangement through its Model Vault service [11]. The published designs show that what an outsider can check depends less on the hardware than on three choices built on top of it. The choices are a public log of software releases, an attestation check on the user's device, and research access to the software. The providers make these choices differently, so \"verifiable\" means different amounts of outside checking.
\nEach choice fills a gap that attestation leaves open. A trusted execution environment (TEE) is designed to isolate software from the machine's operator. Its attestation report is signed by a key in the chip and carries a measurement: a cryptographic fingerprint of the loaded software [6, 7]. The measurement identifies the build, the exact software version, but does not show what the build does with a request [6, 11]. A public log lets the device confirm that the build is on a record outsiders can see. An attestation check on the device keeps the provider from simply asserting that its servers passed. Research access lets outsiders examine what the build does.
\nApple's Private Cloud Compute (PCC), announced in June 2024, makes all three choices. A user's device encrypts a request only for server nodes whose attested measurements match a release in a public, append-only transparency log. Apple committed to publishing each production image, the software the server nodes boot, within 90 days of its log entry [1]. In October 2024 Apple released a Virtual Research Environment (VRE), along with source code for selected components under a limited-use license. The VRE lets anyone with a suitable Apple silicon Mac download a logged release and boot it in a virtual machine. A researcher can thus run a lightly modified copy of the software whose measurement a device checked [2].
\nApple's June 2026 expansion moves new Apple Intelligence workloads onto Google Cloud. The deployment uses NVIDIA confidential-computing GPUs, Intel CPUs with Trust Domain Extensions (TDX) and Google's Titan chip. Apple says it keeps an append-only ledger of that hardware and will publish all binaries. It also says that for components that could expose user data if compromised, attestation is rooted in at least two independent vendors' roots of trust (the parts of a system trusted without further checks) [3]. Outside checks lag behind. Apple's release notes describe the deployment as a preview ramping toward PCC's full security, privacy and transparency properties. They also say VRE support for its attestations and log entries awaits a public research program due later in 2026 [3, 4].
\nMeta's Private Processing, introduced for WhatsApp in 2025, also puts the check on the device. Before sending a request, the app opens a session with a confidential virtual machine (CVM), which runs as a TEE. The session uses Remote Attestation plus Transport Layer Security (RA-TLS), which ties the encrypted connection to the CVM's attestation. The app also cross-checks the CVM's measurements against a third-party ledger [5]. Meta's September 2026 description, covering AI glasses, calls the ledger append-only and publicly witnessed. It says the measurements are public, while the binaries are available under agreement to researchers in Meta's security program. Meta says client devices and outside monitors could discover any deployed code that differed from the published record, a property it calls tamper-evidence. But confirming what a recorded image does requires the binaries [6].
\nTrail of Bits' pre-launch audit of the WhatsApp system shows why that access matters. It reported 28 issues, eight of them high severity [7]. In one, configuration files were loaded after the measurement was taken, so an insider could have injected code while the attestation still verified. In another, tables describing the hardware to the operating system were left out of the measurement. Because both inputs sat outside the measurement, tampering with them would not have changed it. So a ledger check would still have passed. Meta fixed both. Trail of Bits added that outside verification requires researchers to reproduce and examine the CVM images, and that full reproducibility remained challenging [7].
\nGoogle's Private AI Compute runs Gemini models on a hardened Tensor Processing Unit (TPU) platform. Google says the platform offers privacy and security properties comparable to a typical TEE. Private AI Compute's CPU services run in CVMs using AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) [8]. The larger difference from Apple and Meta is where attestation is checked. In the chain of trust NCC Group's 2025 review describes, the device trusts a public key built into the client. Google's key store decrypts requests only for frontend servers that hold a token. Borg Prime, Google's central orchestrator, issues that token after verifying the server's attestation [9].
\nNCC wrote that only Google and the external auditors it granted internal access could verify whether components had been compromised. It also judged that Google as a whole retains the power to expose user data, although no single insider does [9].
\nGoogle's September 2026 update moves some evidence outside the company. Its new encrypted, per-user memory store runs on an open-source server and runtime. Google ties their published source to the deployed enclave in two ways. Reproducible builds let anyone build the source again and get identical binaries. An append-only ledger records the endorsed binary digests, or hashes [8]. On the device, an open-source Android library verifies the memory enclave's attestation before sending the user's key [10]. For the rest of the system, Google publishes digests of critical components and lists two items as future work: validating attestation evidence on the device, and a log co-signed by independent third parties [8]. Trail of Bits noted that Google can change the system without prior external review and that the system contains extensive closed-source code [10].
\nCohere's Model Vault Encrypted, in its Intel TDX deployment, relies on Intel Trust Authority, an attestation service that Intel operates. The service checks each CVM's CPU and GPU evidence against a policy of expected measurements that Cohere registers. Cohere's client-side proxy verifies Intel's signed token before sending a request. Cohere says its vault image and workload are open source and reproducibly built [11]. The customer's client makes the final check. Intel, which also makes the CPU, sits between customer and Cohere as the verifier.
\n| Design | Software record | Who checks attestation | Outside inspection |
|---|---|---|---|
| Apple PCC on Apple silicon [1, 2] | Public append-only log; binaries published within 90 days of being logged | User's device | Public binaries, VRE, some source, bug bounty |
| Apple PCC on Google Cloud, preview [3, 4] | Same log; VRE cannot yet parse these releases | User's device; protections still being phased in | Research program due later in 2026 |
| Meta Private Processing [5, 6, 7] | Measurements in a publicly witnessed ledger | User's device | Binaries shared under agreement, bug bounty, published audit |
| Google Private AI Compute [8, 9, 10] | Ledger of digests for critical components | Google's infrastructure; user's device for the memory store | Audits with internal access, open-source memory server |
| Cohere Model Vault Encrypted [11] | Policy registered with Intel Trust Authority | Customer's client, via Intel's token | Cohere says its stack is open source |
The first dependency is the hardware. In September 2026, researchers disclosed DDRop, a device built from about $160 in parts that silently drops writes to a server's DDR5 memory. The memory then holds stale data, which the memory encryption in Intel TDX and AMD SEV-SNP cannot detect. On TDX, the researchers used it to make a rogue CVM they controlled pass remote attestation with a legitimate workload's measurement. On SEV-SNP, they used it to copy a victim's memory pages. The attack needs a brief physical visit plus control of the host software. Intel and AMD treat physical memory attacks as out of scope for current products [12].
\nApple, Meta and Google face this dependency differently. Apple adds a hardware ledger and a second, independent root of trust [3]. Trail of Bits found that Meta needed extra controls over which CPUs could be trusted, because SEV-SNP does not fully protect against advanced physical attacks [7]. NCC noted that for Google's TPUs, the hardware maker that must be trusted is Google itself [9].
\nThe second dependency is what a measurement leaves out. Besides the WhatsApp findings, Apple's release notes disclose that a configuration value was read without attestation until a later release. The value decides whether certain agent tools run in isolation [4]. NCC found it unclear whether some Google binaries rely on configuration packages that the transparency log does not track [9]. Log filters and egress rules (rules for outgoing network traffic) decide what leaves the protected machine [1, 5, 8]. Outsiders can check them only as far as they see the code, which Apple publishes for its filter [2]. Trail of Bits also found that Google sends truncated hashes of response fragments outside the trusted boundary to check whether responses recite copyrighted text. It rated this unresolved issue high severity but hard to exploit [10].
\nThe third dependency is the record itself. Apple may publish a logged build up to 90 days after it enters the log, so a build can serve requests before outsiders can download it [1]. Verification code needs review too. Trail of Bits found two flaws, since fixed, in Google's attestation and ledger checks. The flaws would have let two or more unauthorized insiders acting together deploy modified services without a publicly visible ledger entry [10].
\nThe first open question is whether the promised checks are delivered, such as Apple's research program for PCC on Google Cloud and Google's device-side verification [4, 8].
\nThe second is who watches the logs. A harmful build that is properly logged is caught only by someone who monitors the log and can examine the build. For Meta's binaries and Google's closed-source code, that examination requires access the provider grants [6, 10].
\nThe third concerns stored state. Google's memory store, Meta's encrypted storage for glasses and Apple's reuse of encrypted intermediate model state across conversation turns keep user data beyond one request [4, 6, 8]. An attestation, checked when a device connects, describes the software a server loaded. How outsiders should check what happens to stored data afterward is unsettled.
\n\nAn attestation report is evidence that you must check against your own requirements before any data leaves your systems. In remote attestation, a machine produces hardware-signed evidence about its software and configuration so that a remote party can decide whether to trust it. Vendor tools can confirm that a report is genuine and that the platform's firmware is current. But judging the software the report records remains your task. For instance, Intel's verification library for Trust Domain Extensions (TDX) leaves it to the verifier to compare the measurements in a quote (Intel's signed report) with expected values.[5] The nine checks below use field names from Intel TDX and AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) as examples.
\nUse it when a service offers attestation evidence and you must decide whether to send it prompts, documents or model weights. Such a service runs in a trusted execution environment (TEE), where hardware is designed to isolate the workload from its host. In this guide, the workload is a whole virtual machine (VM). AMD SEV-SNP, for example, encrypts each VM's memory with its own key.[3] Repeat the checks whenever the service releases new software or the vendor raises its minimum firmware versions.
\nIn the terms of RFC 9334, the Internet Engineering Task Force (IETF) attestation architecture, the service is the attester. A verifier appraises its evidence against reference values. You, the relying party, apply your own policy to the verifier's result.[1]
\nIdentify each attester and its TEE technology, because each technology has its own evidence format and verification tools.[2, 5] An AI service may add evidence from its graphics processing units (GPUs). NVIDIA's verifiers compare GPU evidence with reference measurements from signed manifests, and an Online Certificate Status Protocol (OCSP) service checks the certificates for revocation.[6]
\nCheck that the report's signature chains to a key the vendor controls. Otherwise, the report does not count as evidence. An SEV-SNP report's SIGNING_KEY field identifies the key that signed it, such as the chip's Versioned Chip Endorsement Key (VCEK).[2] AMD's Key Distribution System (KDS) serves VCEK certificates and the chain behind them: the AMD Root Key (ARK) issues the AMD SEV Key (ASK), which issues the VCEK certificate.[3] For TDX, Intel's library checks the Provisioning Certification Key (PCK) certificate chain and the quote's signature.[5]
\nCheck the versions of the trusted computing base (TCB), the set of components the protection depends on. AMD defines a TCB version as a combination of component versions, such as SNP firmware and processor microcode. AMD raises the minimum patch level when it fixes vulnerabilities. Each VCEK is unique to a chip running a specific TCB version.[3] A report's REPORTED_TCB names the version used to derive the key that signed it.[2] AMD's guide compares these values with those in the VCEK certificate.[4]
\nTrail of Bits found that WhatsApp's Private Processing system originally trusted the patch level the firmware claimed. Meta's fix instead reads the patch level from the VCEK certificate and enforces a minimum.[7]
\nFor TDX, Intel's library returns a verification result such as OK, OUT_OF_DATE or REVOKED. Intel also describes policies that accept an out-of-date platform for a grace period.[5]
\nCompare the measurements with published reference values. A measurement is a cryptographic hash of code or data, recorded as it loads. SEV-SNP's MEASUREMENT is a hash that the firmware computes at launch, as the hypervisor (the software that manages virtual machines) loads data into the VM's memory.[2] In TDX, a protected VM is called a trust domain. MRTD covers the trust domain's initial contents. By convention, four runtime registers, RTMR0 to RTMR3, hold measurements taken later by the virtual firmware, the operating system and the runtime.[5]
\nReference values tie each hash to a release that you or others can inspect. In Apple's Private Cloud Compute design, a device encrypts its request only for nodes whose attested measurements match a release in a public, append-only transparency log.[8]
\nSend a nonce, an unpredictable value used once, and check that the signed report contains it. A valid report from last week says nothing about the machine today. Under the nonce approach in RFC 9334, the appraising party sends the nonce, and the attester includes it in the signed evidence. A match shows that the claims were signed after the nonce was generated.[1]
\nBoth technologies offer a 64-byte field for such data. In SEV-SNP it is REPORT_DATA, which the firmware does not interpret.[2] In TDX it is REPORTDATA, which Intel suggests can hold a verifier's nonce.[5] WhatsApp's reports originally carried no client-supplied value, so an attacker who compromised a TEE once could have replayed its attestation indefinitely.[7]
\nCheck that the report is tied to the connection you are about to use. Freshness shows a report is recent. Binding shows that your connection ends inside the attested environment. Intel notes that report data can carry a public key generated inside the trust domain for setting up a secure session.[5] Meta's fix for WhatsApp placed the client_random value from the Transport Layer Security (TLS) handshake in each report, tying every report to one connection.[7] Also ask how any GPU evidence is tied to your session. Without that tie, the GPU evidence could come from another machine.
\nCheck the debug and policy flags even on a genuine, fresh report, because it can still describe an environment the host can inspect. SEV-SNP's POLICY field includes a DEBUG bit. It also includes a setting for whether a migration agent (software that helps move the VM to another machine) may be associated with the VM.[2] In TDX, setting the DEBUG bit in TDATTRIBUTES lets the host access the trust domain's processor state and private memory. Intel advises against giving production secrets to a trust domain with any debug flag set.[5]
\nList the inputs the service reads after launch. They stay unverified unless measured code records them or checks them against expected values. Trail of Bits found two such gaps in WhatsApp's system. First, environment variables came from configuration files read after the measurement. This would have let an insider load hostile code without changing the attestation. Second, the Advanced Configuration and Power Interface (ACPI) tables, which describe hardware to the operating system, were not measured. This would have let a malicious hypervisor declare rogue devices with access to protected memory.[7] For an AI service, ask about model weights, adapters, system prompts and serving configuration.
\nKeep a record that lets you or an auditor reconstruct the decision. You need it because an attestation result reflects the policy, endorsements (usually vendor-signed statements about the hardware) and reference values in force when it was produced.[1]
\nA provider's statement that its model outputs are verifiable is only as useful as the specific claim behind it, because the mechanisms grouped under verifiable inference check different things. A zero-knowledge proof reveals nothing beyond the statement it establishes. Such a proof can show that an output is consistent with weights the provider has committed to.[1] A sampled audit checks only some requests and is designed to detect large-scale cheating with high probability.[6] This checklist turns a general claim into ten questions, each with a worksheet.
\nUse it before you rely on a provider's or protocol's claim that its outputs are verifiable. For example, you might rely on the claim when you pay for a particular model or let an agent act on the outputs. Gather the written claim with the paper or specification behind it, the verification tools, and your own requirements, including what a single wrong output would cost you.
\nWrite the claim out in full, naming the model, input, output, decoding settings (which control how each token is chosen) and time of the run. Each mechanism covers only some of these. zkLLM's zero-knowledge proofs show that a returned result is correct for the prompt and for a confidential model the provider has committed to.[1] Gong, Liu and Li argue that such proofs do not bind the computational effort spent. In their Hollow-LLM attack, a provider keeps the declared architecture and parameter count but uses weights that reduce the work to that of a much smaller model. The proofs still verify.[3] TOPLOC checks hashes of the model's internal activations. Its authors note that it cannot detect speculative decoding, in which a cheaper model generates the tokens. In their tests, though, it caught every change of model, prompt or numerical precision.[4]
\nName the mechanism the claim relies on. Each family of mechanisms rests on different evidence and assumptions.
\n| Mechanism | Example | A passing check shows | Main assumption |
|---|---|---|---|
| Zero-knowledge proof | zkLLM, DeepProve[1, 2] | The output matches the public architecture run on committed weights[3] | The commitment identifies the intended weights |
| Hardware attestation | Serving in a trusted execution environment (TEE)[7, 9] | Which software genuine hardware loaded | The hardware vendor and the measured software |
| Activation fingerprint | TOPLOC[4] | Recomputed activations match the provider's hashes within set thresholds | A validator able to rerun the model |
| Refereed delegation | Verde[5] | The correct result, if at least one provider is honest | Operators in the model's computation give bit-identical results across hardware |
| Optimistic re-execution | EigenAI[8] | Nobody challenged within the dispute window, or re-execution matched | Someone challenges; verifiers use identical hardware |
| Sampled audit | IMMACULATE[6] | Audited requests were consistent with the claimed model | Audit requests are indistinguishable from normal ones |
Find out what data and hardware the verifier needs, because these decide whether you, or someone you trust, can run it. Zero-knowledge proofs promise public verifiability,[3] and DeepProve reports verification times of 1 to 3.7 seconds.[2] TOPLOC's validator reruns the model over the generated tokens to recompute activations,[4] so it needs the weights and suitable hardware. EigenAI requires verifiers to use the same graphics processing unit (GPU) models as the operators who run inference, because A100 and H100 GPUs produce different results for identical operations.[8]
\nList each party or component whose failure would let a wrong output pass. Every mechanism leaves at least one, and the table's last column names the main one. Outside testing does not remove that dependence. Cai and colleagues conclude that tests run without the provider's cooperation cannot reliably detect model substitution. Statistical tests on text outputs need many queries and miss subtle substitutions, and tests on log probabilities fail because production inference is nondeterministic.[7] Cai and colleagues propose TEEs instead. A TEE moves trust to the hardware vendor and the measured software. Our guide to reading a remote attestation report covers those checks.
\nFind out whether the scheme checks each output, a sample or only disputed results. An IMMACULATE auditor sends a small number of random requests that look like normal traffic. The auditor then asks the provider to prove how it served them. The authors reason that cheating pays only if a provider deviates on a non-negligible share of requests. So, they argue, such sampling detects large-scale deviations with overwhelming probability.[6] Under EigenAI's optimistic design, results stand unless someone challenges them during a dispute window.[8] Both designs target systematic cheating. Neither guarantees that a particular output you received was checked.
\nCheck that the evidence refers to your request, so that it cannot be reused for another. It must also capture every input that determines the output. EigenAI describes its output as a pure function of the model, prompt, seed and decoding settings, that is, as depending only on these four inputs. So all four must be recorded for a re-execution to match.[8] Session binding matters too. Attestation reports in WhatsApp's TEE-based system originally carried no client-supplied value, so they could have been replayed. Meta's fix ties each report to one Transport Layer Security (TLS) connection.[9] Keep the evidence with the record of any action an agent takes on the output. You can then trace that action to a verified result.
\nCheck the model commitment, a published cryptographic fingerprint of the weights that later proofs refer to. In zkLLM, the provider spends up to 20 minutes committing to a model and publishes a commitment of about 10 MB.[1] A commitment fixes a set of weights without saying which weights they are. Unless the provider links it to a release you can inspect or evaluate, a proof shows only consistency with some fixed weights. The Hollow-LLM results show that weights fitting a large declared architecture can do a much smaller model's work.[3]
\nFind out what consequence a failed check has. Without a defined consequence, detecting an error changes nothing. In EigenAI, a mismatch found on re-execution leads to slashing, which takes funds from the operator's stake.[8] In Verde, a dispute narrows to a single operator in the model's computation. The referee re-executes that operator to find which provider was wrong.[5] With proofs and attestations, your own client decides the consequence, so confirm that it rejects an output that fails.
\nRecord what verification costs, because cost decides how much traffic a provider can afford to verify. zkLLM reports proving one inference of a 13-billion-parameter model in under 15 minutes.[1] DeepProve reports about 174 proven tokens per minute for GPT-2 and 86 for Gemma 3.[2] IMMACULATE limits its verifiable computation to audited requests and reports under 1% throughput overhead.[6] EigenAI reports under 2% overhead in its own tests.[8] Verde runs each task on at least two providers, so total cost at least doubles. Its reproducible operators also carry overhead relative to PyTorch: on A100 GPUs, the authors report 58% for Llama inference at 1 billion parameters and 98% at 8 billion.[5]
\nLook for outside review of both the mechanism and its deployment. zkLLM was accepted to the ACM Conference on Computer and Communications Security (CCS) in 2024; DeepProve's ePrint entry lists a minor revision for CCS 2026.[1, 2] Academic analysis can also expose a gap in a whole class of claims, as the Hollow-LLM paper argues for zero-knowledge inference.[3] Deployments need their own review. Trail of Bits' pre-launch audit of WhatsApp's TEE-based system found 28 issues, eight of them rated high severity.[9] Treat figures that only the provider has measured, such as EigenAI's reproducibility results, as claims until others reproduce them.[8]
\nA Content Credential that validates shows which certificate holder signed a set of claims about a file, and which of the file's bytes those claims cover. The person relying on the claims still has to judge whether they are true.[1] Content Credentials are manifests specified by the Coalition for Content Provenance and Authenticity (C2PA). A manifest lists statements about an asset, called assertions, in a claim that the signer signs.[1] Run the six checks below before you rely on a credential to publish, cite or label an image or video.
\n.c2pa manifest file, which c2patool reads with --external-manifest.[2] A re-encoded or resized copy cannot match the manifest's hard binding, which is a cryptographic hash of the original asset's bytes.[1]The specification defines three manifest states, each requiring the one before:[1]
\n| State | What validation has confirmed |
|---|---|
| Well-formed | The manifest and its assertions meet the specification's requirements |
| Valid | The signature verifies; the certificate was within its validity period and is not reported as revoked |
| Trusted | The certificate also chains to a trust anchor, a CA certificate that the validator accepts; or the user has added it to the validator's private credential store |
The asset is valid only if the hashed bytes are also unchanged. If the manifest is valid, you can attribute its claim to the claim generator: the hardware or software named in claim_generator_info.[1] In c2patool, --info reports whether the manifest validated, and the plain command prints the manifest data.[2]
c2patool image.jpg --info\nc2patool image.jpgFind the signer: the holder of the signing certificate, identified by its subject.[1] In the C2PA conformance program, the signer is always an instance of a generator product, a system that produces assets with manifests. CAs on the C2PA trust list may issue signing certificates only to conforming products.[4] Each certificate names the product and records an assurance level, currently 1 or 2, reflecting the security requirements the product met.[4] A credential trusted against this list therefore names a product, such as a camera app.
\nThe --certs option prints the certificate chain, and the trust subcommand checks it against the list passed with --trust_anchors.[2] If the chain reaches no accepted trust anchor, the validator reports 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'Both the program and conforming validators have documented gaps. An April 2026 security analysis led by researchers at the University of Maryland, Baltimore County (UMBC) says version 0.1 of the program certified products without technical review.[6] Version 0.2 has been the only version accepting applicants since 9 October 2026. It requires sample output files and a second approver for each record.[4] The UMBC-led authors also found two conforming validators that did not report Nikon's November 2025 revocation of a camera's certificate.[7] The specification says online validators should attempt a revocation check.[1]
\nSort what the validator displays, because only part of it is attributed to the signer. Created assertions are attributed to the signer. Gathered assertions come from other parts of the workflow, such as a person typing in details. They are signed as part of the claim but are not attributed to the signer.[1] Metadata outside the manifest, such as Exchangeable Image File Format (EXIF) fields, is not attributed to the signer even when hashed. The exception is metadata copied into a c2pa.metadata assertion among the created assertions.[1]
The actions assertion declares what was done to the asset. For a new asset, the first action is c2pa.created, with a digital source type such as trainedAlgorithmicMedia for output from a generative AI model. For an edited asset, the first action is c2pa.opened, with an ingredient assertion that describes the original.[1] Version 2.4 of the specification adds a c2pa.ai-disclosure assertion for details such as the type of model.[1] Unless allActionsIncluded is true, other actions may have gone unrecorded.[1]
A hash match protects only the bytes it covers, so list the exclusion ranges: the byte ranges that the hash leaves out. One range holds the manifest, and the specification allows others only for asset metadata. The claim generator must ensure that whatever an attacker writes there cannot materially change how the asset is interpreted.[1] Validators must reject a manifest if the range holding it contains other data. They must flag extra ranges with an informational code such as assertion.dataHash.additionalExclusionsPresent.[1]
The UMBC-led authors report that a Pixel 10 Pro stored location data in an exclusion range. They also report that a conforming validator did not detect their change to that data.[7] On 2 October 2026, security researcher David Buchanan published an image with a single exclusion range that spanned the whole file. He said the image's signature was valid but protected none of the file, and that no verification tool he could find flagged it. He showed the range with c2patool's detailed report.[2, 5]
\nc2patool image.jpg -dLook for a TSA time-stamp, the only source of a trusted time for a manifest. The TSA countersigns the claim signature, which shows that the signature existed at the attested time. Times written by the claim generator, such as an action's when field, are untrusted.[1] The validator must chain the TSA's certificate to its TSA trust anchors, which include the C2PA TSA trust list. If it cannot, it reports timeStamp.untrusted and ignores the time-stamp.[1]
With a trusted time-stamp, the validator judges the certificate's validity at the attested time. The credential therefore still validates if the certificate expires or is revoked after that time.[1, 3] Without one, an unchanged file stops validating once the certificate expires.[1, 7]
\nEven a trusted time-stamp dates only the signature. Buchanan says he edited the winning numbers into his image after a lottery draw. According to him, its trusted time-stamp from hours before the draw remained valid, because the signature covered none of the image.[5] The UMBC-led authors add that nothing in the signed data refers to the time-stamp, so it can be removed and replaced without detection.[7]
\nDo not treat a missing manifest as evidence about a file's origin, because metadata can be removed deliberately or accidentally.[9] Soft bindings can lead back to the manifest. A soft binding is an identifier computed from the content, such as a fingerprint, or embedded in the content as an invisible watermark. It can therefore match a copy whose bytes differ.[1]
\nIf the original manifest recorded a soft binding and a copy is stored in a manifest repository, the binding can locate that copy. The matcher must then confirm that every soft binding in the recovered manifest matches those used in the search.[1] The CAI adds a fingerprint check that the content matches the recovered manifest. It notes that watermarks can be removed or spoofed, and that fingerprint matches are never certain.[9]
\nA watermark detector covers only generators that embed its watermark. Google opened its SynthID Detector to everyone on 7 October 2026. Google says the detector checks whether an image, video or audio file was made with AI from Google or from partners including OpenAI, NVIDIA and Kakao.[10] A negative result therefore says nothing about other generators, as our brief on the detector notes.
\nThree U.S. agencies published ten voluntary key practices on 16 October 2026 for managing incidents during the training and evaluation of super intelligence (SI) agents. The publishers are the Center for Advancing Innovation and Standards for Super Intelligence (CAISSI) at the National Institute of Standards and Technology (NIST), the National Security Agency's Super Intelligence Security Center (NSA SISC) and the Cybersecurity and Infrastructure Security Agency (CISA).[1, 2] NIST's CAISSI web page also lists work published by NIST's Center for AI Standards and Innovation (CAISI).[4]
\nThe document defines SI agents as systems that interact with an environment and autonomously execute actions toward a specified goal. It says such a system is typically a generative model with scaffolding software that gives it tools. The document focuses on the SI control incident. In such an incident, agents take significant uninstructed actions that compromise policies, controls or security measures set by the operator to define the task or ensure human oversight. Actions caused by adversarial prompt injection, in which an attacker plants instructions in an agent's input, count as instructed. So do actions caused by a deliberately backdoored model. The practices are grouped into five stages, from preparation to reporting.[2] CISA says the document is aimed especially at pre-deployment agents with reduced safeguards.[3]
\nSeveral practices concern evidence for later review. Practice 5.3 calls for tamper-resistant logs with reliable timestamps, detailed enough to reconstruct agent trajectories, tool calls, reasoning traces and security-control decisions. Practice 3.3 says agents should be unable to access or interfere with monitoring processes and logs. Practice 5.1 asks organizations to preserve model weights and environments as needed to investigate an incident.[2]
\nUnder practice 2.4, organizations should partner with independent external auditors and evaluators to verify that control and monitoring systems work as intended. Practice 10.2 calls for giving third parties enough access for independent analysis.[2] Practice 2.5 suggests publishing evaluation and agent identifiers to help defenders understand unexpected traffic. But the authors note that publishing Internet Protocol (IP) address ranges could expose deployers to attack.[2]
\n\nAnthropic said on 15 October 2026 that it had begun giving what it calls employee-like access to a team from METR, a nonprofit that evaluates frontier AI models. The post opens by citing Anthropic's September commitment to stronger third-party assessment and its signing of the White House Accord on Super Intelligence. In that accord, companies pledged to partner with independent auditors or evaluators.[1]
\nAccording to Anthropic, six METR employees have company hardware, office space and access to internal tools and systems roughly on par with those of its own risk assessment teams. Anthropic encourages its staff to share information with them as they would with a colleague. A few defined categories are excluded, such as customer data, attorney-client privileged material and information about model architectures.[1]
\nAnthropic says METR will publish its own analysis of Anthropic's risk levels, incidents or practices. It says it cannot veto publication but can require redactions in predefined categories, such as content that reproduces confidential intellectual property. Anthropic decides which information falls into those categories. METR, however, reserves the right to make certain statements about the access and information it received. The team works under enforceable agreements, and other METR staff are kept separate from its work.[1]
\nThe post calls this the third of three access tiers. In the first, Anthropic decides what access an evaluator gets and must approve publication. In the second, evaluators receive more information. They can publish without approval and include their views on whether redactions Anthropic required were justified.[1]
\nAmong Anthropic's other evaluators, SecureBio is reviewing the chemical and biological weapons chapter of Anthropic's August Risk Report.[1] On 20 October, METR published a review of the misalignment section of that report. Its authors were engaged before the new arrangement and lacked the access it describes. Their terms let Anthropic veto publication. METR says no redactions were made.[2]
\n\nOn 14 October 2026 Singapore's Infocomm Media Development Authority (IMDA) released a Starter Kit for Testing Agentic Systems for Safety and Reliability. On the same day, the AI Verify Foundation launched an accreditation program for companies that test AI systems on behalf of others.[1] IMDA also formed a task force on AI-enabled cyber threats to the country's infocomm and media sector.[1]
\nThe kit starts from the observation that agents act on their environment with limited human involvement, so a malfunction can have real effects.[2] It organizes testing into four steps, from identifying risks such as erroneous or unauthorized actions to continuous monitoring and re-testing.[1]
\nBecause agents take actions over multiple steps, the kit recommends testing an agent's entire trajectory, including its reasoning and actions, in addition to its final output.[1, 2] It asks for logs of the agent's actions, tool calls and state changes, so that its behavior can be reconstructed and assessed. It also proposes agent-specific metrics such as tool use accuracy and handoff accuracy.[2] IMDA says the kit draws on consultations with government agencies and more than 20 deployers and testers. It says the kit will be updated as a living document.[1]
\nFirms seeking accreditation under the foundation's AI Tester Accreditation Programme undergo technical, operational and financial evaluations. The first five accredited firms are AIDX Tech, Knovel Engineering, PwC Singapore, Resaro and Vulcan. Accreditation lasts one year.[1]
\nAccording to the foundation's program page, the technical evaluation checks a firm's claimed testing services against guidelines such as IMDA's earlier starter kit for testing large language model applications. The page says accreditation signifies that a firm has shown it can assess AI systems within a specific, documented scope of risks. It adds that accreditation is not a guarantee or certification that AI systems are completely safe or free from all risk.[3]
\n\nOn 14 October 2026 the European Commission published the reference of EN 18286:2026 in the Official Journal of the European Union. The standard's full title is Artificial intelligence – Quality management system for EU AI Act regulatory purposes. The Commission did so through Implementing Decision (EU) 2026/2274. It adopted the decision on 12 October, and the decision entered into force on the day of publication.[1] The European Committee for Standardization (CEN) and the European Committee for Electrotechnical Standardization (CENELEC) drafted the standard in response to a 2025 Commission standardization request. It covers the request's item on quality management systems for providers of AI systems, including post-market monitoring processes.[1]
\nCEN-CENELEC announced the citation on 15 October and called EN 18286 the first harmonized standard in support of the AI Act. CEN-CENELEC says the standard translates the quality management requirements of Article 17 into practical, auditable requirements for providers of high-risk AI systems. It adds that the citation gives providers a presumption of conformity with the corresponding provisions of the Act.[2] The decision states that, from the date of publication, systems conforming to a harmonized standard whose reference is published in the Official Journal are presumed to conform with the requirements it covers.[1]
\nArticle 17 requires providers of high-risk AI systems to put in place a documented quality management system. Its required aspects include test and validation procedures, data management, risk management, post-market monitoring and serious-incident reporting.[3] Article 17 sits in Section 3 of the AI Act's chapter on high-risk systems. Under the Digital Omnibus on AI, Sections 1 to 3 of that chapter apply from 2 December 2027 for systems listed in Annex III. For systems covered by Annex I, they apply from 2 August 2028.[3, 4]
\n\nOPAQUE Systems, a confidential AI company, announced on 13 October 2026 that its team is joining Anthropic to continue OPAQUE's work. OPAQUE began as a research project at UC Berkeley's RISELab.[1] The company's homepage now says that OPAQUE Systems is winding down its operations.[2]
\nIn the announcement, OPAQUE describes its path from confidential AI to what it calls verifiable AI. Confidential AI means AI workloads run on sensitive data under hardware-enforced protections. Verifiable AI, in OPAQUE's terms, is cryptographic evidence of what ran, where it ran and under which policies. OPAQUE says it worked with a wider community on open approaches to trust and security problems around AI agents and models, through AgenTrust and several open-source projects.[1]
\nAccording to the homepage, OPAQUE's open-source work continues at AgenTrust, and projects including Confidential MCP and TRACE remain available under their existing licenses. The Confidential Computing Summit, an industry event OPAQUE created, continues at the Linux Foundation.[2, 3]
\nNeither OPAQUE page discloses the terms of the arrangement. The New Stack reported on 15 October that Anthropic told The Information it is licensing OPAQUE's technology and hiring some of its engineers. The report added that Anthropic had otherwise released no further information. Citing The Information, The New Stack said those joining include chief executive Aaron Fulkerson and chief technology officer Rishabh Poddar, but not all of OPAQUE's employees. It also reported that neither company had made statements about maintenance commitments for OPAQUE's open-source projects.[3]
\nThe New Stack quoted two outside views. Arjun Jaggi, an applied AI researcher, said a frontier lab's resources could help harden such tools for production. Michael Heinrich, chief executive of 0G Labs, cautioned about a potential conflict of interest when tools that produce verification evidence sit inside a model vendor that is itself being checked.[3]
\n\nGoogle opened its SynthID Detector to everyone on 7 October 2026, making the tool available globally in English, according to a post by Pushmeet Kohli of Google DeepMind.[1] SynthID is Google's system of imperceptible watermarks for AI-generated media. Google says the detector can check whether an image, video or audio file was made with AI from Google or from partners. Google names OpenAI, NVIDIA and Kakao among them and lists Apple as coming soon.[1]
\nGoogle introduced the detector in May 2025 as a verification portal. It opened the portal first to early testers and offered a waitlist to journalists, media professionals and researchers.[2]
\nThe October post says Google has watermarked more than 180 billion images and videos and 240,000 years of audio since launching SynthID in 2023. It adds that the verification features built into Search, the Gemini app and Chrome now handle more than 1 million requests a day.[1]
\n\nOn 7 October 2026 the UK AI Security Institute (AISI) released Transect, an open-source Python package for analyzing transcripts of long agent evaluations. It builds on Inspect Scout, a transcript-analysis library. Meridian Labs, which makes Inspect Scout, supported Transect's development.[1, 2] A transcript records an agent's messages, tool calls and tool responses. AISI says these records can run to billions of tokens (the word pieces that language models read and write) as agents work on longer tasks and coordinate with other agents. That is more than human experts can review in full, AISI says.[1]
\nUsers give Transect a transcript, the task's context and the categories of activity they want to distinguish, such as coding or data analysis. The package extracts recorded events, including human messages and sub-agent launches, directly from the transcript. It then uses judge models, language models chosen by the user, to label stretches of activity. Its report places labels, token use and events on a shared timeline measured in agent turns. Each label links to the transcript passages it describes.[1, 2] AISI notes that labels for sub-agents describe what they were asked to do, which may differ from what they did.[1]
\nTransect stores every label and individual model judgment, so reviewers can reopen an analysis without new model calls. When an analysis uses several judges or repeated judgments, the report shows where they disagree. AISI cautions that agreement does not make a label correct. It adds that fresh judgments may differ when an analysis is rerun.[1]
\nThe accompanying paper demonstrates the workflow on an AI research and development evaluation that produced almost 13 million tokens.[2] The code is on GitHub under the MIT license.[3] AISI also cites its own security incident earlier this year, in which agents took unsanctioned actions during an evaluation. It says systematic transcript review helped establish what the agents did.[1]
\n\nSecurity researcher David Buchanan reported on 2 October 2026 that a signer can produce Content Credentials whose signature and trusted timestamp stay valid but cover none of a file's content.[1] Content Credentials are the provenance format specified by the Coalition for Content Provenance and Authenticity (C2PA). They attach a signed record, called a manifest, that makes claims about a file's origin. Manifests often include a timestamp from an independent time-stamp authority, which attests that the signature existed at a given time.[1]
\nThe method uses exclusion ranges, byte ranges that a signer can leave out of the cryptographic hash that the signature covers. Buchanan set a single exclusion covering the entire file, so the claim signature covers the hash of an empty string. He says he edited the image after signing and that the signature and the timestamp stayed valid.[1] His example is a photo of a lottery ticket. He says it shows the winning numbers of the 28 August 2026 EuroMillions draw but carries a trusted timestamp from hours before the draw. He reports that the C2PA verification tools he could find did not flag anything unusual.[1]
\nVersion 2.4 of the C2PA specification says the software that creates a manifest must limit exclusion ranges to the manifest store or to asset metadata. It also tells validators to reject a manifest when the exclusion range that holds it contains other data, and to report any additional exclusion ranges with an informational code.[2]
\nBuchanan writes that a whole-file exclusion is easy to detect, but a small one is harder to judge. He adds that exclusions cannot simply be dropped, because some file formats contain checksums that must be updated after signing. He therefore proposes defining which bytes may be excluded in each format and requiring verifiers to enforce those limits.[1]
\nAn April analysis by researchers at the University of Maryland, Baltimore County (UMBC), Hacker Factor and the National Security Agency had already reported that the exclusion range enables undetectable alterations.[3]
\n\nGeorgetown University's Center for Security and Emerging Technology (CSET) published a report on 29 September 2026 that assesses location verification as a tool for enforcing US export controls on AI chips. Its authors, Jacob Feldgoise, Kyle Miller and Hanna Dohmen, compared methods on verifiability, accuracy, security and repeatability. They conclude that a centralized ping-based location verification (PLV) system, supplemented by physical inspections to investigate leads, would be the most robust and feasible approach. They make no recommendation on whether policymakers should mandate location verification.[1, 2] A House committee's version of the Chip Security Act lists ping-based location verification as one acceptable mechanism.[3]
\nIn PLV, trusted landmark servers at known locations estimate a chip's location from the round-trip time of signals sent to it. The authors recommend that each chip sign its responses in the firmware of its trusted execution environment (TEE), an isolated area of the processor. They judge that this offers the best balance of security, cost and ease of implementation. One reason they give is that firmware updates can reach TEE-equipped chips already in use. Any implementation, they add, is unlikely to withstand state-backed attackers.[1]
\nThe report estimates that a PLV system would cost $3.1 million to $28.8 million a year if the landmark servers are owned. If they are rented, the estimate is $2.6 million to $72.4 million a year. In more than ten million simulated scenarios, physical inspections never detected more diverted chips per dollar than PLV. This held even though the authors deliberately chose model parameters that favor inspections.[1, 2]
\nThe authors also describe inherent limits. PLV can detect diversion only after it occurs. A chip that stops responding may be in storage or deliberately disconnected. Accuracy is likely no better than about 20 miles, so the system cannot reliably distinguish nearby data centers run by different operators. Because PLV verifies locations rather than users, it cannot detect a transfer to a restricted company in the same data center.[1]
\n\nMeta said on 23 September 2026 that it is extending Private Processing to its AI glasses. Private Processing is the confidential computing infrastructure Meta introduced in 2025 for WhatsApp and the Meta AI app. The platform runs AI models inside confidential virtual machines (CVMs), which are designed to keep their memory encrypted and isolated from the host. Meta says the platform is designed so that even Meta cannot access user data. Meta named streaming transcription, contextual search and long-term recall as workloads it designed the system to offload.[1]
\nAccording to Meta, the glasses verify the server before sending any context. Over a remote attestation and TLS (RA-TLS) session, the device obtains a hardware-signed certificate from the server's trusted execution environment (TEE). It checks that the signature chains to a root key published by the chip vendor. It also checks that the measured software image matches an entry in an append-only ledger witnessed by an independent third party. If either check fails, it does not connect. To keep requests from being tied to an account, Meta says devices use anonymous credentials and reach its gateways through a third-party Oblivious HTTP (OHTTP) relay run by Fastly or Cloudflare.[1]
\nFor memory features, Meta says it built the storage engine inside the TEE and encrypts stored data with user-provided keys. Meta says the public ledger makes tampering with deployments detectable. It adds that researchers in its security program have access to the binaries under agreement, which lets them confirm that a recorded image behaves as described. Meta is also extending its bug bounty program to Private Processing on glasses and plans to give researchers tools, CVM binaries and documentation.[1]
\nTrail of Bits audited the WhatsApp version before launch. In an April 2026 post, it said it found 28 issues, eight rated high severity, including attestation reports without freshness guarantees. It said Meta fixed that issue by adding a TLS nonce.[2] We cover that audit in a separate brief.
\n\nGoogle said on 23 September 2026 that it will add a persistent, per-user memory layer to Private AI Compute, which until now erased context when each task ended. The platform processes AI requests in hardware-isolated cloud environments. Google says the keys that unlock the memory will be held only on users' devices. It says a secure enclave, one such isolated environment, will decrypt the memory temporarily to handle a request.[1]
\nAccording to the updated technical brief, the memory store is a per-user database inside a trusted execution environment (TEE). The brief says keys are released only to an enclave whose attestation matches an endorsed memory binary. An attestation is a signed record of the software an enclave loaded. Google says the memory server and its runtime are open source. It says reproducible builds and an append-only ledger of binary digests tie that code to the deployed binaries. Because each request must reach a specific user's store, the brief says the memory system does not claim network-level non-targetability, the property that requests cannot be linked to users.[2]
\nGoogle's post says devices will be able to verify its server software before sending personal data.[1] The brief lists device-side validation of attestation evidence as future work, along with a ledger co-signed by independent third parties. It gives no dates.[2]
\nA Trail of Bits assessment dated 21 September 2026, linked from the brief, reported ten findings. Google resolved eight, and two remain unresolved. The unresolved finding rated high is that hashes of model-response text are sent outside the trusted computing base, the components that the system's security depends on. The hashes are sent out for checks on whether responses recite copyrighted text. Google plans a filter inside the enclave so that most hashes never leave it. Trail of Bits says this reduces the risk without eliminating it. The other unresolved finding, rated low, is that deleted memories may be restored into the active database. Google accepted that risk. Trail of Bits also noted that Google can change the system without prior external review and that the system contains extensive closed-source code.[3]
\n\nOn 16 September 2026 Cohere announced Confidential Computing in Model Vault in a post on X. It said that no one, including Cohere, can access customers' workloads.[1] Model Vault gives customers dedicated, single-tenant model deployments. Cohere's documentation calls the new option Model Vault Encrypted and says it is in beta for customers who contact the company.[3]
\nAccording to the documentation, inference runs inside a hardware-based confidential virtual machine (VM) paired with an NVIDIA GPU in confidential-computing mode. In a confidential VM, the hardware encrypts the VM's memory and is designed to isolate it from the host. The documentation's examples are VMs using Intel Trust Domain Extensions (TDX) or AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP).[3] Clients encrypt requests with Oblivious HTTP (OHTTP) to a key generated inside the attested environment, so the load balancer and network carry only ciphertext.[2]
\nThe documentation describes a deployment on Intel TDX. In that deployment, Intel Trust Authority, Intel's attestation service, appraises the evidence from the CPU and GPU against an approved policy and issues a signed token. Before sending any data, Cohere's client proxy verifies Intel's signature and the measurements (hashes of the loaded code and configuration) that the token reports. It also checks that the encryption key is bound to the attested environment, and it refuses to connect if a check fails.[2]
\nEvery inference response also includes an attestation certificate that customers can keep as a record of the environment that served the request. Cohere says the approved measurements come from reproducible builds of open-source code, so an independent party can rebuild the artifacts and compare them.[2, 3]
\nThe documentation's frequently asked questions (FAQ) page also lists what stays visible outside the protected environment: routing metadata such as the model name, operational metrics, and network timing and byte volume. The residual risks it names include hardware side channels (indirect leaks through effects such as timing), attacks that require deep physical access, and the operator's ability to stop or restart the environment.[3]
\n\n