Mechanism · Hardware-enabled guarantees (flexHEG) and guarantee processors
Evidence & limits
On this page
R1Proposed for checking and enforcing training-compute limits on chips, against adversaries up to states
The design is detailed, but nothing has been built or tested in public.
Assessed use: checking and enforcing training-compute limits on chips, against adversaries up to states
Rubric assessment
- R1 met: the flexHEG series sets out the components, the claims that could be verified or enforced, the update governance and a threat model that includes state-level adversaries 1 2 4. RAND and CNAS describe related HEM designs and their threats 5 6.
- R2 not met. As of September 2026 no public implementation or reproducible end-to-end results have been published, and no Implementation record realises this mechanism. Part II mentions that "an existing FlexHEG prototype" uses high-resolution power measurements, but gives no details or results 2. Claimed results that are not public do not count. Because that prototype could not be checked, confidence is medium rather than high.
- A public prototype of a guarantee processor or Interlock on a real accelerator data path, with published end-to-end results.
- A secure enclosure evaluated against invasive physical attacks, with published cost-to-circumvent estimates.
- A specified ruleset language and a multi-party update protocol implemented and analysed.
- Chipmaker engagement, needed for integrated designs.
Assessed 2026-09-25 against rubric v1.1.
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 6. 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" 2.
- Prototype. Part II says that "an existing FlexHEG prototype uses high resolution power measurements", with no further detail 2.
- Related work. Part II notes TEE-based efforts by Mithril Security and EQTY Lab 2.
- 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 7.
Limitations
- Enclosures. The authors write that nation-state attackers "can likely compromise the best current secure enclosures" 2.
- Retrofits. Designs that rely on Secure Boot are exposed to voltage glitching and probing 2.
- 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" 1.
- Algorithmic efficiency. Gains lower the compute needed for a given capability over time 4.
- Chipmaker position. An August 2025 NVIDIA blog post states that NVIDIA GPUs "do not and should not have kill switches and backdoors". It distinguishes optional software features controlled by the user from a kill switch hardwired into a chip 8.
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.
Known flaws
- State attackers can likely defeat current secure enclosures
- Firmware-only retrofits rely on Secure Boot, which fault injection can bypass
- Many important rules cannot be checked on-chip
- FLOP accounting can be laundered through external data
- Supply-chain diversion and hidden backdoors
- Coverage stops at flexHEG-equipped chips
Blockers
Integrated flexHEG needs substantial help from the accelerator manufacturer, and the authors estimate 3.7–7.9 years, from when the manufacturer starts work, for such hardware to displace other accelerators in frontier development.
State-level attackers who hold the hardware can likely compromise the best current secure enclosures.
Rival states would need to trust the design and manufacture of guarantee processors and enclosures, for example through open design, redundant processors from each side or oversight of production.
Restricting future rule updates would need a formal language for rules, which the authors judge most likely infeasible for early flexHEG versions.
Governing all relevant chips depends on knowing where they are, through chip registries and detection of undeclared facilities.