Case file FS-03ControlMaturity: ProposedReviewed 2026-08-22

Mechanism under review

The approved friend group

Fixed Set is a proposed export-control mechanism for limiting the scale of accelerator clusters without prohibiting the export of every useful chip. A root of trust admits high-bandwidth communication only among a preauthorised pod, while communication beyond that pod is throttled. This can enforce a network topology if every consequential path is covered; it does not by itself establish what computation occurs or whether a slower, wider system remains capable enough.

Read primary source ↗

Adversary realism5/5

Explicitly adversarial

The source models commercial, state-supported and state attackers with physical custody, and assumes sufficiently resourced protection can ultimately be circumvented.

Trusted dependencies5/5

System-wide

The claim depends on identity, firmware, every relevant interconnect, parameter-setting, physical security and fleet coverage composing correctly.

Policy reach4/5

Export-scale

It would constrain cluster architecture after sale across consumer and data-centre products, while stopping short of inspecting workload content.

01Mechanism under review

Keep exported accelerators useful in small systems while preventing their aggregation into a frontier-scale supercomputer.

01
Preauthorise a small set of chip identities and bind the set to a hardware root of trust.
02
Permit unrestricted high-bandwidth links only among members of that set.
03
Throttle every communication path outside the set to a policy-defined bandwidth ceiling.
04
Use integrity checks, secure firmware and possibly remote attestation so unauthorised membership or configuration changes cause refusal to operate.

Technical output

A hardware-enforced claim about which devices may exchange data at high bandwidth, plus an external-bandwidth ceiling for the covered system.

02Claim boundary

What the primitive says—and what it does not.

Can establish

The covered interconnect accepted only preauthorised peer identities.
Covered external traffic remained below the configured bandwidth limit.
A detected unauthorised configuration can trigger refusal to operate.

Remains external

Whether every usable communication path, including CPUs, NICs, switches and storage paths, is actually covered.
Whether the chosen pod size and bandwidth ceiling prevent a policy-relevant training run as algorithms change.
Whether unrestricted, older or indigenous hardware supplies an adequate substitute.
Whether the authorised set and export policy are legitimate, current or correctly administered.

03Threat model in scope

Protected asset

The peer-membership restriction, external-bandwidth limiter, device identities and roots of trust that define the pod boundary.

Adversary

A chip owner with physical custody, ranging from a commercially motivated operator to a state actor with failure-analysis equipment and supply-chain access.

Enforcement boundary

The mechanism reaches only interfaces brought inside the preauthorised system boundary; uncovered data paths and compute outside equipped products remain beyond it.

Capabilities considered

Firmware exploitation, key theft, protocol manipulation and resource pooling.
Side-channel analysis, fault injection and package-level tampering.
Focused-ion-beam editing, reverse engineering and attacks repeated across many chips.
Communication-efficient or decentralised training that reduces dependence on the restricted links.

Limits and exclusions

Cybersecurity of manufacturers, public-key infrastructure and government authorities is largely outside the working paper's HEM analysis.
Equivalent compute obtained from chips without the mechanism is acknowledged but not directly analysed.
The paper does not specify a final device architecture or a settled policy bandwidth threshold.

04Trust register

The assurance dependency chain.

DomainRequirementFailure consequenceSource treatment

Identity and roots of trust

Every pod member must possess an unforgeable identity bound to the authorised set.

A cloned identity or compromised root admits an unauthorised accelerator at full bandwidth.

central

Interface completeness

All high-value paths through accelerators, CPUs, NICs and switches must enforce the same boundary.

One uncovered interface becomes the inter-pod network.

discussed

Policy-to-bandwidth mapping

The pod-size and bandwidth settings must remain restrictive for relevant training methods while preserving allowed uses.

The rule either permits the targeted workload or disables legitimate applications.

central

Hardware and firmware integrity

Self-tests, secure firmware and physical protections must resist a custodian with access to the device.

A scalable bypass converts the fixed set back into ordinary networking.

central

Fleet coverage

Equipped chips must constitute enough of the adversary's available compute for the restriction to matter.

The workload migrates to unrestricted or substitute hardware.

discussed

05Caveats on the record

Limitations the source already recognizes.

The mechanism does not yet exist, and the paper offers a rough outline rather than a specific implementation (Chapter 7, pp. 51–53).
The correct external-bandwidth limit and maximum set size are open questions with substantial permitted-use costs (p. 54).
Communication-efficient and decentralised training directly weaken the mechanism's premise (p. 55).
Effectiveness hinges on securely restricting high-bandwidth communication to verified devices; a compromise could make the mechanism ineffective (pp. 55–56).
The authors state that they lack enough confidence to recommend HEM deployment and call for further architecture and threshold research (pp. 58–59).

06Consortium assessment

Where the assurance moves

A narrow and testable network-control property is asked to carry a broader claim about effective compute aggregation. The transfer holds only if interface coverage is complete and the policy threshold continues to track training practice.

Load-bearing sequence

Device identity remains unforgeable under owner custody.
Every useful high-bandwidth path enforces pod membership.
The external limit materially penalises future training algorithms.
Alternative hardware and longer training schedules do not erase the imposed cost.

Institutional translationInternational order is rendered as an access-control list, with hardware replacement awaiting approval from the seating committee.

07Tests that would change our mind

A finding should be falsifiable.

Test 01

Inventory every physical and logical data path and demonstrate that no unmetered route can join two pods.

Test 02

Benchmark frontier-relevant distributed training across the proposed ceiling, including communication compression and infrequent synchronisation.

Test 03

Attempt identity cloning, firmware rollback, fault injection and a repeatable per-chip bypass under the stated adversary tiers.

Test 04

Replace failed chips and change topology without creating an unaudited reauthorisation path.

Test 05

Quantify false restriction and performance costs for hosted inference, scientific computing and other allowed workloads.

08Record provenance

Primary sourceHardware-Enabled Governance Mechanisms ↗

Reviewed2026-08-22

Methodologyv1.0

Correction statusnone

Evidence register (4)

Hardware-Enabled Governance Mechanisms, Chapter 7, pp. 50–54 (PDF pp. 61–65)

Fixed-set goal, preauthorised pod, roots of trust, external throttling and open parameter questions.

Hardware-Enabled Governance Mechanisms, Chapter 7, pp. 55–56 (PDF pp. 66–67)

Communication-efficient training, verified-device dependency and need for implementation-specific threat analysis.

Hardware-Enabled Governance Mechanisms, Chapter 4, pp. 22–31 (PDF pp. 33–42)

Physical and nonphysical attacks, actor tiers, scope exclusions and cost-imposition security model.

Hardware-Enabled Governance Mechanisms, Chapter 8, pp. 57–59 (PDF pp. 68–70)

Circumvention, adoption and substitute-hardware limits; authors' non-recommendation pending further work.