Hardware-enabled guarantees (flexHEG) and guarantee processors

How it works

RAND defines hardware-enabled governance mechanisms (HEMs) as controls built into AI hardware that enable "enforcement and compliance verification" of policies ⁵. It analyses two designs ⁵:

• Offline licensing lets a GPU run a set amount of work under a renewable license, then refuse or slow further work.
• The fixed set limits high-bandwidth links to a small pod of pre-authorized chips.

CNAS proposes a hardened security module that enforces valid firmware and up-to-date operating licenses and supports remote attestation. It would be rolled out in stages, from firmware changes to tamper-evident and then tamper-proof hardware ⁶. An interdisciplinary workshop report by O'Gara et al. discusses HEMs for four uses: verifiable AI training and inference, verifiable cluster configuration, location verification and offline licensing ⁷.

flexHEG (flexible hardware-enabled guarantees) combines two components ¹:

• Guarantee processor: "an open-source, standardized, general-purpose processor that sits between the AI chip and the rest of the world". It can see all information and instructions going to and from the chip ¹.
• Secure enclosure: it houses the chip and the guarantee processor. If tampering is detected, secrets are wiped ¹.

When the guarantee processor sits directly on the data path, the design is called an Interlock. As the only way in, it can monitor or control the flow and encrypt data leaving the enclosure ². The rules it applies form a ruleset, which anyone from the chip's owner alone up to "a quorum of states" might set ¹. Changes could require k-of-n approval, and periodic licenses could force devices to stay current ².

Part II of the flexHEG series describes a range of implementations ²:

• Integrated hardware, built into the accelerator by its manufacturer.
• Retrofits, such as modified firmware or a replacement network interface card acting as the Interlock.
• TEE-backed software, which Part II judges relatively fast to deploy but probably not secure against sophisticated actors with unrestricted physical access.

Part III contrasts two kinds of agreement. In verification-based agreements, states detect violations and retaliate. In ruleset-based agreements, the devices enforce the rules and no state can rewrite them alone ⁴.

What it establishes

The authors list claims flexHEG could support ¹:

• the total compute used to train a model;
• whether a model's score on an automated test stayed below, or rose above, an agreed level;
• deployment only to approved devices;
• a chip's approximate location;
• which architectures and training techniques were used.

A guarantee processor could also block any operation that would push a training run past a threshold ¹.

It cannot establish:

• intent or downstream misuse, which is not observable on the chip ¹;
• whether a network is the whole system or one expert in a larger one ¹;
• a true FLOP count if earlier results are hidden in external inputs ²;
• anything about compute without flexHEG hardware ^{1 4}.

Fully automatic, on-device compliance checking "appears unlikely to be feasible" ¹. Part III therefore discusses compromises that combine enforced rules with verification ⁴.

Threat model

In international use, "the primary attackers ... are the participating states themselves" ⁴. Devices would need to be open source, auditable and "robust to tampering even from state-level adversaries" ¹. CNAS stresses that existing features "need to be hardened" before adversarial use ⁶.

RAND defines three kinds of threat actor: unsubsidized commercial, state-subsidized commercial, and state. It groups attacks into four classes ⁵:

• non-invasive, for example side channels;
• semi-invasive, such as fault injection;
• fully invasive, such as focused ion beams and electron microscopy;
• non-physical, including design theft and cryptographic, firmware, supply-chain and resource-pooling attacks.

The design also assumes a trustworthy supply chain. Part III proposes manufacturing equipment locked to standard designs, independent testing, camera oversight, tamper-evident shipping, and extensive testing and detailed physical imaging of a random sample of finished devices ⁴.

Evidence

• Design reports. RAND and CNAS published design and analysis reports in 2024 ^{5 6}. The three flexHEG parts followed in 2025, commissioned by ARIA ^{1 2 4}.
• Timelines. CNAS estimates that the needed hardware security could take as little as 18 months, and up to 4 years, of technical effort by leading firms ⁶. Part II estimates 3.7–7.9 years for integrated flexHEG to displace other accelerators at the frontier, counted from when a manufacturer starts work. It argues that to reach its full potential, flexHEG would likely need to be deployed at scale "by 2027 or sooner" ².
• Prototype. Part II says that "an existing FlexHEG prototype uses high resolution power measurements", with no further detail ².
• Related work. Part II notes TEE-based efforts by Mithril Security and EQTY Lab ².
• Open questions. O'Gara et al. ask how to verify license authenticity at scale and how to attest the integrity of fixed-set pods remotely ⁷.

Limitations

• Enclosures. The authors write that nation-state attackers "can likely compromise the best current secure enclosures" ².
• Retrofits. Designs that rely on Secure Boot are exposed to voltage glitching and probing ².
• Supply chain. Diversion and backdoors are open problems ^{2 4}.
• Evaluations. Making capability evaluations robust to models trained to underperform is "a very difficult open problem" ¹.
• Algorithmic efficiency. Gains lower the compute needed for a given capability over time ⁴.

Physical protection is covered in Tamper evidence for verifier devices, interconnect limits in Bandwidth limits and compartmentalization and throttling in Hardware performance throttling and licensing.