Google DeepMind pilots double-blind AI evaluations inside confidential computing enclaves
Hiding test prompts from the model maker and weights from the testers shows how confidential computing can make benchmarks harder to game.
Google DeepMind on 27 August described a pilot of what it calls double-blind AI evaluations, in which an external tester's prompts are hidden from the model provider and the model's weights are hidden from the tester. The post, authored by William Isaac, Sol Messing and Kristian Lum, said the approach is intended to address benchmark contamination and to protect sensitive test material, such as cybersecurity or government evaluations.
The pilot ran on a Gemini Flash Lite model inside Confidential Space, part of Google Cloud's Confidential Computing portfolio, using a secure GPU enclave. DeepMind said the arrangement lets both parties cryptographically verify that the evaluation data and the proprietary model remain private to their respective owners. The post illustrates the arrangement as a seven-step secure evaluation workflow, though it does not enumerate the steps in text. It describes the enclave as the place where the external evaluation data and the model meet without either being disclosed to the other side.
DeepMind named the Singapore AI Safety Institute, OpenMined, AVERI and MLCommons as partners in the pilot. It did not describe the specific roles each organisation played, publish results from the evaluation, or give figures on performance or overhead. The stated aim is to remove a trade-off that has constrained third-party testing: evaluators either had to submit prompts through an API, exposing them to the provider, or providers had to release weights, exposing their model.
The post closes by saying DeepMind hopes the pilot establishes a new approach to model oversight that the wider industry can adopt to build safer and more widely trusted systems. No timeline for broader availability was given.
Why it matters
External evaluation only carries weight if the evaluator can be confident the model has not seen the test, and the provider can be confident the evaluator has not seen the model. Confidential computing on GPUs turns that mutual assurance into a technical property rather than a contractual promise. If it scales, it could change how safety institutes and standards bodies certify models.
External evaluation only carries weight if the evaluator can be confident the model has not seen the test, and the provider can be confident the evaluator has not seen the model.
Conventional evaluation
Evaluator sends prompts to the provider's API, exposing the test set; or the provider hands over weights, exposing the model.
Double-blind evaluation
Prompts and weights meet inside a confidential GPU enclave; each party verifies cryptographically that its asset stays private.
What you can learn from this
- Benchmark contamination inflates scores without improving models. If test questions appear in training data, even accidentally through web scrapes, a model can reproduce answers it has memorised. Public benchmarks decay for this reason as soon as they are published. Keeping prompts private to the evaluator removes the leak at its source, which is why hidden test sets matter more than ever for frontier models. Contamination is hard to detect after the fact, because overlap can be paraphrased rather than verbatim, and private sets must be refreshed too, since results shared with a provider gradually reveal them.
- A trusted execution environment isolates code from its host. A TEE is a hardware-enforced region of memory that the operating system, hypervisor and cloud operator cannot read. Code inside it can process secrets that were encrypted on the way in and are only decrypted within the enclave. Extending this to GPUs is recent and important, because model inference runs on accelerators, not CPUs. Memory is encrypted with keys held by the processor, so even someone with physical access to the server sees only ciphertext.
- Remote attestation is how you know you are talking to the enclave. Before releasing secrets, each party asks the hardware for a signed measurement of exactly what code is running inside the environment. If the measurement matches the expected workload, the party releases its key. This is what turns a confidentiality promise into something a third party can verify. The measurement covers code and configuration, not data, so both parties must also agree in advance on exactly which evaluation program will run.
- Double-blind borrows from experimental design. In a clinical trial, neither the participant nor the researcher knows who received the treatment, which removes both sources of bias. In model evaluation, the two assets are prompts and weights, and the two parties are evaluator and provider. Blinding both sides means neither can tune the outcome, deliberately or by accident. The analogy also carries a warning: blinding removes bias in the measurement but says nothing about whether the test itself measures the right thing.
- Confidentiality does not cover everything. An enclave protects data at rest and in use, but the model's outputs still leave the environment and can leak information about the prompts, and side channels such as timing remain an active research topic. The threat model must state what is protected and what is not. Reading that fine print is the difference between real assurance and a reassuring diagram. The evaluator also has to trust the hardware vendor's attestation root, which is a different kind of trust from trusting the provider.
We teach this
How to use this in practice
- Build a private evaluation set you never publish. Write 30 prompts with reference answers that reflect the work you actually do, store them outside any repository, and script a run against whichever model you use, scoring exact or rubric matches. Done looks like: a baseline score you can re-run when a model version changes, on questions that cannot be in anyone's training data. Version the prompt set with a date, score with a script rather than by eye, and retire any question you end up quoting in a public bug report.
- Check whether a public benchmark you cite is versioned. Find the benchmark's repository, note the commit or release you are using, and record its publication date next to the model's training cut-off. Done looks like: a one-line note in your evaluation report stating which version you used and why contamination is or is not a concern. If the benchmark includes a canary string, check whether the model reproduces it, which is a quick contamination signal.
- Inspect a confidential computing option on your cloud account. Look up how your provider exposes confidential VMs and whether any GPU types support them. Run the describe command for an instance you own, for example
gcloud compute instances describe NAME, and look for a confidential instance configuration block. Done looks like: a note stating which of your workloads run in a confidential environment, even if the answer is none. If nothing supports it, record the closest available option and what it would cost, so the answer is a decision rather than an unknown. - Draw the trust boundaries. Sketch three boxes: the evaluator's prompts, the provider's weights and the enclave where they meet. Add arrows for encrypted inputs, attestation checks and the outputs that leave. Done looks like: a diagram where you can mark, honestly, which arrows are verified by hardware and which rely on the other party's word. Add a fourth box for the outputs and write beside it what a determined party could infer from them alone.
Sources
- Piloting the world's first double-blind AI evaluations — Google DeepMind
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report