How could the US and China verifiably slow AI?

In order to verify measurements of AI training runs, it is important to understand the size and configuration of the clusters they ran on. (O’Gara et al.) AI training relies on being able to interconnect many pieces of individual compute into a high-bandwidth interconnected cluster. It makes sense to restrict the ability of any unauthorized actor to illicitly aggregate AI chips into large scale clusters if doing so would enable those chips to cause much more harm. There are two basic known approaches to doing so.

One — chips could be sold in a fixed set, where they are only authorized to interconnect with the other chips in that pod. The chips would perform tests to check for unauthorized changes, and shut themselves down if they detected them. The bandwidth with devices outside the pod would be significantly limited.

Two — chips could use a software adjustable cap, where each chip uses public-key cryptography to determine how many chips it is in communication with, so it can limit its number of interconnections to be within an authorized cap. (O’Gara et al.)

This approach has a few problems in each form. Existing cluster-management software could potentially be adapted to do either of these jobs, but it would be easier to tamper with, and might struggle with uneven network topologies and hardware heterogeneity. Fixed pods would struggle with individual chip attrition, and adjustable-cap systems could have the cap enforcement mechanism targeted. (O’Gara et al.)

Small numbers of breaches between ‘separate clusters’ in particular could enable illicit reinforcement learning, which is a major part of current AI training runs, and is easier to parallelize. RL can be distributed across multiple ‘separate’ data centers with a small number of leaks of weights. A small number of leaks is less dangerous where frequent weight transfers are a constraint.

Any treaty setting controls in hardware would need the physical mechanisms to do so to exist. Right now, no AI chips exist that are designed to be in compliance with a bilateral US-China AI treaty. Policymakers have a variety of tools available here, some of which are more or less mature. Here are some of the ones that are important, in rough order of ascending complexity.

A monotonic counter is a counter which stores its state when powered off, and whose value can only go up, like license numbers, or the total number of FLOPs run on the chip. The count stored on the chip cannot be artificially lowerable for the chip to be useful. One possible approach to implementing this stores fast-changing values in volatile SRAM (which requires continuous power), but writes them to flash memory if power is removed (this requires a capacitor to store power). For somewhat less fast-changing values (slower than counting, say, operations performed), flash memory alone could work. For quantities that are updated very infrequently, like license numbers, unary counting could be used, where fuses are burned sequentially to represent each increment.

Any hardware governance mechanism, whether chip licenses, cluster size limits, workload verifiers, or location trackers, needs a way to store data like cryptographic keys, in a way resistant to external alteration, and that doesn’t disappear if the chip loses power. This may be read-only, like for cryptographic keys, or it may be dynamic, for example for tracking compute graphs. Ideally, based on my reasoning, it should be tamper-evident to external inspectors. (O’Gara et al.)

Any attempt to make, for example, hardware that checks regularly for if new limits have been imposed on the size of interconnected clusters, relies on the hardware being able to tell the time in ways resistant to attack (which it could respond to by, for example, deleting necessary private keys). You could increment a monotonic counter at a continuous fixed rate, for example. This would need to be secured against tampering from factors like power supply or environmental interference. (O’Gara et al.)

It is essential for the physical components of all of these systems to be secured from tampering by adversaries. There are three complementary approaches to this — making tampering with compute harder, making the hardware tamper-evident to inspectors, and making hardware respond to tampering in ways that lower the payoff. (O’Gara et al.) Most of this is not mature, as “much of the existing literature on hardware security focuses on different threat models and target hardware, such as low-power smart cards and microcontrollers” — and wasn’t designed for faster AI chips that draw more power and utilize complex packaging. Adapting existing techniques to AI chips “may require substantial work”. (O’Gara et al., §3.2.2)

These could include mounting components in ways that reveal if they have been disassembled, and adapting existing anti-tamper chip envelopes for AI data centers. Video surveillance of data centers is also a potentially valuable tool. (O’Gara et al.)

A chip could be equipped with sensors to monitor the properties of its enclosure, and be designed to wipe itself if those properties (capacitance, resistance) change. The cryptographic keys inside the chip could be PUFs (physical unclonable functions) that are derived from attributes of the enclosure, which would be required to decrypt key operating parts of the software so the chip could operate. Memory components could potentially be designed to wipe themselves if they detects unauthorized access attempts. In addition, all of this could be made out of materials that are hard to work with, to make it harder to scale up device-modifying industrial processes.

Trusted execution environments are currently hardware features used in cloud computing, which enable cloud providers to run programs for customers without being able to see them. They could serve a variety of uses if adapted to hardware governance, including metering chip usage, implementing chip location verification, or to run model evaluations or sign what proportion of a lab’s compute was used for inference versus training (O’Gara et al.). This adaptation could take the approach of a separate component to the AI chip, or it could be incorporated into the chip. Existing TEEs could potentially leak sensitive information to adversaries, and existing TEEs are not designed to be secure against adversaries with unsupervised physical access. There are various proposals on hardware that would address these challenges, including the FlexHEG (Flexible Hardware-Enabled Guarantees) project.

This proposal envisions the FlexHEG as a general-purpose computer designed to be retrofittable onto existing AI chips, with many of the features discussed above, like tamper-resistant enclosures (Petrie et al.). It is designed both to be able to let users verify what their chip has been used for, and enforce rules on how the chip will be used, using a built-in ruleset agreed to by countries party to a governance regime. (Petrie et al.) Crucially, this ruleset could be updated over time as circumstances change, letting the existing hardware respond to new threats. The ruleset could be made to only update after multilateral consensus is reached (say using private keys held by multiple nations) (Petrie et al.). This device could verify the architectures, training techniques, and compute quantities used in training (Petrie et al.). It could also, by encrypting the weights on the chip and only being able to run specific sets of weights, limit the ability of states to gain from deploying noncompliant models (Petrie et al.). Hardware like this would need to be open-source, so all parties to a treaty could inspect it for errors, and it and the software running on it would need to be extremely secure. And developing it may require a multi-year lead time. It may be possible to speed some parts of this up with AI. OpenAI, for example, was able to move their Jalapeño chip from digital logic to tape-out in roughly nine months, largely due to their internal models being able to significantly accelerate the software-shaped parts of chip development. Current models may be able to significantly accelerate hardware design as well.

Ravi Krishna says that OpenAI’s approach to backend design already feels a bit conservative. He believes that to be an artifact of when the project, which began in October of 2024, took place. “The models from the last four to five months have improved. From April [2026] onwards…is when they really started to be able to handle those tasks better.”

From the perspective of an American or Chinese policymaker, if you want to slow down or pause AI, you have a variety of instruments you can use to make a binding agreement. Each of them has ways it could be subverted or fail. Some of them could be available quickly, while others have long lead times. In many possible cases, the impetus for such a treaty could be a sudden warning shot that leaves little time for a complicated initial bargain. The HuggingFace incident was an early version of this, but the response to it was limited by the fact real-world economic damage was quite small. Let’s assume something like this happens with large impact — say a wave of AI-enabled cyberattacks begins threatening power grids and the global financial system, and the US and Chinese leadership think further racing would be too dangerous. The communication could start at the bilateral US-China AI communication channel that’s devloping from the September 2026 Trump-Xi summit.

Such an agreement could begin with verifying how much compute each party has and where, and pausing bringing new compute online. The US and China could use satellite imagery to track where new data center construction is being done, and use customs, permitting, financial, and other records, to try and pin down where as many of the AI chips each party has produced as possible are deployed. The goal of this would be to prevent the accumulation of undeclared compute stockpiles that could be used for a future breakout. I think it would be possible to supplement this with random on-site inspection of supply chains. To give an example, if your public data have established that chips C, C’, C’‘ .... from factory F have been installed in data center D, and you want to check nation N hasn’t been spoofing records to make a secret stockpile, you can go over to D to check some subset of its chips for compliance at random. The following factors mean this would decrease the payoff of spoofing a lot.

The US and China would also start tracking the supply chain of new compute, so they could establish it wasn’t going to non-declared stockpiles, which could be inspected in the same way.

Remote sensing could tell you if new undeclared data centers are being built at large scale. However, none of this will tell you what is being done with the compute that already exists, before hardware methods come online. The two simplest ways to handle this are by shutting existing clusters down or by making them only be able to run existing AI models and not develop new ones. The former method would be easy to verify through remote sensing of data center power consumption and thermal emissions. If, say, 90% of each side’s compute were shut down, this would significantly slow any defection attempts, while preserving some older capabilities through distillation. However, it would likely cause significant economic pain. The latter method could be verified without hardware, through cluster-level software, as well as spies, whistleblowers, and AI developer inspections. Simpler hardware could be developed more quickly, like using dumb network taps to log hashes of ML activity, so you could rerun the covered operations in a trusted environment later to check for compliance.

By the time such an agreement is possible, the US may have a system of embedded auditors used to disclose insight into frontier labs for the US public. I don’t think this is directly transferable t