What is compute verification?

Suppose you want to know properties about what a machine is computing, but you do not trust the machine’s owner to be honest to you. The other way around, the machine’s owner wants to keep their data confidential, hidden from you. Compute verification bridges the gap, proving properties about data, computation and hardware activity without revealing the secrets.

We call the data owner the prover, and the checking party the verifier.

‍

What is this good for?

It makes it possible for distrusting parties to work together on governing compute. This is especially important for mutually verifying adherence to agreed rules about how (or how not) to use computing resources. The most prominent motivation behind compute verification is international cooperation on responsible and restrained R&D of AI: highly sensitive information in closed-door research, and risks posed to people both within and outside of frontier companies. Without AI compute verification, we could get a race-to-the-bottom: Stay ahead of the competition, or be out-competed by someone more reckless than you. 

With AI compute verification, it becomes possible to govern AI even across borders: Nation A and nation B mutually verify that rules are being followed, and tradeoffs in favour of safety and responsible use are made by all sides.

For readers interested in reading more about this use case in particular, we point to the following resources:

An International Agreement to Prevent the Premature Creation of Artificial Superintelligence - MIRI

AI 2040 - AI Futures Project

A Few Reasons to Develop AI Verification Technology - Amodo Design

‍

What kinds of rules could an agreement contain? Examples please.

Suppose the United States, China, and other jurisdictions were to seek an agreement for more responsible AI development and deployment. Here is a demonstrative list of rules that these parties may agree on:

1. Maintain monitorable chains of thought, refrain from developing frontier AI with inscrutable decision-making, or putting it in charge of high-stakes decisions/giving it tool-use interactivity with the world.
2. Require all AI model checkpoints and scaffold versions (potentially including training data as well) to be cryptographically committed to a governing body. The commitments need not reveal the plaintext data, but they lock in the data for later, privacy-preserving auditing.
3. Require AI systems to be approved by a regulator before deployment, including internal-only deployment. A criterion for whitelisting may be for an AI system to pass a standardised suite of evaluations, which could be updated as evals advance and requirements change.
4. Prohibit certain use cases of AI. It could be desirable to prohibit covert AI-enabled influence/deception campaigns, fraud/ransom, or aiding unapproved users in high-risk dual-use areas such as CBRN (Chemical, Biological, Radiological, Nuclear).

‍

What does this do for me in particular?

If you are a regular citizen:

If powerful AI continues being siloed and securitized, democratic oversight is at stake. If the confidentiality of intellectual property shields internal AI deployment from public view, voters are un-informed about the real, closed door frontier, and what it is used for. As AI becomes increasingly powerful, the risks to the public become ever larger. Privacy-preserving verification helps remove plausible deniability that can be exploited by powerful actors to act against public interest in secret. For example, training data of frontier models is proprietary and a strictly guarded business secret. Whether or not this data contains copyrighted material or user data could be proven or disproven via privacy-preserving verification. Likewise, businesses could prove what instructions an AI was deployed with, and whether sampled outputs comply with their published policies. Such practices would increase public trust in AI, even though they are inherently imperfect because our scientific understanding of AI behavior is in its early stages.

Finally, if you are concerned about society-scale risks connected to powerful AI, you have a personal interest in defusing arms race dynamics in AI development. Many experts worry that the continued race to build smarter AIs could lead to human extinction—including you and your family. 

If you are a frontier AI company or cloud provider:

If AI governance can achieve its goals with minimally invasive and privacy-preserving mechanisms, high-stakes issues (such as national security) can be resolved with less costly and heavy-handed regulation. 

Additionally, industry incentives can re-align towards race-to-the-top dynamics, where honest behaviour can be proven. Customers expect consistent service quality as advertised (e.g. serving models at a particular quantization), as well as security and privacy of their data. 

Verification can also improve public relations: “Here is evidence that we are acting responsibly with internally developed and deployed models, you do not need to take our word”

If you are a government official:‍

By default, government decision makers know basically nothing about frontier AI and little about how compute is used. If they want to know any specific detail, they have to write a letter to companies asking for information and giving them weeks to reply. And for the most part, this only works if companies operate within one’s own jurisdiction. State capacity faces challenges with keeping up with the pace of AI development. The government’s ability to obtain situational awareness and verify truth improves with its verification methods.

Verification can help make (AI) compute governance more efficient and consistent than case-by-case decisionmaking based on limited evidence. Evidence protected by strict confidentiality could still be used without a court order overriding that confidentiality, and such orders are difficult to obtain and enforce.

‍

Is this a dual-use technology that can also be used for surveillance?

A key objective of compute verification is to be privacy-preserving, not to extract information without the prover’s consent. In fact, without proper privacy-preserving tools, compute governance may face the decision of either not enforcing rules at all, needing certified people for accessing confidential data, or relying on legal deterrence without verification. In some scenarios, the incentives point towards secret defection, even if illegal (e.g. in a global treaty without verification, see the Biological Weapons Convention; see also the nuclear test ban story below). Unfortunately, even without compute verification, there are many existing government efforts to surveil citizens. Compute verification could exacerbate this risk in certain cases, but careful design and implementation would result in only a small increase in risk. Existing tools are applied aggressively to citizens, but in only a limited capacity to governments and companies. By contrast, compute verification is primarily concerned with whether governments and companies are engaging in illicit practices.  

‍

Why would the leading power ever restrain themselves?

An agreement restrains not only the leader but also the followers. The positive-sum benefits of mutually verified restraint can outweigh zero-sum competition under certain circumstances.

1. In AI governance this can be the case when de-escalating international relations takes priority, or when AI becomes increasingly difficult to align and control. If alignment fails on either the leader’s side or the challenger’s, it could be catastrophic for both.¹
2. Leads are narrow and unverifiable to their holder. A power that believes it is ahead is often uncertain by how much, and leads erode through espionage, algorithmic diffusion, and fast-following. Locking in verified constraints while ahead can be worth more than gambling on an uncertain lead. 
3. The leader can be incentivized (pressures and rewards), by the followers.

‍

How does it work?

Most approaches have in common that there exists some trusted entity between the prover and verifier that can access the confidential data and give correct, but strictly limited and pre-agreed disclosures to the verifier. This entity could be a mutually secure processor, or a collection of unilaterally secure processors checking each other, running code that both parties trust (or double-checked). It could also be institutional, e.g. trusted inspectors checking source code or hardware configuration.

We can distinguish between on-chip and off-chip mechanisms:

On-chip mechanisms are fabricated into the hardware used by the prover. For example, the prover could run their usual workloads in so-called Trusted Execution Environments (TEEs), which attest to their memory state (i.e. what code they are running) using a signing key only the hardware can access, not the prover. The digital signature of the TEE proves to the verifier what device has made the claim (if the key was not stolen). 

On-chip mechanisms attempt to meet the security requirements of both parties on one chip, while also being flexible and performant enough to be useful for the prover’s usual workloads. Against anything but amateur-level cyberattackers, this has proven fragile, at least for commercially available TEEs, which have a long history of being broken, even with attacks considered in-scope in their manufacturer’s threat models. Development and deployment of more secure on-chip mechanisms is expected to take at least a couple of years. 

Off-chip mechanisms use additional hardware separate from the chips used by the prover. This could be retrofitted analog sensors, confidential network loggers, memory pinging probes or similar. This can be separated even further into devices that only gather information, and other devices that evaluate it and publish disclosures. It would take months to a couple of years to develop and deploy these mechanisms at scale, depending on the specific mechanism. 

For more detailed information, see Verifying International Agreements on AI - RAND

‍

What does this cost the prover and verifier? 

A design goal of most compute verification approaches is to cost orders of magnitude less than the monitored hardware. If security requirements are extreme, this can be challenging. But modern AI racks can cost millions of dollars each, while network monitoring devices or memory pinging probes are more likely on the order of hundreds to single-digit thousands of dollars per rack.²

The scale of compute required to check the outputs of the prover’s cluster can be much smaller, for at least two reasons:

1. Random sampling. For example, a single server rack can re-compute a small selection of the inference throughput of an entire AI datacenter, while still giving strong statistical assurance.³
2. Retroactive verification. A computation that has already been performed can be cheaper to verify than the original computation was.⁴

‍

Why focus on hardware, not data or algorithms?

Hardware has a physical location and cannot be copied or transferred at the speed of light to the other side of the planet. For more detailed information, see Computing Power and the Governance of AI.

‍

Can't the prover just cheat? 

Verification measures rely on red-teaming during the R&D phase and either statistical deterrence during deployment (rather than perfect prevention), or outright prevention. 

The threat model is different compared to traditional cybersecurity: In cybersecurity, the defender holds a secret and needs to guard it against an attacker that can choose the time and approach of their attack and can try as many times as they want, until they succeed. The defender loses if the attacker breaches the defenses even once. 

In verification, the situation is inverted: The attacker loses if they are caught even once. The defender can layer multiple defenses, while the attacker would need to evade monitoring and verification at a relevant scale to even benefit from the attack. The risk-reward calculation from the attacker’s perspective includes the likelihood of detection, the reward of successful evasion, and the consequences in case of detection. For more details see this analysis.

‍

What about hidden datacenters and smuggled chips?

Tracking advanced semiconductors and accounting for their stock is technically more viable than tracking restricted narcotics or firearms, especially for AI hardware: The supply chain goes through several key bottlenecks in multiple nations, which can triangulate their own accounts against each other. This would require international collaboration of the nations involved in this supply chain. This, in turn, would require at least two nations to agree that chip smuggling and hidden datacenters are an important problem at all. Moreover, large-scale AI hardware diversion would be difficult to conceal, especially against nation-state level intelligence.

‍

What happens when a violation is detected?

There is a difference between verification and enforcement. But enforcement needs to be based on credible evidence, which is the goal of verification. Also, a verification mechanism raising suspicion does not necessarily prove violation. False positives are a concern as well as false negatives. Generally, one can:

1. Reduce both the false positive and false negative rates of the verification mechanisms before deployment
2. Establish a procedure for incremental disclosure, before deployment. In case of a suspected violation, the procedure prescribes how to resolve the dispute, via increasingly invasive investigation.

‍

Isn’t political will the real blocker?

Typically yes, but not always. Treaties are written around what can be verified. When verification technology improves, rules that were previously off the table become negotiable. 

The 1963 Limited Test Ban Treaty prohibited nuclear tests in the atmosphere, underwater and in outer space, but not underground: seismic monitoring could not yet reliably distinguish underground explosions from earthquakes, and the parties could not agree on on-site inspections to resolve ambiguous events. One bottleneck was computational: computers of that time could not process the seismic data quickly enough.

This changed with the Fast Fourier Transform, now foundational to digital signal processing far beyond seismology (the full story). Seismic verification matured over the following decades and helped negotiators reach the 1974 Threshold Test Ban Treaty and the Comprehensive Nuclear-Test-Ban Treaty,⁵ whose International Monitoring System watches for underground tests worldwide today. 

AI compute verification aims to do for AI agreements what seismology did for the test ban. 

‍

When will the mechanisms be ready for an AI assurance agreement?

It depends on the mechanism: the more sophisticated the verification mechanisms become, the more robustly such agreements can be verified, with less invasive measures. A progression may look as follows: From having to turn off chips, to only pausing training of new models, to running verified training runs, to conducting controlled and supervised automated AI research at a controlled pace. The better verification technology gets, the more options are on the table.

As of July 2026, research is in the testing and de-risking phase for retrofittable off-chip mechanisms, while TEEs are incrementally being improved by industry. This means that if we had to globally verify compliance with some rule (e.g. slowing down automated AI research), with currently available mechanisms, the necessary measures would be heavy-handed and costly, in order to be reliably enforced. 

The speed at which R&D progresses towards better solutions, like a quickly and cheaply retrofittable “datacenter lie detector”, depends on political will, funding, the influx of the right kind of talent, institutional buy-in and your support!

For an overview of some ongoing research on off-chip mechanisms, see section 5 of this working paper.

‍

Who is working on this?

The majority of work on compute verification is commercial and focused on TEEs or secure software. 

AI compute verification, with threat models adequate for international agreements, is a tiny field of ~30-50 people and even fewer full-time employee equivalents, as of July 2026. The field heavily leans towards non-profit organizations (not exclusively, though), philanthropic funding, and early-career researchers.

Senior technical talent with experience in security and the cloud industry are underrepresented and would be highly valuable additions to the field.

‍

How can I help?

Get involved!

Interest in verification work is growing, but the development of technical demos and a proper research community is still in its infant stages and bottlenecked by talent, funding, and coordination capacity.

This is a field where a single person with the right skills can move the needle. We need:

• Engineers and scientists: FPGA engineers, datacenter networking engineers, silicon photonics experts, analog/mixed-signal engineers, cryptographers, formal verification researchers, ML systems engineers, cybersecurity and hardware security specialists, high-frequency trading hardware specialists and independent hackers who love to build and break things.
• Entrepreneurs and founders: Enterprise sales people, venture capitalists, public grantmakers and incubators, and established companies opening up new product lines. This is in order to prepare the supply chains and business ecosystems and precedents needed to scale up deployment. Verification can have purely commercial use cases, for example for demonstrating faithful genAI inference.
• Policy and diplomacy: Technology policy researchers, arms control and treaty verification veterans, diplomats, and people with expertise in, or connections to, the Chinese AI ecosystem.
• Funding and operations: Funders, fundraisers, and program managers who can help coordinate a distributed research effort.

If any of this describes you, or if you bring adjacent skills and learn fast, reach out.

‍

Footnotes

1 In 1969, the United States unilaterally renounced its development program of biological weapons. Richard Nixon: “[Biological weapons] have "massive, unpredictable and potentially uncontrollable consequences”. While biological weapons are less generally useful than AI, mutual restraint may target specific high-risk development choices, such as training models to conceal capabilities from evaluators, or deliberately instilling open-ended power-seeking objectives. 

Note that the lack of reliable verification prevented an agreement: the renunciation was unverified, and it failed in both directions. The Soviets believed Nixon's renunciation was a hoax designed to conceal a covert offensive program, and the United States began to suspect almost immediately that the Soviet Union was continuing its offensive BW program in secret, which later turned out to be the case.

2 For more details, see this paper on network monitoring-based verification, or this essay on network taps. In contrast to evidence-capture devices, verification compute does not scale with the prover’s compute, because of the statistics of random sampling. 

3 See the appendix of this working paper.

4 For example, a prompt completion generated by the prover, in decode inference, can be verified by re-computing in prefill mode. Additionally, compliance checks may use content moderation algorithms that are far more lightweight than the inference model. This is precedented in most customer-facing genAI deployments (see e.g., Anthropic’s classifiers).

5 Adopted by the UN General Assembly, though not officially enforced. De-facto, international monitoring has established a taboo.

‍