The landscape of AI verification

When people talk about AI “verification”, it can often be hard to know exactly what they mean. The word is trying to cover a lot: verifying the safety evaluation run by a cooperative lab, which is relatively easy; and verifying that a nation-state didn’t train an advanced model against the terms of a treaty, which is hard. Because of that confusion, and to solidify in my own mind the value of particular verification tools, I have found it useful to take a step back to map out the landscape of verification and the threat models it intends to engage with.

This classification is pretty shoddy, and may have inaccuracies, but gives a rough idea/starting point for thinking. I always welcome feedback.

Forms of verification

Verification is usually introduced as treaty enforcement, but that’s only one pathway to reducing risk. There are in fact several, of which a few are:

• International agreements: To reduce race dynamics, verification lets states detect violations of an AI limitation treaty, thereby making the treaty credibly enforceable.
• Transparency measures: To mitigate risks of proactive attacks from an adversary that feels threatened by AI, verification allows for credible disclosure that AI remains within some set of red lines.¹
• Domestic oversight: To lower risks of a frontier lab releasing unsafe models, verification allows a regulator to detect anomalies in data centers that indicate unsafe AI training.

¹ Jervis, “Cooperation Under the Security Dilemma” (World Politics 30, 1978), is the classic account of reassurance defusing a spiral. Hendrycks, Schmidt & Wang, Superintelligence Strategy (2025), arXiv:2503.05628, discusses this scenario for AI. Assuring a rival about what your AI will and won’t do is harder than accounting for how much compute you spent, and destabilising uses may not need much compute.

There may also be secondary benefits to some verification tools being deployed, such as increasing security of model weights.

Models of verification

A verification system in general combines two things:

• Declarations: claims that things have been done in compliance with an agreement (can be implicit), or more specific reporting on activities.
• Verification measures: tools that are deployed to verify the declarations.

Different sets of tools promise to give different assurance about, and enable verification of, different declarations:

• Attestable audits: Runs evaluations inside trusted execution environments (TEEs). This allows for domestic oversight, but does not catch covert training.²
• Compute verification: Uses chip-activity logging or off-chip network taps, analog sensors, and partial re-execution. This set of off-chip tools can verify declared compute.³
• FlexHEG: A “guarantee processor” in a tamper-evident enclosure. This processor allows for limitations on compute, verification of evaluation, controlled deployment, and even automated enforcement.⁴
• A full treaty regime: All of the above and more, likely managed by an international agency.

² Schnabl, Hugenroth, Marino & Beresford, Attestable Audits (2025), arXiv:2506.23706.

³ Shavit, What Does It Take to Catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring (2023), arXiv:2303.11341.

⁴ Petrie, Aarne, Ammann & Dalrymple, Flexible Hardware-Enabled Guarantees for AI Compute (2025), arXiv:2506.15093.

⁵ Mentioned in Six Layers of Verification.

The application of different tools, and at different jurisdictional levels of enforcement, are best thought of with reference to the threat models they intend to address. As you may naturally expect, the most robust tools are also the least ready to be deployed, and we are not completely confident they are feasible in practice.⁵

Additionally, more robust tooling comes with a need to verify the robustness of the tooling itself to adversarial uses, including siphoning of model weights or other protected data.⁶

⁶ Baker, Kulp, Marks, Brundage & Heim, Verifying International Agreements on AI: Six Layers of Verification (2025), arXiv:2507.15916.

My takehome thoughts

Thinking this through, I notice that there are multiple entry points to starting to do verification, and weaker options can be worth considering for many reasons. They may add to the toolkit for domestic oversight – building capacity for verification, finding and patching issues with the tools, and helping to identify further holes in their use. They may be a proof of concept that drives appetite for stronger verification. If a specific country adopts weaker verification, they may even crowd in expertise and funding, helping to build production-ready tools for other countries.

All in all, it is worth continuing to consider the opportunities for doing less robust verification sooner, while we keep working to build out the toolkit for robust verification.