verifiable.pro

The verification stack and trust tiers

Seven layers show where a claim about an AI system sits, from the chip up to the laws, standards and agreements that govern the system. Five trust tiers show what a passing check of that claim rests on, with trusted execution environments as the reference point.

Seven layers of checkable claims

Each layer names a kind of claim that someone outside the provider can check, from the chip at T1 up to the laws, standards and agreements at T7. Each row also says who can check it. Layers are positions, not security levels: a higher layer is not safer, and it builds on the layers below without containing them. Checking can continue upward only while each layer's evidence is bound to the layer below it. TEEs give direct evidence at T1 and T2 and reach the other layers only through the code they measure.

  1. T7

    Policy

    Checkable claimDevelopers and governments keep the commitments they make about training, deployment and compute.

    Who checksRegulators and inspectors can check commitments, mostly through audits and site visits.

    With a TEEOnly through measured codeUnder a proposal, chips would sign location-check answers with a key in TEE firmware.

    Bound to the layer belowMissingCommitments and rules rarely name the audit results or attested evidence they rely on, though there are proposals to do so for compute agreements.

    What a TEE shows here and other evidence

    With a TEE: For proposed location checks on export-controlled chips, CSET recommends that each chip sign its answers with a key in its TEE firmware. This shows where a chip answers from. It does not show who uses the chip or whether a commitment was kept.

    Other evidence: Audits (inspections, conformity assessment, evaluator requirements)

    Newest: · European Commission Cites EN 18286 as a Harmonized Standard Under the AI Act

    Governance & compute verification

    11 stories · 1 about TEEs

  2. T6

    Evaluations & audits

    Checkable claimA reported result came from the stated model, tests and conditions.

    Who checksIndependent evaluators given access to the model can rerun the tests or check the test logs.

    With a TEEOnly through measured codeAn evaluation run in a TEE shows which model and test code were loaded.

    Bound to the layer belowEmergingEvaluations run inside TEEs, or auditors check logs that are bound to attested environments.

    What a TEE shows here and other evidence

    With a TEE: When an evaluation runs inside a TEE, the attestation report shows which model, test set and evaluation code were loaded. The weights and test items can also stay confidential. The report does not show that the benchmark measures what matters.

    Other evidence: Audits (structured access, accredited testing) · Re-execution (rerunning an evaluation) · Proofs (zero-knowledge evaluation proofs)

    Newest: · Anthropic Says It Has Given Six METR Evaluators Employee-Like Access

    Verifiable evaluation & auditsFormal verification

    12 stories · 1 about TEEs

  3. T5

    Agents & actions

    Checkable claimAn agent took these actions, under this policy, on behalf of this person or organization.

    Who checksServices an agent calls can check its signed requests; reviewers can later check its log.

    With a TEEOnly through measured codeShows which guardrail code was loaded, but not that it works.

    Bound to the layer belowEmergingEach action is recorded in a tamper-evident log, together with the signed output that triggered it.

    What a TEE shows here and other evidence

    With a TEE: An attested agent runtime can show which guardrail or policy code was loaded before the agent acted. It does not show that the guardrail works or who authorized the agent.

    Other evidence: Signatures (signed requests and mandates, tamper-evident logs) · Audits (incident reviews)

    Newest: · NIST, NSA and CISA Publish Incident Practices That Call for Tamper-Resistant Agent Logs

    Agent identity & accountability

    7 stories

  4. T4

    Outputs & content

    Checkable claimThis output came from this model and input, and this media has this origin.

    Who checksReaders and platforms can check a response's signature or an image's Content Credential.

    With a TEEOnly through measured codeCan tie a response to the software that produced it, but cannot show that it is correct.

    Bound to the layer belowEmergingResponses are signed with a key that exists only inside the attested environment.

    What a TEE shows here and other evidence

    With a TEE: When the session is bound to the attestation report, a response can be tied to the software that produced it. If that software measured the weights, the response can be tied to them too. The report does not show that the output is correct.

    Other evidence: Proofs (zero-knowledge proofs of inference) · Re-execution (activation fingerprints, refereed delegation, sampled audits) · Signatures (Content Credentials, watermarks)

    Newest: · Google Opens Its SynthID Watermark Detector to the Public

    Verifiable inference & computationContent provenance & watermarking

    15 stories · 2 about TEEs

  5. T3

    Models & data

    Checkable claimThese are the weights that were trained, signed and deployed, with this lineage.

    Who checksDevelopers and auditors can check a model's signature, or compare its hash with the published one.

    With a TEEOnly through measured codeWeights count only if measured code checks them. Attestation can be a condition for releasing their keys.

    Bound to the layer belowEmergingThe attested software records a hash of the weights it loads, so the report can name the exact model.

    What a TEE shows here and other evidence

    With a TEE: Weights loaded after launch are covered only if measured code checks them, for example against a published hash. A key server can also release the key that decrypts the weights only to an environment whose attestation meets its policy.

    Other evidence: Signatures (model signing, build provenance, AI bills of materials) · Proofs (weight commitments, proofs of training data) · Audits (dataset audits)

    Newest: · CISA and G7 Partners Publish Minimum Elements for AI Software Bills of Materials

    Model & data supply chainGovernance & compute verification

    4 stories

  6. T2

    Software & runtime

    Checkable claimThis exact code and configuration processed the request.

    Who checksYour device can compare attested measurements with published values before it sends a request.

    With a TEEDirect evidenceLaunch measurements identify the code and configuration that were loaded.

    Bound to the layer belowIn useAt launch the chip measures the software it loads and signs those measurements in its attestation report.

    What a TEE shows here and other evidence

    With a TEE: Measurements taken at launch identify the software that was loaded. A verifier compares them with published reference values. Inputs loaded later count only if measured code checks them. A match identifies the software but does not show that it behaves correctly.

    Other evidence: Signatures (signed builds, logged releases) · Proofs (formal verification of code)

    Newest: · OPAQUE Says Its Team Is Joining Anthropic as the Company Winds Down

    Confidential computing & attestationFormal verification

    10 stories · 10 about TEEs

  7. T1

    Hardware & compute

    Checkable claimThe computation ran on genuine hardware in a protected mode.

    Who checksYour device can check the attestation report's signature before it sends a request.

    With a TEEDirect evidenceA report whose key chains to the chip vendor shows genuine hardware in a protected mode.

    What a TEE shows here and other evidence

    With a TEE: A report signed with a key that chains to the chip vendor shows that genuine hardware launched the measured software in a protected mode, at stated firmware versions. Whether the mode keeps the host out depends on the vendor's design. You trust that design within the vendor's threat model, which leaves out some physical and side-channel attacks.

    Other evidence: Audits (data-center and chip inspections)

    Newest: · OPAQUE Says Its Team Is Joining Anthropic as the Company Winds Down

    Confidential computing & attestationGovernance & compute verification

    13 stories · 11 about TEEs

The line through the codes is the evidence chain: solid where a binding to the layer below is in use, dashed where one is emerging, broken where none exists yet. Where the chain breaks, checking stops.

T1–T7 name the stack layer of the claim each story reports. A layer is a position, not a security level. The layers are this site's own scheme, not an industry standard. The TEE tag marks stories about trusted execution environments.

How other approaches compare with TEEs

The tiers are ordered by what a passing check rests on: first a party's statement, then hardware evidence, then recomputation and proof. The order shows where the trust sits; it is not a ranking. Each tier checks a different, narrower claim. Costs differ too, and they do not follow the order. Of these approaches, only a TEE is designed to keep prompts and weights from the operator while they are processed. Deployed services often combine tiers.

Baseline, not a check

The provider's word

Model cards, privacy policies and a service's description of itself, including the words "attested", "private" or "verified". Such a statement tells you what the provider says. An outsider can compare it with evidence, but the statement on its own cannot be checked. We report it as the provider's claim.

Tier 1 · The signer and its keys

Signatures and logs

A passing check establishes
A known key signed these exact bytes, and they have not changed since. A transparency log adds a public record of the signing, so anyone who monitors the log can notice a quiet replacement.
It does not establish
How the artifact was produced, or whether what the signer asserts is true. A signed model can still misbehave. A credential records what its signer claims. A missing watermark shows nothing.
What stays hidden, cost and how it compares
You trust
The signer's honesty and key custody, the certificate authority or identity provider that names signers, and whoever monitors the log. For watermarks, the party that embeds them and the detector's error rates.
Hidden from the operator
Nothing: signatures and logs are public by design.
Cost and maturity
Cheap per artifact and in production use. Sigstore's model-signing library reached version 1.0 in April 2025. Researchers report that C2PA falls short of its stated security goals. Another researcher says that exclusion ranges (parts of a file that the signature leaves out) let a malicious signer backdate an edited image.
Compared with a TEE
A TEE's attestation report is also a signature, but the hardware issues it about software it measured. In this tier, a person or organization decides what to state. Signatures also complement a TEE: a transparency log of software releases lets a verifier compare the measurements in a report with the logged releases.
Combined with a TEE
Apple's Private Cloud Compute pairs attestation with an append-only log of software releases.

Includes: Model signing (Sigstore, OpenSSF Model Signing), build provenance and AI bills of materials, transparency logs, C2PA Content Credentials, signed agent requests and mandates, and tamper-evident logs. Watermark detection sits beside this tier: a watermark is an embedded statistical signal, not a signature.

Further reading

Tier 2 · The examiner and the access it had

Audits and evaluations

A passing check establishes
What a named examiner observed about a system, with the access it was given, at a point in time. Audits reach claims that no hardware report or proof describes, such as whether a developer follows its own safety practices.
It does not establish
That the system serving users is the one examined, or anything outside the examination's scope.
What stays hidden, cost and how it compares
You trust
The examiner's competence and independence, the depth of access the developer granted, and the honesty of the report.
Hidden from the operator
The examiner sees what the developer shares, usually under confidentiality; the public sees the report.
Cost and maturity
Each engagement takes expert time, and access is negotiated case by case, so audits cannot cover every request. Accreditation, assurance levels and requirements for evaluators are still being defined.
Compared with a TEE
The evidence rests on people's judgment rather than on a report a client can check for each request. A TEE can deepen an audit: evaluators can test a confidential model inside a TEE, and its attestation report shows which model and test code were loaded.
Combined with a TEE
Google DeepMind's double-blind pilot ran an evaluation inside Google Cloud's Confidential Space. Its report notes that not all inference code could be inspected and that the setup still trusted Google.

Includes: Third-party audits and evaluations with black-box, white-box or outside-the-box access, accredited testing and graded assurance levels, conformity assessment against standards, data-center and chip inspections, and reviews of agent incidents.

Further reading

Main subject

Tier 3 · The chip vendor and the measured software

Hardware attestation with TEEs

A passing check establishes
Genuine hardware launched software with the stated measurements in a protected mode, at stated firmware versions. A random value from the verifier, called a nonce, shows that the report is fresh. Only a report that commits to the session key shows that this connection ends inside the attested environment.
It does not establish
That the measured software behaves correctly. Inputs loaded after launch count only if measured code checks them. The report also does not show that the protected mode keeps the host and the cloud operator out. That is a property of the vendor's design.
What stays hidden, cost and how it compares
You trust
The chip vendor's design, firmware and keys; whoever publishes the reference values, and the verifier that compares against them; and the measured software. Isolation holds only within the vendor's threat model. That model leaves out some physical attacks, such as the DDRop memory interposer, and does not cover all side channels. The operator can still stop or restart the environment.
Hidden from the operator
Prompts and weights, within the vendor's threat model. Of the approaches compared here, this is the only one designed to keep them from the operator while a large model runs.
Cost and maturity
Commercial CPUs and GPUs in the major clouds, used by deployed AI services. One preprint measured about 1% to 3% throughput overhead for tuned serving on NVIDIA B200 GPUs, and 30% to 40% with default inference software. Published audits have found inputs left out of the measurement and reports that could be replayed.
Why this is our main subject
AI services already rely on this tier, so its limits affect readers now. Its evidence is also easy to overstate: a valid report identifies the software without vouching for it.

Includes: Confidential VMs on Intel TDX, AMD SEV-SNP and Arm CCA; NVIDIA Hopper and Blackwell GPUs in confidential-computing mode; remote attestation in the IETF RATS roles; attestation-gated key release; and AI services that publish attestation evidence, such as Apple Private Cloud Compute, Meta Private Processing, Google Private AI Compute and Cohere Model Vault Encrypted.

Further reading

TEE hub

Tier 4 · An honest checker

Re-execution

A passing check establishes
A rerun of the checked requests, or of a sample, matched the provider's output, exactly or within a stated tolerance. With refereed delegation, which sends the same job to several providers, the client gets the correct result if at least one provider is honest.
It does not establish
Anything about requests nobody checks, including rare cheating that sampling misses, or whether the model is any good.
What stays hidden, cost and how it compares
You trust
That a checker holding the model actually runs the check; that the provider cannot single out audit requests; and that the tolerance does not let a cheaper model pass. Optimistic schemes, which accept a result unless someone challenges it, also need a challenger who acts within the dispute window.
Hidden from the operator
Nothing by default: the checker sees the prompt and the weights, unless the re-execution itself runs inside a TEE.
Cost and maturity
At least one more run of whatever is checked. On top of the duplicate run, Verde's authors report 58% to 98% inference overhead for its reproducible operations, relative to PyTorch on A100 GPUs. Sampling schemes report under 1% throughput overhead. Mostly research protocols, with one deployment reported live (EigenAI, January 2026).
Compared with a TEE
Re-execution replaces trust in a chip vendor with trust in an honest checker, but nothing stays confidential. It can check which model produced an output, a question a TEE leaves to the software it measures.
Combined with a TEE
EigenAI re-executes challenged requests inside TEEs, so it relies on both sets of assumptions. Someone must challenge within the dispute window, and verifiers holding at least two-thirds of the stake must behave honestly. The enclave hardware must also be trusted.

Includes: Full re-execution, activation fingerprints (TOPLOC), refereed delegation (Verde), sampled audits (IMMACULATE), optimistic schemes with a dispute window (EigenAI), and statistical tests of model identity.

Further reading

Tier 5 · The proof system and the statement proven

Proofs (zero-knowledge and formal)

A passing check establishes
A zero-knowledge proof shows that the proven computation turns an input and committed weights into a given output. Committed weights are weights the prover fixed in advance, and the proof does not reveal them to the verifier. A formal proof shows that a stated property holds for every input within its specification.
It does not establish
A proof covers its statement and nothing more. The proven computation is often an integer version of the model with greedy decoding, in which the model always picks the most likely next token. Committed weights are the advertised model only if something else ties them together. The Hollow-LLM paper describes committed weights that keep proofs valid while most of the declared model's computation is never performed. (The editor co-authored that paper.)
What stays hidden, cost and how it compares
You trust
The soundness of the proof system and of any trusted setup, the proof checker, and a circuit or specification that matches the system in use.
Hidden from the operator
The weights, from the verifier. The prover still sees the prompt.
Cost and maturity
Proving costs orders of magnitude more than inference. zkLLM took 803 seconds to prove one inference of a 13-billion-parameter model. DeepProve reports 174 proven tokens per minute for GPT-2 and 86 for Gemma 3. These are research systems. Neural-network verifiers prove properties such as robustness over a region of inputs. Proof assistants such as Lean now check AI-generated proofs of major theorems.
Compared with a TEE
For integrity, proofs remove the need to trust hardware. But they keep nothing from the provider, prove a narrower statement and cost far more. Formal verification can also complement a TEE: attestation shows which code was loaded, and a proof about that code can show that it meets its specification.

Includes: Zero-knowledge proofs of inference and evaluation (zkLLM, DeepProve, Jolt Atlas), proofs against committed weights and proofs of training data; formal verification of neural networks (α,β-CROWN) and of code, and proof assistants such as Lean.

Further reading

Homomorphic encryption and multiparty computation also hide data while it is processed, but they are not checks in themselves.

Why TEEs are our reference point

Tiers combined in practice

  • Apple Private Cloud Compute: attestation plus a public log

    Trust tiers: TEE + Signatures

    Devices send requests only to nodes whose attested measurements match a release in an append-only log. Apple publishes the images for researchers. The attestation still rests on the hardware and Apple's keys. Outside researchers are left to examine what a logged build does.

  • EigenAI: re-execution inside TEEs

    Trust tiers: Re-execution + TEE

    A committee re-executes challenged requests inside TEEs, and the results must match byte for byte. The design still needs someone to challenge within the dispute window and verifiers holding two-thirds of the stake to behave honestly. It also relies on the enclave hardware.

  • Double-blind evaluation: an audit inside a TEE

    Trust tiers: Audits + TEE

    Evaluators tested a Gemini model in Google Cloud's Confidential Space. The setup was designed to keep the weights from the evaluators and the test prompts from Google. The report notes that not all inference code could be inspected and that the setup still trusted Google.

Topics

  1. Confidential computing & attestation Main subject

    Hardware isolation designed to protect AI workloads while they run, paired with remote attestation, which reports the software loaded to handle prompts, data and model weights.

    Trust tiers: TEE

    15 articles · 27 resources

  2. Verifiable inference & computation

    Cryptographic proofs and re-execution protocols for checking that an output, or a set of trained weights, came from the claimed model and computation.

    Trust tiers: Re-execution, Proofs

    6 articles · 24 resources

  3. Formal verification

    Machine-checked proofs that a neural network, a program or AI-generated code satisfies a precise specification for every input in its scope.

    Trust tiers: Proofs

    3 articles · 23 resources

  4. Verifiable evaluation & audits

    Ways to bind a reported benchmark score or audit finding to the model, test set and code that produced it.

    Trust tiers: Audits

    12 articles · 26 resources

  5. Model & data supply chain

    Signatures, build provenance and bills of materials that let a user check who produced a model or dataset, from which inputs, and whether it changed after release.

    Trust tiers: Signatures

    5 articles · 25 resources

  6. Content provenance & watermarking

    Signed metadata and embedded watermarks that record where media came from and whether AI generated or edited it.

    Trust tiers: Signatures

    10 articles · 22 resources

  7. Agent identity & accountability

    Evidence of which agent acted, for whom and under what authority, kept in records that cannot be quietly rewritten.

    Trust tiers: Signatures, Audits

    9 articles · 19 resources

  8. Governance & compute verification

    Checking whether commitments, rules and agreements about AI are kept, including claims about chips and training runs.

    Trust tiers: Audits, TEE

    7 articles · 20 resources