A Private Exam for AI Models: Inside DeepMind’s Double-Blind Evaluation Pilot

A benchmark stops measuring a model the moment the model maker can study the questions. But the people best placed to write difficult, sensitive tests cannot simply hand them over, and the companies best placed to run frontier models will not hand over their weights. Google DeepMind’s new pilot tries to resolve that standoff by turning a confidential GPU environment into a neutral examination room. The important question is not whether the system makes a benchmark score impressive. It is whether it makes that score believable.

On August 27, 2026, Google DeepMind announced a pilot it calls the world’s first double-blind evaluation of a proprietary frontier-class AI model. The company is working with the Singapore AI Safety Institute, OpenMined, AVERI, and MLCommons to evaluate a Gemini Flash Lite model against confidential benchmarks inside a privacy-preserving environment.

The phrase sounds like a technical refinement, perhaps another layer of cloud security for a field already overloaded with claims about secure AI. It is more consequential than that.

AI evaluation has developed an awkward contradiction. The industry says model testing should be independent, rigorous and difficult to game. Yet a serious evaluator often needs to protect its prompts, scoring rules, datasets, red-team techniques and methods of detecting a subtly dangerous answer. A model vendor, meanwhile, wants to protect model weights, inference systems, deployment settings and intellectual property.

Until now, those interests have usually met through contracts, controlled API access, zero-logging promises or a great deal of mutual trust. Those measures can be useful. They are not the same as a system in which neither party must simply take the other’s word for it.

DeepMind’s idea is to create a room where the evaluator can bring the exam paper, the vendor can bring the model, and neither side gets to inspect the other’s materials. The room is a confidential-computing enclave, a specially protected execution environment that can produce cryptographic evidence about what code ran inside it. The evaluator receives evidence that its private test was handled according to an agreed procedure. The vendor receives evidence that its proprietary model was handled under the same procedure. Only a deliberately narrow set of outputs gets out.

That is the promise. It matters because benchmark secrecy is becoming part of the measurement problem itself.

The test has become a target

Picture the human version first.

A university wants to know whether a student can solve unfamiliar problems. It does not publish the final exam six months before the test, invite tutors to drill every question, then celebrate the resulting pass rate as proof of learning. Everyone understands why. The score would measure preparation for a known artifact as much as underlying competence.

AI benchmarking often operates under much less forgiving conditions. Public benchmarks have helped the field move quickly. Researchers can compare methods, rerun work, identify errors and establish a shared vocabulary. That openness remains essential for science.

But public tests also become training material, fine-tuning targets and product marketing battlegrounds. Even when a benchmark’s exact questions are not deliberately added to training data, they may circulate through papers, repositories, mirrors, tutorials, online discussions or variants that reveal the structure of the original task. A model can learn the answers. It can also learn the style of answer that earns points.

This is benchmark contamination. It does not require a model to contain a literal, searchable copy of every prompt. Exposure can be partial. The training process can contain close paraphrases, worked examples, answer keys, generated derivatives or repeated cues about what a benchmark rewards. The result is an uncomfortable ambiguity: a high score may indicate general capability, test familiarity, or a mixture of both.

DeepMind itself frames the issue through the exam analogy and says benchmark contamination can skew apparent performance when models have seen prompts in advance. The company argues that conventional confidentiality agreements and zero-logging arrangements are no longer enough by themselves for especially sensitive tests.

The stakes rise with the kinds of tests people most want independent evaluators to create. A cybersecurity evaluation might include undisclosed vulnerable code. A biosecurity assessment could contain sensitive task structures that should not be widely distributed. A national AI safety institute may hold proprietary scenarios drawn from real public-sector risks. An enterprise may want to test a model against internal processes, documents or adversarial cases that cannot leave its control.

In each case, the evaluator has a good reason not to give a vendor a reusable study guide.

The old arrangement forces a choice. The evaluator either gives the model developer enough access to run the test, thereby creating opportunities for prompt exposure, or the developer gives the evaluator unusual access to the model, potentially including weights or internal infrastructure. Black-box API testing avoids the latter risk, but it means the vendor controls the execution environment. A contract may prohibit logging. An independent auditor may inspect a process. Neither arrangement automatically proves that the intended process was the one actually executed.

That gap is what the enclave is intended to narrow.

A neutral room with locked doors

Confidential computing is often explained in terms of encryption. That is true, but incomplete.

Data are normally protected in two familiar moments. They are encrypted while stored, and encrypted while moving across a network. The difficult moment is when a computer needs to use the data. To calculate an answer, the machine ordinarily decrypts information in memory. This is called data in use, and it is where a cloud operator, privileged administrator, compromised host, or malicious software may theoretically gain access.

A confidential-computing environment tries to reduce that exposure. It creates an isolated area whose contents are protected from the surrounding system, including much of the infrastructure that ordinarily runs the workload. In the DeepMind pilot, the protected area is described as a GPU enclave within Google Cloud’s Confidential Space offering. DeepMind says the arrangement allows cryptographic verification that the evaluator’s data and Google’s proprietary model each remain private to their respective owners.

The word “verification” deserves close attention. The architecture does not ask the evaluator to trust a vague claim that the cloud is secure. It is built around remote attestation.

Remote attestation is like checking the seal, serial number and approved blueprint of a laboratory before delivering a sample. Before an evaluator releases its encrypted prompts, it receives a signed technical statement from the protected environment. That statement should identify the hardware security state, the approved evaluation software, the relevant configuration and the code identity of the workload that will handle the prompts.

If the evidence matches the evaluator’s policy, the evaluator releases a decryption key. If it does not match, the key remains withheld. The vendor goes through an analogous process for the model artifact or the key needed to activate it.

The central idea is simple: secrets are not sent because a counterparty says, “Trust us.” They are released only to a verifiably configured environment.

This is why “double-blind” is a useful description, although it should not be confused with the clinical-trial meaning of the phrase. In this setting, the blindness is asymmetric but mutual.

The evaluator should not see the model weights, proprietary serving code or other vendor-controlled internals. The vendor should not see raw prompts, benchmark datasets, hidden scoring rubrics or the evaluator’s full methodology. Both may see an agreed result. Both may receive evidence that the system followed the rules. Neither should receive the other side’s raw secret.

A crucial detail is that the enclave is not merely a place where two encrypted files happen to coexist. It is a governed process. Its value comes from the sequence:

1. The parties agree on what will run.
2. The environment proves what it is prepared to run.
3. Each party releases only the key needed for that verified environment.
4. The environment executes the evaluation.
5. It produces only the outputs that the policy permits.
6. It records or commits to evidence of the run.
7. The parties can verify that the run corresponds to the agreed version of the system.

Each step has a failure mode. A credible evaluation design has to address all of them.

The difference between a locked room and a trustworthy process

The first question a reader should ask is not, “Was an enclave used?” It is, “What exactly did the enclave enforce?”

A protected GPU environment can mitigate one very specific and increasingly serious risk: the evaluator’s prompts becoming available to the model vendor in a form that enables deliberate pre-test optimization. It also reduces pressure on vendors to reveal model weights to evaluators, a significant concern for commercial competition and model security.

That can make confidential benchmarks more practical. A safety institute may be willing to test a model with scenarios it would never upload to an ordinary vendor dashboard. An enterprise may be able to use internal material without letting a model provider retain it. A third-party evaluator may gain a more credible basis for saying that the vendor did not get direct access to the exam.

DeepMind says the pilot is particularly relevant to sensitive assessments in areas such as cybersecurity and government use, where benchmark confidentiality and data sovereignty matter sharply.

But privacy of inputs is not equivalent to integrity of the evaluation. A locked room can still contain the wrong test, the wrong model, the wrong stopwatch or the wrong scorekeeper.

Consider the evaluation harness. This is the software surrounding the model: prompt formatting, sampling settings, system instructions, tool permissions, retries, timeout rules, scoring logic and aggregation. Small choices can dramatically alter outcomes. A model tested with generous retries or specialized tools is not the same product as a model tested once without them. A model evaluated with a quiet system prompt may behave differently after a product team adds a consumer-facing policy layer.

If the harness is not precisely specified and included in attestation, the enclave may faithfully run an ambiguous experiment.

The model identity matters just as much. “Gemini Flash Lite” is a product family name, not necessarily a complete description of a tested artifact. A meaningful report should identify a model version, release date, checkpoint or immutable cryptographic digest. It should specify whether safety fine-tuning, system prompts, content filters, retrieval, search, code execution, memory, routing or tool access were enabled.

Otherwise, an evaluator may test one thing and the public may infer another.

This concern is not theoretical. DeepMind has previously noted that external groups evaluating Gemini through API or chat access were testing production-ready fine-tuned versions with safety filters, and that parameters such as temperature and token limits could be configured in some cases. Those choices may be justified, but they demonstrate why evaluation setup is inseparable from evaluation result.

An enclave can bind the setup more tightly. It cannot make ambiguous setup choices disappear.

Key release is where trust becomes operational

The key-release process is the heart of the design, and it is easy to gloss over because it sounds administrative. It is not.

Suppose an evaluator encrypts a confidential benchmark. The file can sit in storage, travel across the network and even enter the enclave without revealing anything useful. The decisive moment occurs when the evaluator’s key-management system decides whether to provide the key that decrypts it.

A robust policy should require more than a claim that an enclave exists. It should check an attestation report against a narrow allowlist. The report should match a specific hardware security configuration, a specific confidential runtime, a specific version of the evaluation harness, a specific network policy and, ideally, a specific output policy.

The vendor’s model key should be similarly conditional. The model package should unlock only for an environment running the agreed evaluator code, not for a generic enclave that could be repurposed to inspect or extract it.

This is the difference between using keys as passwords and using keys as conditional consent. The evaluator’s key says: “You may inspect these prompts only if you are exactly this approved process.” The vendor’s key says: “You may invoke this model only if you are exactly this approved process.”

There are still difficult design questions.

Who writes the allowlist? If Google controls the attestation policy, an outside evaluator may worry that the vendor has too much influence over the definition of “approved.” If the evaluator controls it completely, the vendor may worry that the evaluation code is designed to reveal too much about the model or to issue unbounded queries. A stronger arrangement makes the policy inspectable by both parties, locks it before the run, and gives each party a veto over material changes.

The key system must also prevent a common operational mistake: approving a broad class of environments rather than a particular evaluation. A policy that allows any future workload with a vaguely similar configuration is less reassuring than one tied to exact code measurements and a time-limited, one-purpose run.

Attestation, in other words, should not become a ceremonial stamp. It should be the gatekeeper.

Output is the escape hatch

If prompts are the exam paper and model weights are the trade secret, outputs are the hallway door. Most of the privacy risk now flows through them.

An evaluator needs results. It may need model answers to determine whether a failure was genuine. It may need sample outputs to write a public report. A vendor may need diagnostic data to fix a defect. Yet rich outputs can leak secret prompts, reveal sensitive evaluation methods or help a vendor reverse-engineer the benchmark.

The answer is not necessarily to prohibit all outputs. It is to define an output policy before testing begins.

For a simple capability benchmark, the evaluator might receive every answer while the vendor receives only an aggregate score and a class of failure. For a highly sensitive red-team exercise, the evaluator could receive encrypted detailed records, while the vendor receives a constrained remediation report identifying behavioral categories without the exact attack prompts. An independent oversight body could receive a sealed evidence package available only if a dispute arises.

The output filter itself must be part of the trusted workflow. If it runs outside the enclave, unfiltered model responses may leak before policy is applied. If the filter is opaque or easily changed, it can become a tool for withholding inconvenient evidence.

A public result should therefore say what was withheld and why. “Independent evaluation” should not mean “trust us, the details are secret.” It should mean “some details are secret, but here is enough evidence to understand what was tested, under what configuration, by whom, with what limits, and how the result was computed.”

The tension is real. The more detail an evaluator releases, the easier it may be to contaminate the benchmark. The less detail it releases, the harder it is for outsiders to assess whether the score means anything. Good governance does not eliminate this tradeoff. It makes the tradeoff visible and managed.

Logging must be deliberately narrow, not merely absent

DeepMind contrasts the technical approach with traditional zero-logging protocols. That comparison is revealing. “No logs” is a powerful promise if everyone follows it. It is a weaker guarantee if a party cannot technically verify the absence of collection.

But a secure evaluation cannot simply log nothing. Without records, there is no reproducibility, dispute resolution or credible audit trail. The objective is selective logging.

A well-designed system should distinguish at least four categories:

• Operational logs, such as machine health, job start and job completion. These may be necessary, but should not include prompts or raw responses.

• Integrity logs, such as attestation evidence, software hashes, configuration digests, key-release decisions and signed timestamps. These are essential because they establish what ran.

• Evaluation records, including prompts, responses and fine-grained scores. These are often the most sensitive and should be encrypted, access-controlled and retained only according to a stated policy.

• Public reporting records, such as aggregate results, methodology summaries, known limitations and remediation commitments.

The important test is whether the process creates enough evidence to support a claim without creating a quiet back channel through which secrets accumulate.

A vendor should not be able to retain raw prompts “for debugging” unless the evaluator explicitly agreed to that access. An evaluator should not be able to collect unlimited model traces, internal activations or response variants unless that was part of the approved scope. Cloud operators should not obtain broad visibility simply because they host the infrastructure.

This is partly technology and partly discipline. Technical controls can limit access. Contracts, retention rules, independent oversight and consequences for violations still matter. A cryptographic room does not make its human operators irrelevant. It reduces what any one operator can do alone.

Reproducibility without publishing the answer key

The usual scientific instinct is to publish data and code so others can reproduce a result. Confidential evaluation complicates that instinct, but it does not make reproducibility impossible.

The goal changes from universal rerunnability to verifiable repeatability.

A credible report can publish cryptographic commitments to the benchmark version and harness version without releasing the benchmark itself. It can disclose the model digest, decoding settings, tool policy, run date, number of trials, scoring protocol, confidence intervals where appropriate, and the attestations that bound the setup. It can allow a trusted third party to repeat the evaluation using the sealed materials. It can schedule a later disclosure window after a benchmark has been retired.

The public does not need every test question to ask sensible questions about the result. Was the benchmark fixed before the model was selected? Did the evaluator control the test set? Was the model version frozen? Were tool calls enabled? Were answers scored by people, by code or by another model? Were failures independently reviewed? Was the test repeated? Did the vendor receive prompts, traces or only aggregates?

A confidential benchmark should be harder to game, not easier to hide behind.

DeepMind’s pilot is significant precisely because it attempts to provide cryptographic evidence about the protected process rather than relying solely on organizational assurances. But the company’s announcement is a pilot, not the final standard. Its real contribution may be to force the field to define what evidence an evaluation claim must carry.

What this architecture cannot tell us

The most important limitation is conceptual: a secure test can still test the wrong thing.

Construct validity is the formal term. In plain language, it asks whether a score actually measures the capability or risk people say it measures. An enclave can prove that a model answered a secret set of questions. It cannot prove that those questions represent real-world cybersecurity ability, deception risk, scientific reasoning, fairness, reliability or economic usefulness.

The second limitation is harness quality. If the prompt template is unrealistic, if scoring rewards superficial phrasing, if the evaluator gives one vendor special tool access, or if an automated judge makes systematic mistakes, confidential computing faithfully preserves a flawed procedure.

The third is public-variant gaming. A vendor may never see a particular secret prompt yet still optimize on publicly known benchmark families. If an evaluator’s questions follow a familiar template, models can learn the genre. Secrecy is strongest when it is combined with task diversity, regular refreshes, hidden distributions and careful selection of cases that resemble real-world use.

The fourth is hidden capability or hidden assistance. A model may appear to perform well because it had retrieval, web search, code execution, memory, a routing system or human-in-the-loop support. Those tools can be appropriate. The issue is disclosure. The enclave can enforce an agreed tool policy, but it cannot decide which policy answers the public’s question.

The fifth is deployment drift. The model in a protected test may not be the model customers use a month later. Product teams update weights, routing, filters, system prompts, tools and user interfaces. Behavior changes with them. An independent evaluation of a frozen artifact is meaningful, but it is not a permanent certificate for every future deployment.

Finally, there is the risk of performative independence. If the vendor chooses the evaluator, funds the work, negotiates the scope, controls publication timing and receives veto power over findings, the enclave will not solve the governance problem. It may protect the prompts very well while leaving the institutional incentives untouched.

A practical checklist for reading “independent evaluation” claims

For buyers, policymakers, journalists and researchers, the next wave of evaluation announcements should invite a more exacting set of questions.

1. Was the model identity fixed? Look for an exact version, a cryptographic identifier or another immutable reference. A product name alone is not enough.

2. Was the benchmark genuinely confidential before the run? Ask who authored it, whether it was exposed to the vendor, whether public variants exist, and how long it has been in circulation.

3. What did attestation verify? A serious answer identifies the hardware-backed environment, the workload identity, the evaluation harness and the relevant network and output policies.

4. Did key release depend on attestation? If the benchmark and model could be decrypted in a broad or manually administered environment, the core assurance is weaker.

5. What exactly was tested? The report should state prompts, system instructions, tool access, sampling settings, retry rules, timeout rules, filters and any agentic scaffolding at a meaningful level of detail.

6. What could each party see? Specify whether the vendor saw raw prompts, model outputs, failure labels, aggregate scores or no evaluation records at all. Specify whether the evaluator saw weights, traces or only responses.

7. What was logged and how long was it retained? “Zero logging” is not a sufficient answer. The question is which data was logged, encrypted, accessible and deletable.

8. Who scored the results? Automated scoring, human scoring and model-based grading each introduce different failure modes. A credible evaluation explains review procedures and disagreement handling.

9. Can another trusted party reproduce the run? Full public release may be impossible. Independent repetition using sealed artifacts should not be.

10. What does the result not establish? The strongest reports explain their boundaries. They do not let one confidential score stand in for broad safety, reliability or readiness claims.

The benchmark vault is not the verdict

There is a temptation, especially in AI, to treat better measurement infrastructure as a substitute for judgment. It is not.

A private test can make a score more resistant to one of the field’s most damaging distortions: the slow conversion of every respected benchmark into training data and marketing material. It can let external experts use sensitive tests without surrendering them. It can protect vendors from having to expose model weights. And it can create a technical