How the protocol works step by step
The process starts with a shared policy that names the permitted code, drivers, machine image and hardware. Those components are converted into verifiable measurements. Neither party releases its secret yet: the model provider and evaluator first demand evidence that the agreed environment is genuinely running.
Only after remote attestation does each side release the key for its encrypted asset. Model weights, inference code and confidential questions coexist solely inside the enclave. What leaves is a pre-defined artifact—such as an aggregate report—rather than raw prompts, responses or model parameters.
Where trust actually moves
“Double blind” does not make trust disappear. It moves trust from the relationship between organisations into a trusted computing base: processor, GPU, firmware, attestation mechanism, machine image and evaluation code. A flaw in any of those layers can weaken privacy or result integrity.
Reproducible builds and review scope matter too. If a proprietary component is supplied only as a binary, the evaluator may confirm that the same artifact ran without understanding every effect it can have. Technical isolation therefore belongs alongside code review, access control and explicit legal accountability.
Seven layers of a secure evaluation
A simplified pilot flow: both parties verify the environment before their protected assets are released.
- 01Define policy
Agree permitted code, hardware and output.
- 02Reproducible build
Components receive verifiable measurements.
- 03Launch enclave
GPU and host start in the approved state.
- 04Remote attestation
Each party checks the environment.
- 05Release model
Weights remain hidden from the evaluator.
- 06Release benchmark
Questions remain hidden from the provider.
- 07Controlled result
Only the agreed evaluation artifact leaves.
How to judge the strength of the evidence
Separate three questions: did the benchmark stay secret, did the model stay secret, and does the benchmark measure the right behaviour? An enclave can strongly support the first two, but it cannot repair a poorly designed test, an unrepresentative sample or a metric disconnected from real risk.
A professional report should name the model and benchmark versions, publish the attestation policy, list components covered by review, explain result aggregation and state known limitations. Without that detail, the cryptography may look impressive while the reader still cannot tell what was actually tested.
Where the pattern is most useful
Government evaluation, cybersecurity, health and finance are natural candidates because the test set may itself contain sensitive material. It can also allow an institution to compare closed models when it cannot take custody of their weights or send confidential data to an external API.
A sensible adoption path starts small: one model, one benchmark, a pre-defined report and a failure procedure. Scaling to multiple labs and model versions comes later. The hardest questions may concern approvals, licences, liability for disclosure and a provider’s right to challenge a result rather than compute.
What to watch next
Independent replications on different hardware and cloud providers would make the evidence stronger. Standardised attestation reports also matter, so an agency, auditor or customer can compare two evaluations without reverse-engineering an entire infrastructure stack.
The real maturity test will be a disputed result: a model scores poorly, the provider challenges the benchmark, and the evaluator suspects an environment change. A sound protocol must support independent replay while preserving both parties’ secrets.
What each party does not need to disclose
The arrangement reduces information asymmetry without handing the most sensitive asset to the counterparty.
Receives the controlled result, not the private test set.
Can verify the stack and execution conditions.
Runs the test after successful attestation.
From confidentiality agreements to machine-enforced rules
A confidential benchmark solves one problem and creates another. Keeping questions out of public circulation preserves their value, yet a closed model normally runs on infrastructure controlled by its provider, which can technically see the input. Contracts, zero-logging commitments and organizational controls reduce risk, but they do not give the evaluator independently verifiable proof that questions were neither retained nor used later. The alternative—transferring model weights—moves the largest intellectual-property and dual-use risk to the provider and often prevents the evaluation from happening at all.
Double-Blind Evaluation turns part of that trust negotiation into enforcement of an agreed policy. Each party releases its asset to the enclave only after independently checking its attested state; encrypted transport and hardware memory encryption protect the data in transit and during computation. This is the important shift: confidentiality rests not solely on the counterparty’s promise but on isolated hardware, attestation and a constrained program acting together. Trusted parties do not vanish. The hardware maker, cloud platform and reviewed software remain in the chain, but the scope of that trust can be named, documented and challenged.
Attestation proves what ran, not whether it was good
Remote attestation begins with a hardware root of trust. The processor signs measurements of successive layers in the booted stack, and both participants compare those measurements with the expected values. A fresh nonce prevents an old report being replayed, while an ephemeral key binds the encrypted channel to that particular enclave instance. The evaluator therefore need not take a cloud administrator’s word that the approved image is running: it can verify signatures and hashes before decrypting the benchmark.
That proof has a precise boundary. It supports claims about hardware identity and measured software, not the correctness of every line of code. If the approved program contains a defect, exports data through an available output channel or calculates a metric incorrectly, attestation can faithfully confirm that this flawed program ran. A reproducible build is therefore valuable only alongside source review, an explicit network policy and negative tests demonstrating that an unauthorized output really cannot leave the enclave.
A mock interface separates test preparation from the model secret
The evaluator needs to write its test before it can see the real model. The report uses a mock model interface for this purpose: the provider publishes a compatible input-and-output contract against which evaluation logic can be prepared without exposing weights. Dependencies, data formats and permitted operations are agreed before execution. This reduces last-minute improvisation and exposes compatibility problems before the two sensitive assets ever share an environment.
The harder case arises when inference code or evaluation logic is itself confidential. The authors allow controlled redaction, but a hidden component may call only an allowlist of methods that cannot open a network connection or another route for leakage. That is a pragmatic compromise, not full transparency. The larger the unseen part of a program becomes, the tighter its capabilities must be. A mature review approves not merely a file but its dependencies, privileges and every channel through which information might leave.
The result can become a leakage channel too
Protecting inputs is insufficient if the program can return an arbitrarily rich result. Raw model responses might reproduce parts of a question; detailed logs could reveal evaluation technique; repeated adaptive queries against a score could gradually disclose the structure of the secret set. The pilot therefore uses a pre-agreed, bounded result such as aggregate metrics. A defensible output policy should specify fields, precision, minimum groups and the number of permitted runs, rather than naming a report and leaving its contents open.
Output restriction has a scientific cost. An evaluator given only a total has less material for diagnosing failure, inspecting unusual responses or reproducing an analysis. Tiered access can help: a basic report shared across parties, a richer artifact retained in a controlled repository, and a joint procedure for disclosing a specific case. This makes clear that output privacy is a methodological choice. A policy that is too loose weakens confidentiality; one that is too tight may weaken the independence and explanatory value of the assessment.
What the pilot actually demonstrated
In the reported deployment, Gemini 2.5 Flash Lite ran on a confidential NVIDIA H100 GPU inside a Google Cloud machine whose host memory was protected with Intel TDX. PySyft supplied the coordination layer. A private AILuminate reserve set was used with AVERI and MLCommons; the technical report labels it AIRR 1.0 in one passage and AIRR 1.4 in the experimental setup, so the version should remain unresolved pending an author correction. The Singapore AI Safety Institute supplied a separate set concerned with eliciting harmful content in its local context. After attestation, weights and prompts travelled through encrypted channels into the enclave, and the environment was later decommissioned.
The pilot demonstrates the practical feasibility of mutual confidentiality between a model owner and benchmark owners, but its trusted base was not fully independent of Google. The authors report that not every proprietary method implementation could be inspected or allowlisted, guest operating-system builds were not independently reproducible, and Google services remained in the attestation verification path. It is not a published Gemini safety result or evidence that the protocol fits every model and platform. Stronger evidence would include replication by other laboratories and infrastructure providers.
What cannot be learned without broader access
Not every evaluation is a prompt set followed by one metric. Activation probing, representation steering, token-level likelihood analysis and deterministic offline inspection may require direct access to weights or internal states. The technical report itself notes that such audits are among the reasons evaluators request copies of models. An enclave can broaden the range of feasible external tests, but it should not become a reason to replace every deeper form of access with black-box scoring.
Measurement integrity is also different from validity. A secret benchmark can remain perfectly hidden while measuring behaviour that is narrow, prompt-sensitive or disconnected from deployment. A report still needs to define the construct, sample, model version, inference settings and uncertainty. Without that context, “cryptographically verified” can be mistaken for a quality certificate. Cryptography protects the execution history; it does not guarantee that the research question, benchmark or interpretation was wise.
When this pattern is worth adopting
The strongest candidate is an evaluation in which both secrets carry material value: disclosing questions would shorten the benchmark’s useful life or create security risk, while transferring weights would be unacceptable. Before execution, the parties should agree the threat model, owner of each layer, accepted firmware versions, build process, output policy, log retention, abort path and dispute procedure. That coordination cost will be disproportionate for a routine public benchmark and justified mainly where ordinary access arrangements prevent credible testing.
The critical verdict on the pilot is positive but conditional. It removes an important institutional barrier and could improve oversight of closed models. Maturity should be judged through independent reproducibility, publication of the attestation policy, fast response to hardware vulnerabilities and a clear account of what the evaluation excluded—not by the number of polished demonstrations. The durable value is not the aura of a “secure box”; it is an auditable division of responsibility when neither party can simply trust the other.
The benchmark’s life after its first secure run
Confidentiality does not end when the enclave is decommissioned. Participants need rules for who retains the report, whether the provider may test successive checkpoints, when item-level results can be disclosed and after how many runs the benchmark is considered partly contaminated. Even without seeing questions, repeated experiments against one metric create feedback that can guide model tuning. Trial limits and a transparent evaluation register therefore help preserve independence.
Every report should bind its result to the model hash, benchmark version, attestation policy and verification time. A driver, firmware, evaluation-code or aggregation change makes comparison with the previous result a new claim requiring justification. A well-governed protocol creates a provenance chain rather than a one-time badge. It lets readers distinguish a current, reproducible measurement from a number still circulating in presentations after the tested system has changed.
A dispute needs a disclosure protocol before a result exists
A confidential evaluation becomes most difficult not during a clean run but when the parties interpret a disappointing result differently. Before testing, they should approve a dispute charter: who may raise an objection, what evidence is admissible, who acts as a neutral custodian and which events pause publication. The charter should separate challenges to the benchmark, model, infrastructure and aggregation method. A provider then cannot dismiss the whole evaluation with a general complaint, while an evaluator cannot use confidentiality as a reason to refuse every form of scrutiny. A process agreed in advance also protects the party with less organizational leverage because access to an appeal does not depend on bargaining power after the result is known. Asset owners should declare conflicts of interest and identify people who must step back from a decision.
Disclosure should proceed in layers. The parties first receive a public summary that separates agreed facts, open objections and interpretation of the result. If that is insufficient, a neutral reviewer receives access inside a controlled environment only to the artifact needed to decide the specific challenge. The scope expands only after recording why the previous layer could not answer the question. Every step needs an owner, rationale, decision trail and a pre-agreed review point. A correction should not overwrite the original report; it should appear as a signed addendum tied to the versions of the model, benchmark and execution policy. This ledger preserves history without exposing secret prompts or weights to the public. Protocol maturity is demonstrated not by an absence of disputes but by whether disagreement can be resolved without allowing either party to declare the truth unilaterally or leak the other party’s asset.
Frequently asked questions
What does “double-blind” AI evaluation mean?
The model provider cannot see confidential questions, while the evaluator receives neither weights nor private inference code. Both assets meet only inside an attested enclave, which returns a result agreed in advance.
Does the protocol prove that a model is safe?
No. It strengthens confidentiality and execution integrity. The conclusion still depends on benchmark quality, test scope, the exact model version and whether measured behaviour transfers to real deployment.
Does an enclave eliminate trust?
No, but it narrows and relocates it. Participants still rely on hardware, firmware, attestation and reviewed software. The gain is that this trusted base can be specified and the running configuration independently checked.
When is the additional complexity justified?
When a benchmark contains sensitive material or loses value after disclosure, while transferring model weights is unacceptable. For a routine public benchmark, coordination overhead may outweigh the privacy benefit.