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 II proposes two ways to record and check workloads ²:

• Compute graphs. A developer declares the operations and data transfers that produce each block of data. A static declaration describes the whole workload before it runs. A dynamic declaration records operations as they execute, including data-dependent control flow. The guarantee processor would check those declarations through observed transfers or sampled recomputation ².
• Distributed FLOP accounting. Assuming an accurate local FLOP tally, each Interlock records the accelerator sessions that could have influenced its local data. Transfers carry these histories, and receivers keep the highest count per source to avoid counting the same work twice. External inputs still need safeguards against hidden results of earlier computation ².

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 flexHEG 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 ⁴.