Google Adds a Lock to AI Benchmark Testing

Google is adding an extra layer of protection to AI model evaluations so that the parties involved cannot “see” one another.

On August 27, Google announced the launch of a double-blind evaluation technology for frontier proprietary AI models. External evaluation organizations can test models in an encrypted “black box” environment without seeing the model weights, while model providers cannot see the evaluators’ test prompts. Both sides receive only verified evaluation results.

The pilot was conducted by Google in collaboration with the Singapore Institute of Artificial Intelligence Safety, OpenMined, AVERI, and MLCommons, using Gemini Flash Lite as the test subject. Google said this is the world’s first double-blind evaluation practice targeting frontier proprietary AI models.

It addresses a problem that exists far beyond academic papers. Today, many model leaderboards appear increasingly precise, with scores reported to several decimal places. Yet it is becoming harder to determine whether those scores still represent a model’s true capabilities.

Models May Have “Seen the Exam Questions” Long Ago

AI evaluation has a long-standing problem: benchmark contamination. In other words, a model may encounter test data during training or later fine-tuning, causing it to perform unusually well during formal evaluation.

The analogy to students taking exams is not entirely accurate. If a student sees a question in advance, they may simply gain a few extra points. If a model has seen an entire test set, similar wording, or even answer explanations in its training corpus, it may learn “how to pass this exam” rather than the reasoning abilities underlying the questions.

For large language models, contamination does not come only from training data. Public benchmarks are repeatedly circulated, and test questions and answers may appear in papers, code repositories, dataset mirrors, forum discussions, and model evaluation reports. Before releasing a new version, model developers may also gradually become familiar with the distribution of certain public test sets through extensive internal experiments.

This creates an awkward result: models continue to improve on benchmarks, but developers cannot tell whether that improvement comes from greater capability or from adapting to the evaluation rules and test samples.

For general question answering, this bias may merely distort leaderboards. In high-risk scenarios such as cybersecurity, healthcare, and government affairs, the consequences are much more serious. A model that scores highly on a public security test is not necessarily equally reliable when facing unknown attacks.

Traditional Evaluation Is Caught in a Dilemma

Independent evaluations currently usually require evaluators and model vendors to exchange information, and both categories of information are sensitive.

If evaluators hand the complete test prompts to a model vendor, the vendor has an opportunity to see the questions in advance and optimize the model or adjust its system prompts accordingly. Even without intentional cheating by the vendor, once a test set becomes public, a model may “encounter” it again in future training data.

Another approach is to give evaluators access to the model weights and run the tests locally. This is relatively feasible for open-source models but is practically unworkable for closed-source models. Model weights are a vendor’s most valuable intellectual property. They contain the results of training, architectural implementation details, and commercial advantages, making it impossible to hand them to a third party merely to undergo a single external evaluation.

As a result, independent evaluation has long remained in an imperfect state:

• Evaluators control the questions, but the model provider may gain access to test information in advance;
• The model provider controls the weights, but external organizations cannot independently verify them;
• Neither side shares complete information, making evaluations difficult to reproduce;
• The more public a test is, the more easily it can be contaminated; the more confidential it is, the harder it is to build industry consensus.

Google’s double-blind approach essentially simplifies the exchange relationship: both the test questions and the model weights enter an execution environment that neither side can directly read.

How the Encrypted Black Box Works

Google uses Google Cloud Confidential Space and its associated confidential computing capabilities. The key point is not merely to “store data after encrypting it,” but to keep the data protected as much as possible during computation as well, while using cryptographic verification to confirm that the runtime environment and code meet expectations.

In this test, the evaluation data was prepared by the external organization, while Google provided the Gemini model. Through mechanisms such as remote attestation, both sides confirmed that the testing tasks were executed in a verified confidential environment:

Evaluation organization: Submits encrypted test prompts
Google: Submits the protected proprietary model
Confidential environment: Verifies the running code and performs the evaluation
Output: Returns aggregated evaluation metrics

In terms of permission boundaries, the evaluation organization cannot read Gemini’s model weights, and Google cannot view the specific test prompts. This makes it difficult for the model provider to optimize for individual questions, while also preventing the evaluator from copying the model for other purposes.

This differs from ordinary API testing. API evaluation generally means that the caller can see the inputs and outputs, while the service provider knows at least the request content and calling patterns. Double-blind evaluation is closer to a certified “remote measuring instrument”: data goes in and results come out, but the participants cannot arbitrarily disassemble the instrument or inspect the other party’s materials.

Of course, confidential computing is not magic. It relies on hardware isolation, trusted execution environments, remote attestation, access controls, and an auditable software stack. If there are vulnerabilities in the environment configuration, evaluation code, or result aggregation mechanism, the double-blind setup can still lose its meaning. Therefore, what truly matters is not merely “using encryption,” but whether a third party can verify that the entire evaluation process actually operated as promised.

Especially Valuable for Closed-Source Models

The most direct beneficiaries of this technology are closed-source models that are unwilling to disclose their weights but still need to undergo external scrutiny.

In the past, most safety reports published by closed-source model vendors were produced by internal teams or involved controlled evaluations by partner organizations. Such reports are not without value, but it is difficult for outsiders to determine whether the test sets were sufficiently unfamiliar, whether the evaluators had complete independence, and whether the results had been filtered by the vendor.

A double-blind environment provides a middle path: model vendors do not need to hand over their weights, and third parties do not need to provide the complete question bank to the vendors. This is particularly important for government agencies, financial institutions, cybersecurity laboratories, and medical research organizations. These entities often possess data that cannot leave their local environments or be seen by model vendors, while still needing to verify whether a model meets a given safety threshold.

For example, a cybersecurity organization may want to test a model’s ability to identify phishing emails, analyze malicious code, or reproduce vulnerabilities. The test prompts may contain unpublished attack samples and internal intelligence that cannot be handed directly to a model company. If the evaluation is completed inside a confidential environment, the organization can retain control of its data while obtaining a relatively independent measurement of the model’s capabilities.

Government agencies have similar needs. They may need to evaluate a model’s performance on sensitive-language tasks, critical infrastructure, emergency response, or intelligence analysis, but cannot hand complete scenarios to a vendor. Double-blind evaluation means that “third-party verification” no longer necessarily entails “the leakage of sensitive data.”

But It Is Not the End Point for Evaluation Credibility

The significance of Google’s pilot lies more in providing a new evaluation infrastructure than in proving that all benchmark problems have been solved.

First, double-blind evaluation can prevent participants from seeing each other’s core assets in advance, but it cannot automatically guarantee the quality of the test set. If the questions have insufficient coverage or measure only certain capabilities, a model can still perform well on the metrics while failing in real-world environments.

Second, the evaluation code itself must be trustworthy. Who writes the test logic? Who reviews the code? Is there room for people to selectively choose metrics? Can the results be reproduced? These questions still require institutional arrangements. An incorrect test protected by encryption is still an incorrect test.

Third, model outputs cannot always be summarized by a single score. Factuality, robustness, tool use, long-context performance, refusal strategies, and cybersecurity capabilities often require different test designs. For Agent-style models in particular, the evaluation target has expanded from “whether the answer is correct” to “whether the model will take irreversible actions.” Returning only an overall score may obscure critical risks.

Fourth, confidential computing introduces additional costs and engineering complexity. Hardware support, cloud environment configuration, key management, remote attestation, and auditing procedures all raise the barrier to evaluation. Large organizations may be able to afford them, but small research teams and open-source communities may not be able to reuse them easily.

Therefore, double-blind evaluation is better understood as filling a missing piece of infrastructure for the industry, rather than replacing public benchmarks, red-team testing, human review, and real-world monitoring.

Beyond Leaderboards, the Industry Needs “Verifiable Evaluation”

Over the past few years, model competition has revolved largely around leaderboards. Vendors publish a set of benchmark scores, outsiders use those scores to judge whether one model is stronger, and developers then choose APIs or deployment solutions accordingly. But once every vendor becomes familiar with public leaderboards, the scores themselves become less discriminative, and the credibility of the evaluation begins to matter more than the size of the number.

Google’s move sends a signal that model evaluation is shifting from “publishing questions and scores” toward “demonstrating that the testing process has not been manipulated.” This is why double-blind evaluation, confidential computing, and remote attestation are gradually entering discussions about AI governance.

A more mature evaluation system in the future may need to provide several capabilities at once:

1. Keep test data unknown to model providers to reduce the risk of benchmark contamination.
2. Keep model weights or internal implementations isolated from evaluators to protect intellectual property.
3. Make the execution environment and evaluation code verifiable, auditable, and reproducible.
4. Report not only overall scores, but also task distributions, failure cases, and confidence intervals.
5. Support continuous evaluation to observe whether model updates cause capability regressions or introduce new safety issues.

For developers, the practical impact is not that they need to switch to a new evaluation tool tomorrow. It is that, when looking at model scores in the future, they should ask one additional question: How was this score produced? Was the test set independent? Had the model encountered the data in advance? Did the evaluator truly have independent authority?

By placing Gemini Flash Lite in this environment, Google has first completed a technical validation. Whether it can be adopted by other model vendors, independent laboratories, and regulators will depend on cost, the degree of standardization, and whether the parties involved are willing to accept verifiable external oversight.

At least today, competition in AI evaluation is no longer only about “whose model has the higher score.” It also includes “who can make others believe that the score is meaningful.” This may be an easily underestimated dimension of the next stage of competition in model infrastructure.

References

• ITHome: Google Launches the World’s First Double-Blind AI Evaluation Technology — Provides specific information about Google’s confidential benchmark testing conducted in collaboration with the Singapore Institute of Artificial Intelligence Safety, OpenMined, AVERI, and MLCommons.