Consortium forVerified Computing

M-0009 / On-chip & hardware

Hardware-enabled guarantees (flexHEG) and guarantee processors

Proposed chip add-ons, a guarantee processor inside a tamper-protected enclosure, that would check and enforce agreed rules on how AI accelerators are used.

R1 ProposedSource reviewed 2026-09-25

01 / The mechanism and its boundary

What the technique establishes

flexHEG (flexible hardware-enabled guarantees) is a proposed chip add-on that pairs an open, auditable guarantee processor, which sees all data and instructions going to and from an AI accelerator, with a secure enclosure that reveals or responds to tampering. Like other hardware-enabled governance mechanisms, it would let a verifier check, or the chip itself enforce, rules about how AI compute is used. Rule changes, such as to a cap on training compute, could require approval from several parties. RAND and CNAS describe related designs, such as offline licensing. All are designs; the one prototype mentioned is unpublished. The main obstacles are physical security against state attackers, chipmaker cooperation, and international trust in chip design and manufacturing. The authors estimate that integrated hardware would take 3.7–7.9 years from the start of chipmaker work to displace other accelerators at the frontier. Whether a use is malicious cannot be checked on the chip.

Threat model
Adversarial prover
Adversarial evaluation
Published analysis
Hardware needed
New chip design
Prover cooperation
Required
Confidentiality
Preserving
Category
On chip & hardware
Technical detail and cited results
  • Interlock. A flexHEG component on the data path is called an Interlock. As the only path for data and instructions into the accelerator, it could monitor or control that flow and encrypt what leaves the enclosure. The candidate points are HBM, NVLink, PCIe and the cluster NIC S-1204.
  • Encryption cost. Part II roughly estimates that encrypting all NVLink traffic with AES-256-GCM would take about 3% of computing power, energy or board space, and encrypting all HBM traffic about 11% of power S-1204.
  • Checking and logging. Part II estimates that for a guarantee processor to double-check one streaming multiprocessor (SM) of a Blackwell chip would take roughly 1/192 of the chip's compute, assuming 192 SMs per chip S-1204. NVIDIA states that the Blackwell GPUs in its HGX B200 system normally have 148 SMs S-1611. Storing a FLOP log for 1M unique sources, such as a very large cluster, would take roughly 30 MB S-1204.
  • Updates. An update, or the lack of one, could require approval by k of n parties. Periodic licenses could specify a minimum firmware version, and signatures should ideally be quantum-resistant S-1204. A guarantee processor could be required to install a firmware update regularly, for example every three months, or it would block the chip S-0035.
  • Enclosure. Tamper evidence is sufficient for verification, while guarantees about future use need tamper response. Options include capacitor discharge or antifuses that disable the chip, PUF-derived keys, and sensors for radiation, voltage glitching, lasers and temperature S-1204.
  • Manufacturing oversight. Part III proposes extensive testing of a random sample, for example 1/1000 of finished devices, which would give a 63% chance of catching a batch of 1000 compromised devices at that stage S-1205.
  • RAND designs. An offline license might authorize 10^18 operations before the GPU falls back to 1% performance. A "fixed set" restricts high-bandwidth links to pre-authorized pods of fewer than 65 chips S-0057.

Claims and scope

A direct link identifies the intended claim. A supporting link supplies part of the evidence. Neither establishes that a complete verification system has been demonstrated.

Readiness for a stated use

R1 Proposed

Assessed use: checking and enforcing training-compute limits on chips, against adversaries up to states

medium confidence · current · assessed 2026-09-25 · rubric 1.1

This is the source map’s editorial assessment. Production use is not evidence of resistance to every adversary.

The design is detailed, but nothing has been built or tested in public.

  • 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 S-0035 S-1204 S-1205. RAND and CNAS describe related HEM designs and their threats S-0057 S-0056.
  • 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 S-1204. Claimed results that are not public do not count. Because that prototype could not be checked, confidence is medium rather than high.

Evidence needed for the next level

  • 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.

Limitations, flaws, and blockers

These are attributed assessments from the source map. Absence of a listed flaw is not a security guarantee.

significant / open / theoretical argument

State attackers can likely defeat current secure enclosures

The flexHEG authors write that "nation-state attackers can likely compromise the best current secure enclosures", and that the marginal cost of circumvention per device is hard to estimate S-1204. RAND similarly judges that anti-tamper measures "would not be insurmountable for a determined and well-resourced adversary", although they raise costs and can reveal tampering S-0057.

S-1204S-0057

significant / open / theoretical argument

Firmware-only retrofits rely on Secure Boot, which fault injection can bypass

Part II notes that the most common attack on Secure Boot replaces the firmware and applies a voltage glitch while the signature is being checked. It also notes that sophisticated actors may use microprobing or laser voltage probing to read key registers S-1204.

S-1204

significant / open / theoretical argument

Many important rules cannot be checked on-chip

Malicious intent "is not a technical property observable on-chip", and misuse depends on what is done with a computation's results S-0035. A guarantee processor cannot easily tell whether a network is the whole system or one expert in a mixture-of-experts system S-0035. Part III judges that a fully local ruleset "may not be entirely feasible" for the same reason S-1205.

S-0035S-1205

significant / open / theoretical argument

FLOP accounting can be laundered through external data

Results of earlier or parallel workloads could be hidden in the "external data" fed to a device, which would falsify the total FLOP count unless the inputs are explained or time delays are imposed S-1204.

S-1204

significant / open / open question

Supply-chain diversion and hidden backdoors

Components could be diverted before a guarantee processor is added, and backdoors could be introduced during design or manufacturing. Open-source designs and physical scans of randomly selected chips are proposed as countermeasures S-1204. Part III proposes international oversight of production and extensive testing of a random sample of finished devices S-1205.

S-1204S-1205

significant / open / open question

Coverage stops at flexHEG-equipped chips

Motivated actors will always be able to use some compute that is not flexHEG-equipped S-0035. Recalling existing consumer GPUs would likely be impractical, and reaching perfect coverage, or conclusively proving that no secret government data centres exist, would be "practically quite difficult" S-1205.

S-0035S-1205

What still blocks use or stronger assurance

  1. 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.

    S-1204

  2. State-level attackers who hold the hardware can likely compromise the best current secure enclosures.

    Dependency: Tamper evidence for verifier devices

    S-1204S-0057

  3. 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.

    S-1205S-0035

  4. Restricting future rule updates would need a formal language for rules, which the authors judge most likely infeasible for early flexHEG versions.

    S-0035

  5. Governing all relevant chips depends on knowing where they are, through chip registries and detection of undeclared facilities.

    Dependency: Chip registries and manufacturing records

    S-1205

Connections in the research map

Depends on

Complementary techniques

Alternative approaches

Concepts used

Organizations and developers

The Consortium’s case files

Related editorial reviews use the Consortium’s own descriptive scores and review dates. Their scores are separate from the atlas readiness rubric.

OS-00 / ControlTen thousand off-switchesRead case file ↗FM-04 / ControlMandatory firmware enlightenmentRead case file ↗HG-08 / ControlPolicy, but make it a peripheralRead case file ↗

Sources and provenance

  1. S-0035 / Tier B

    Flexible Hardware-Enabled Guarantees for AI Compute ↗

    J. Petrie, O. Aarne, N. Ammann, D. Dalrymple · 2025 · arXiv

    Supports: flexHEG definition, components, verifiable claims, rulesets, update restriction, limitations, relation to confidential computing

    Locator: Executive Summary; Conceptual Overview; Appendix A-B

    Version and catalogue details
  2. S-1204 / Tier B

    Technical Options for Flexible Hardware-Enabled Guarantees ↗

    J. Petrie, O. Aarne · 2025 · arXiv

    Supports: Interlock, secure enclosure, integration options, update authorization, overhead estimates (including the 1/192 SM estimate and its 192-SM assumption), timelines, prototype mention, attacks

    Locator: sections on Interlock-Based Design, Secure Enclosure, Potential Accelerator Modifications

    Version and catalogue details
  3. S-1611 / Tier B

    Boost GPU Memory Performance with No Code Changes Using NVIDIA CUDA MPS ↗

    S. Nassernia · 2025 · NVIDIA Technical Blog

    Supports: NVIDIA states that the Blackwell GPUs in an HGX B200 system normally have 148 SMs

    Locator: MLOPart section

    Version and catalogue details
  4. S-1205 / Tier B

    International Security Applications of Flexible Hardware-Enabled Guarantees ↗

    O. Aarne, J. Petrie · 2025 · arXiv

    Supports: verification- vs ruleset-based agreements, states as primary attackers, redundant processors, manufacturing oversight and sampling, coverage limits, algorithmic efficiency

    Locator: Creating an Internationally Trustworthy FlexHEG Ecosystem; Overseeing Production

    Version and catalogue details
  5. S-0057 / Tier B

    Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090 ↗

    G. Kulp, D. Gonzales, E. Smith, L. Heim, P. Puri, M. J. D. Vermeer, Z. Winkelman · 2024 · RAND Corporation

    Supports: HEM definition, offline licensing and fixed set, threat actor tiers, attack classes, anti-tamper limits

    Locator: pp. viii-x, 4, 19-27

    Version and catalogue details
  6. S-0056 / Tier B

    Secure, Governable Chips: Using On-Chip Mechanisms to Manage National Security Risks from AI & Advanced Computing ↗

    O. Aarne, T. Fist, C. Withers · 2024 · Center for a New American Security

    Supports: on-chip governance with existing features, hardening need, 18 months to 4 years estimate

    Locator: Key findings

    Version and catalogue details
  7. S-0006 / Tier B

    Hardware-Enabled Mechanisms for Verifying Responsible AI Development ↗

    A. O'Gara, G. Kulp, W. Hodgkins, J. Petrie, V. Immler, A. Aysu, K. Basu, S. Bhasin, S. Picek, A. Srivastava · 2025 · arXiv

    Supports: workshop agenda on HEMs (four uses) and open questions on licensing and pod attestation

    Locator: §2; §2.3.4, §2.5.4

    Version and catalogue details
  8. S-3162 / Tier B

    No Backdoors. No Kill Switches. No Spyware. ↗

    D. Reber Jr. · 2025 · NVIDIA Blog

    Supports: NVIDIA's stated position that its GPUs do not and should not have kill switches, and its distinction for optional user-controlled features

    Locator: blog post

    Version and catalogue details
Source review date
2026-09-25
Drafted by (source map)
ai
Review handles (source map)
codex-review