Pith. sign in

REVIEW 3 major objections 5 minor 2 cited by

Technical Options for Flexible Hardware-Enabled Guarantees

T0 review · 3 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The report argues that an Interlock on the accelerator's data path — most plausibly a repurposed network interface controller — can give AI developers cryptographically signed, privacy-preserving guarantees about past and future compute…

desk verdict A useful design study with a clever FLOP-counting protocol, but the NIC-based Interlock only covers scale-out traffic, not host or NVLink paths. read the letter →

arxiv 2506.03409 v3 pith:YHTKAEPX submitted 2025-06-03 cs.CR

James Petrie , Onni Aarne This is my paper · ORCID
classification cs.CR
keywords flexiblehardware-enabledguaranteesAIacceleratorgovernanceInterlockarchitecturenetworkinterfacecontrollersecuritysecureenclosurecomputegraphverificationFLOPcountingconfidentialcomputing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Frontier AI labs need a way to make credible statements about what they did or did not compute without leaking their models, and this report argues that the most practical anchor for such statements is the AI accelerator itself. Its proposal, flexHEG, adds two pieces of hardware to accelerators: an auditable Guarantee Processor that watches usage and checks rules, and a Secure Enclosure that makes tampering detectable or destructive. The central move is the 'Interlock': the Guarantee Processor is placed on the accelerator's main data path, so that as the only route for data and instructions into the chip, it can monitor and control what happens without needing to trust the chip's internals. The most promising retrofittable Interlock is a repurposed or replaced network interface controller, and the report works through the concrete mechanisms — encrypted cluster formation, tamper-responsive enclosures, and on-the-fly distributed FLOP counting — that would make the guarantees real. If the design works, AI developers could certify claims such as 'this training run stayed under a compute budget' without revealing the model, and auditors could treat those certificates as trustworthy.

What carries the argument

The load-bearing object is the Interlock: a Guarantee Processor with direct access to a buffer on the accelerator's data path, so that all data and instructions must pass through it. It converts 'what was computed?' from a question that requires trusting proprietary accelerator internals into a question that can be answered by watching a choke point. Three supporting mechanisms carry the design: an encrypted cluster formation protocol (public-key authorization followed by per-source AES-GCM session keys) that lets Interlocks see and constrain which accelerators may communicate; a tamper-evident or tamper-responsive Secure Enclosure that raises the cost of physical attack and can permanently disable a chip; and an on-the-fly distributed FLOP log in which each node stores per-source maxima rather than a single running total, so multi-accelerator compute can be certified without double counting.

What would settle it

A prototype red-team test would settle it: place a NIC-based Interlock between two accelerators running a distributed workload and try two attacks — spoofing a read of accelerator memory through the PCIe path, and injecting precomputed intermediate data through the external-data channel within the allowed latency. If either attack yields a guarantee certificate that passes automated verification, the central monitoring-and-control claim fails. A simpler early signal is vendor policy: if accelerator makers' next confidential-computing releases still block third-party direct memory access into accelerator memory, the retrofittable Interlock cannot be built as proposed.

Watch

Extended reading notes

Core claim

The central claim is that a third-party hardware component, placed on the accelerator's data path, can provide privacy-preserving and verifiable guarantees about both past and future accelerator use, treating the accelerator itself as a black box. The report calls this component an Interlock: as the only path for data and instructions to enter the accelerator, it can robustly monitor and/or control that flow, and by controlling the key exchange that forms encrypted clusters it gains visibility into how data moves between accelerators. The report identifies the network interface controller as the most promising retrofittable home for the Interlock, since modern NICs already sit on the data path, have programmable compute and inline cryptography, and can be swapped by third parties. To make guarantees concrete, the report develops a multi-accelerator FLOP-counting protocol in which each Interlock carries a small log of the highest FLOP counts that could have causally influenced its local data, while external data is hash-anchored and delayed to prevent 'FLOP laundering', so a signed certificate can attest to the compute behind any output.

Load-bearing premise

The load-bearing premise is that a third-party component can gain trustworthy, spoof-resistant access to the accelerator's data path and memory without unacceptable performance loss — access that the report's own footnote records is currently blocked by the leading accelerator vendor's confidential-computing implementation.

Editorial extensions

If this is right

  • A developer could certify that a training run stayed within a stated FLOP budget or used only approved data, without disclosing the model or its weights.
  • Because the Interlock can control as well as observe, guarantees can cover future use: a tamper-responsive enclosure can permanently disable an accelerator before its guarantee logic can be circumvented.
  • A NIC-based retrofit could reach existing accelerators years before integrated on-die designs, and meeting the report's 2027 deployment window depends on that path.
  • k-of-n signed updates mean no single vendor or state can unilaterally change the rules, and licenses with minimum version numbers can force updates even on air-gapped systems.
  • The FLOP-counting protocol scales to very large clusters, storing roughly 30MB per node of source-ID maxima, and resists laundering by hashing and delaying external data.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The prefix-log scheme reads as a general template: the same per-source maximum propagation could carry compute-graph hashes or other workload summaries, so the anti-laundering design likely extends to guarantees beyond FLOPs — an extension the report leaves implicit.
  • The whole retrofit path hinges on one commercial decision the report cannot settle: whether accelerator vendors will permit third-party direct memory access while their confidential-computing features are enabled; the first vendor release to allow this would be a decisive test signal.
  • A natural downstream application is inference-time guarantees, such as capping chain-of-thought length, because an Interlock on a serving network card sees deployed traffic, not only training traffic.
  • If the data-path Interlock proves infeasible, the report's own power-measurement prototype and opportunistic workload classification form a credible interim tier for domestic oversight — a fallback the roadmap acknowledges only in passing.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes flexHEG, a hardware-based system for enabling AI developers to make verifiable, privacy-preserving guarantees about accelerator usage. It surveys four modification strategies (integrated hardware, retrofitted hardware, firmware, software), analyzes Guarantee Processor and Secure Enclosure design choices, and develops an 'Interlock' architecture in which a component on the accelerator's data path monitors and controls data and instruction flow. The report then sketches general-purpose guarantee mechanisms, a multi-accelerator FLOP counting protocol, an encrypted cluster formation protocol, and a multi-year R&D roadmap. The main claimed contribution is that a retrofittable Interlock, implemented by repurposing or replacing the NIC, can provide robust verifiable guarantees about past and future accelerator use while treating the accelerator as a black box.

Significance. If the central architectural claim held, the paper would be a valuable design-space analysis for a policy-relevant problem: it names concrete hardware touchpoints, gives order-of-magnitude cost estimates, and proposes falsifiable mechanisms such as the FLOP log and the k-of-n update authorization pseudocode. The report is honest about its own limitations, explicitly calling for red-teaming, empirical workload datasets, and implementation, and it credits related work by Shavit, Mithril, EQTY, and prior licensing/firmware proposals. The taxonomy of accelerator modifications and the threat-model appendix are useful even independently of the Interlock claim. However, the work is a design sketch rather than a validated system: no component is implemented or formally analyzed, and, as detailed below, the NIC-based Interlock does not satisfy the 'only path' property on contemporary accelerator architectures. The significance is therefore conditional on a substantial revision of the central claim.

major comments (3)
  1. [Interlock-Based FlexHEG Design / Repurposing the Network Interface Controller] The defining property of the Interlock is that it is 'the only path for data and instructions to enter the accelerator,' but the proposed retrofittable implementation, replacing the NIC, sits only on the scale-out network path. On the GB200 NVL72 architecture described in Appendix A, kernel launch and control traffic enter through the host CPU via PCIe or NVLink-C2C, and large tensor-parallel and pipeline-parallel exchanges travel over intra-tray NVLink without touching the NIC. A NIC-based Interlock therefore cannot observe or block host-issued kernels or NVLink transfers, so it does not satisfy the 'only path' condition and cannot by itself enforce future-usage guarantees. The paper should either restrict the Interlock claim to scale-out traffic or describe how interlocks on all ingress paths are coordinated and physically secured.
  2. [Guarantee Example: Multi-Accelerator FLOP Counting] Steps 3 and 4 of the FLOP counting protocol require each Interlock to prepend its FLOP log to data sent to other accelerators. Because intra-node NVLink traffic never traverses the NIC, the FLOP provenance of the dominant in-node data flows is not captured; an accelerator can receive data via NVLink without the local Interlock learning the sender's FLOP log. The protocol is therefore incomplete for the very multi-accelerator workloads it targets unless interlocks are placed on NVLink paths or the design trusts accelerator-internal performance counters, which contradicts the black-box motivation stated earlier in the Interlock section.
  3. [Hardware Modifications (Retrofitted), footnote 4] The paper's own note that Nvidia's confidential computing blocks third-party DMA and that PCIe reads may be spoofable undercuts the proposed data-access route for a plug-in Guarantee Processor: the text claims 'Nvidia supports third party direct memory access to HBM' and that 'a third-party device could potentially be set up to read from HBM.' Because robust access to accelerator workload data is design goal (2), this is load-bearing for the retrofit path. The report should identify a concrete mechanism or required vendor cooperation for trustworthy HBM reads, or explicitly demote the retrofit option to a partial solution that cannot support the full Interlock guarantee.
minor comments (5)
  1. [Cryptography Hardware] The PCIe encryption estimate uses 3000*10^9 bytes/s rather than the 128 GB/s PCIe figure given earlier in the same section; as written, 3000e9 * 75 / 1.98e15 is about 11%, not 0.5%, while the intended estimate should be about 0.5% using 128e9 bytes/s. Please correct the arithmetic and the referenced bandwidth.
  2. [Accelerator Measurements] The table entry for 'Accelerator Instructions' ends with 'One limitation' and then the cell is empty; the sentence is incomplete.
  3. [Cryptography Hardware / cross-reference] The text refers to 'the section, A Specific Retrofittable flexHEG Design,' but no such section appears in the table of contents or in the supplied text; either add the section or fix the cross-reference.
  4. [Secure Enclosure and Bibliography] Several numeric citation markers appear mismatched with the bibliography (for example, [9], [10], [11], [14], and [15] in the Secure Enclosure section do not correspond to the listed references); the citation numbering should be checked throughout.
  5. [Figures] Figure 2 is referenced in the Hardware Modifications (Integrated) section before Figure 1 is introduced in Appendix A; reordering the figures or adjusting the references would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the Interlock and FLOP-log designs are argued from data-path placement and protocol construction, not from fitted outputs or load-bearing self-citation.

full rationale

The report is a design-space analysis rather than an empirical derivation, and no claimed result reduces by construction to its inputs. The central Interlock property is stated as a placement condition: “As the only path for data and instructions to enter the accelerator, the interlock would be able to robustly monitor and/or control this flow”; this is definitional to the design scenario, not a prediction derived from fitted data. The NIC retrofit is explicitly offered as “a promising option,” and the paper itself flags the load-bearing assumption in footnote 4: Nvidia confidential computing blocks direct memory access from third-party devices and PCIe reads may be spoofable. The FLOP-counting protocol (steps 1–4) is a constructive sketch whose correctness depends on the stated assumption that each Interlock can maintain and prepend a FLOP log; that assumption is an input to the design, not a conclusion the paper purports to derive. The only references involving the authors’ prior work ([11], [12], [13]) support the optional firmware-licensing and update mechanism, which is not load-bearing for the Interlock or FLOP-log proposals, and no uniqueness theorem or forbidden-alternative argument is imported from those citations. The core architecture is therefore self-contained as a technical option analysis, and no circular step is present.

Assumptions & free parameters 3 free parameters · 5 assumptions · 3 invented entities

The report introduces a hardware monitoring architecture rather than deriving a result from first principles. The central feasibility claim rests on domain assumptions about third-party data-path access, secure enclosure cooling, and accurate FLOP measurement. No fitted parameters are used, but several hand-picked example constants affect the illustrative protocols.

free parameters (3)
  • AES-GCM compute cost estimate = ~75 operations per byte
    Used in the Cryptography Hardware section to estimate that encrypting NVLink traffic costs roughly 3% of compute or power and HBM roughly 11%. This is an order-of-magnitude estimate, not a measured benchmark.
  • External data delay for FLOP anti-laundering = on the order of months, example 3 months
    The FLOP counting example sets a delay that would prevent sequential workload combination. The value is chosen by hand and directly affects the protocol's practicality.
  • Accelerator displacement timeline = 3.7-7.9 years for integrated flexHEG
    Combines Epoch AI displacement data with a rough 1-4 year estimate to add changes to all leading accelerator designs. The 1-4 year portion has no cited source and no sensitivity analysis.
assumptions (5)
  • domain assumption A third-party component can sit on the accelerator data path and read HBM via DMA or NIC without being blocked or spoofed.
    The Interlock design depends on trustworthy data-path access. The paper notes in footnote 4 of the Retrofitted Hardware section that Nvidia's confidential computing currently blocks third-party DMA from HBM and that PCIe reads may be spoofable.
  • domain assumption The accelerator can be treated as a black box for complex guarantee checks.
    The Interlock section says the design treats the accelerator as a black box, but verifying compute graphs and avoiding mistimed checks requires assumptions about internal accelerator behavior that are not proven.
  • domain assumption Secure enclosures can enclose accelerators while handling up to 1200W heat dissipation, liquid cooling, and maintenance.
    The Secure Enclosure section describes cooling options, metalized foam and liquid-liquid heat exchangers, as possible directions. No tested design is provided.
  • ad hoc to paper External data can be hashed and delayed or audited to prevent FLOP laundering.
    The FLOP counting section introduces hash-plus-delay mechanisms. No proof is given that a determined developer cannot launder compute through external data channels.
  • domain assumption Local FLOP counts can be obtained accurately from performance counters, kernel scans, or power usage.
    The multi-accelerator FLOP counting protocol assumes an up-to-date log of local FLOPs after power-on. The paper lists possible sources but does not validate their accuracy under adversarial conditions.
invented entities (3)
  • Guarantee Processor
    purpose: On-device monitor that collects accelerator measurements, runs guarantee logic, and issues signed compliance certificates.
    Proposed component with no prototype. Open-sourcing the design is listed as Project 2 in Future Work.
  • Secure Enclosure
    purpose: Tamper-evident or tamper-responsive physical boundary protecting the Guarantee Processor and accelerator from physical attacks.
    No working enclosure for 1200W AI accelerators is demonstrated. The FIPS-140 devices cited are not AI accelerators.
  • Interlock
    purpose: A flexHEG component placed on the accelerator's main data path so it can monitor and control all data and instructions entering the accelerator.
    Core architectural contribution, described as a design with four implementation options and no implementation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Technical Options for Flexible Hardware-Enabled Guarantees." pith.science (2026). https://pith.science/paper/YHTKAEPX

@misc{pith2026250603409,
  author       = {Pith},
  title        = {Pith review of: Technical Options for Flexible Hardware-Enabled Guarantees},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YHTKAEPX}},
  note         = {Machine review of arXiv:2506.03409}
}
read the original abstract

Frontier AI models pose increasing risks to public safety and international security, creating a pressing need for AI developers to provide credible guarantees about their development activities without compromising proprietary information. We propose Flexible Hardware-Enabled Guarantees (flexHEG), a system integrated with AI accelerator hardware to enable verifiable claims about compute usage in AI development. The flexHEG system consists of two primary components: an auditable Guarantee Processor that monitors accelerator usage and verifies compliance with specified rules, and a Secure Enclosure that provides physical tamper protection. In this second report of a three part series, we analyze technical implementation options ranging from firmware modifications to custom hardware approaches, with focus on an "Interlock" design that provides the Guarantee Processor direct access to accelerator data paths. Our proposed architecture could support various guarantee types, from basic usage auditing to sophisticated automated verification. This work establishes technical foundations for hardware-based AI governance mechanisms that could address emerging regulatory and international security needs in frontier AI development.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 2 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. How to Catch a GPU: A Taxonomy of Verification and Enforcement Mechanisms for International AI Agreements

    cs.CY 2026-06 conditional novelty 6.0 of 10

    Verification of international AI agreements will fail first at detecting hidden compute facilities, around the 10,000-H100-equivalent scale, before other enforcement mechanisms break.

  2. Safety Features for a Centralised AGI Project

    cs.CY 2025-06 conditional novelty 5.0 of 10

    A policy proposal for seven safety features, including bottom-up pause authority, congressional-chartered board oversight, risk monitoring, and verification technology, to reduce catastrophic risks in a centralized US...

Reference graph

Works this paper leans on

80 extracted references · 69 canonical work pages · cited by 2 Pith papers

  1. [1]

    International AI Safety Report,

    Y. Bengio et al. , “International AI Safety Report,” Jan. 29, 2025, arXiv : arXiv:2501.17805. doi: 10.48550/arXiv.2501.17805

    arXiv doi:10.48550/arxiv.2501.17805 2025

  2. [2]

    Computing Power and the Governance of Artificial Intelligence,

    G. Sastry et al. , “Computing Power and the Governance of Artificial Intelligence,” Feb. 13, 2024, arXiv : arXiv:2402.08797. doi: 10.48550/arXiv.2402.08797

    arXiv doi:10.48550/arxiv.2402.08797 2024

  3. [3]

    Governing Through the Cloud | GovAI

    “Governing Through the Cloud | GovAI.” Accessed: Apr. 12, 2025. [Online]. Available: https://www.governance.ai/research-paper/governing-through-the-cloud

    work page 2025

  4. [4]

    Announcing The Stargate Project

    “Announcing The Stargate Project.” Accessed: Apr. 11, 2025. [Online]. Available: https://openai.com/index/announcing-the-stargate-project/

    work page 2025

  5. [5]

    xAI targets one million GPUs for Colossus supercomputer in Memphis

    M. G. 1 Comment, “xAI targets one million GPUs for Colossus supercomputer in Memphis.” Accessed: Apr. 12, 2025. [Online]. Available: https://www.datacenterdynamics.com/en/news/xai-elon-musk-memphis-colossus-gpu/

    work page 2025

  6. [6]

    The stock of computing power from NVIDIA chips is doubling every 10 months,

    L. Frymire, “The stock of computing power from NVIDIA chips is doubling every 10 months,” Epoch AI. Accessed: Apr. 12, 2025. [Online]. Available: https://epoch.ai/data-insights/nvidia-chip-production

    work page 2025

  7. [7]

    AI’s Power Requirements Under Exponential Growth: Extrapolating AI Data Center Power Demand and Assessing Its Potential Impact on U.S. Competitiveness,

    K. F. Pilz, Y. Mahmood, and L. Heim, “AI’s Power Requirements Under Exponential Growth: Extrapolating AI Data Center Power Demand and Assessing Its Potential Impact on U.S. Competitiveness,” RAND Corporation, Jan. 2025. Accessed: Apr. 05, 2025. [Online]. Available: https://www.rand.org/pubs/research_reports/RRA3572-1.html

    work page 2025

  8. [8]

    datasheet_SuperCluster_GB200_NVL72.pdf

    “datasheet_SuperCluster_GB200_NVL72.pdf.” Accessed: Apr. 05, 2025. [Online]. Available: https://www.supermicro.com/datasheet/datasheet_SuperCluster_GB200_NVL72.pdf

    work page 2025

Show all 80 references
  1. [9]

    1. Overview — GPUDirect RDMA 12.8 documentation

    “1. Overview — GPUDirect RDMA 12.8 documentation.” Accessed: Apr. 12, 2025. [Online]. Available: https://docs.nvidia.com/cuda/gpudirect-rdma/

    2025

  2. [10]

    Hardware Secure Boot,

    B. Kelly, “Hardware Secure Boot,” Open Compute Proj. , [Online]. Available: https://www.opencompute.org/documents/secure-boot-2-pdf

  3. [11]

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

    G. Kulp et al. , “Hardware-Enabled Governance Mechanisms: Developing Technical Solutions to Exempt Items Otherwise Classified Under Export Control Classification Numbers 3A090 and 4A090,” RAND Corporation, Jan. 2024. Accessed: Aug. 23, 2024. [Online]. Available: https://www.rand...

    2024

  4. [12]

    Aarne, T

    O. Aarne, T. Fist, and C. Withers, “Secure, Governable Chips. Using On-Chip Mechanisms 46 Flexible Hardware-Enabled Guarantees | Part I | Part II | Part III to Manage National Security Risks from AI & Advanced Computing,” Jan. 2024, [Online]. Available: https://www.cnas.org/pu...

    2024

  5. [13]

    Near-Term Enforcement of AI Chip Export Controls Using A Firmware-Based Design for Offline Licensing,

    J. Petrie, “Near-Term Enforcement of AI Chip Export Controls Using A Firmware-Based Design for Offline Licensing,” May 28, 2024, arXiv : arXiv:2404.18308. doi: 10.48550/arXiv.2404.18308

    2024 doi arXiv

  6. [14]

    Laser Fault Injection on a Budget: RP2350 Edition,

    courk, “Laser Fault Injection on a Budget: RP2350 Edition,” Courk’s Blog. Accessed: Apr. 05, 2025. [Online]. Available: https://courk.cc/rp2350-challenge-laser

    2025

  7. [15]

    Trusted Execution Environment: What It is, and What It is Not,

    M. Sabt, M. Achemlal, and A. Bouabdallah, “Trusted Execution Environment: What It is, and What It is Not,” in 2015 IEEE Trustcom/BigDataSE/ISPA , Aug. 2015, pp. 57–64. doi: 10.1109/Trustcom.2015.357

    2015 doi

  8. [16]

    Technology overview - AICert

    “Technology overview - AICert.” Accessed: Apr. 12, 2025. [Online]. Available: https://aicert.mithrilsecurity.io/en/latest/docs/getting-started/tech-overview/

    2025

  9. [17]

    Verifiable Compute White Paper

    “Verifiable Compute White Paper.” Accessed: Apr. 12, 2025. [Online]. Available: https://www.eqtylab.io/verifiable-compute-white-paper

    2025

  10. [18]

    What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring,

    Y. Shavit, “What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring,” May 30, 2023, arXiv : arXiv:2303.11341. doi: 10.48550/arXiv.2303.11341

    2023 doi arXiv

  11. [19]

    Project T-TEE reading list - TEE - Trusted Execution Environment / Trustless TEEs,

    “Project T-TEE reading list - TEE - Trusted Execution Environment / Trustless TEEs,” The Flashbots Collective. Accessed: Apr. 12, 2025. [Online]. Available: https://collective.flashbots.net/t/project-t-tee-reading-list/3566

    2025

  12. [20]

    CVE - CVE-2024-56161

    “CVE - CVE-2024-56161.” Accessed: Apr. 12, 2025. [Online]. Available: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-56161

    2024

  13. [21]

    Secure Enclave,

    “Secure Enclave,” Apple Support. Accessed: Aug. 23, 2024. [Online]. Available: https://support.apple.com/en-gb/guide/security/sec59b0b31ff/web

    2024

  14. [22]

    What is Intel® Management Engine?,

    “What is Intel® Management Engine?,” Intel. Accessed: Aug. 23, 2024. [Online]. Available: https://www.intel.com/content/www/us/en/support/articles/000008927/software/chip set-software.html

    2024

  15. [23]

    Open source silicon root of trust (RoT) | OpenTitan

    “Open source silicon root of trust (RoT) | OpenTitan.” Accessed: Aug. 23, 2024. [Online]. Available: https://opentitan.org/

    2024

  16. [24]

    Caliptra: A Datacenter System on a Chip (SOC) Root of Trust (RoT)

    B. Kelly and A. Lagar-Cavilla, “Caliptra: A Datacenter System on a Chip (SOC) Root of Trust (RoT)”

  17. [25]

    Tropic Square | TROPIC01

    “Tropic Square | TROPIC01.” Accessed: Aug. 23, 2024. [Online]. Available: https://tropicsquare.com/product

    2024

  18. [26]

    Hardware trojan attacks in FPGA devices: threat analysis and effective counter measures,

    S. Mal-Sarkar, A. Krishna, A. Ghosh, and S. Bhunia, “Hardware trojan attacks in FPGA devices: threat analysis and effective counter measures,” in Proceedings of the 24th edition of the great lakes symposium on VLSI , in GLSVLSI ’14. New York, NY, USA: Association for Computing ...

    2014

  19. [27]

    A Triple Core Lock-Step (TCLS) ARM® Cortex®-R5 Processor for Safety-Critical and Ultra-Reliable Applications,

    X. Iturbe, B. Venu, E. Ozer, and S. Das, “A Triple Core Lock-Step (TCLS) ARM® Cortex®-R5 Processor for Safety-Critical and Ultra-Reliable Applications,” in 2016 46th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshop (DSN-W) , Jun. 2016, pp. ...

    2016 doi

  20. [28]

    Security through transparency: RP2350 Hacking Challenge results are in,

    E. Upton, “Security through transparency: RP2350 Hacking Challenge results are in,” Raspberry Pi. Accessed: Apr. 12, 2025. [Online]. Available: https://www.raspberrypi.com/news/security-through-transparency-rp2350-hacking-chall enge-results-are-in/

    2025

  21. [29]

    NVIDIA: Adoption of SPARK Ushers in a New Era in Security-Critical…,

    RISC-V International, Keynote: RISC-V at NVIDIA: One Architecture, Dozens of Applications, Billions... - Frans Sijstermans , (Oct. 31, 2024). Accessed: Apr. 12, 2025. [Online Video]. Available: https://www.youtube.com/watch?v=C5A9z_Yk0KA 47 Flexible Hardware-Enabled Guarantees...

    2024

  22. [31]

    A secure approach to generative AI with AWS | AWS Machine Learning Blog

    “A secure approach to generative AI with AWS | AWS Machine Learning Blog.” Accessed: Apr. 12, 2025. [Online]. Available: https://aws.amazon.com/blogs/machine-learning/a-secure-approach-to-generative-ai-wit h-aws/

    2025

  23. [32]

    GB200 Hardware Architecture – Component Supply Chain & BOM,

    “GB200 Hardware Architecture – Component Supply Chain & BOM,” SemiAnalysis. Accessed: Apr. 12, 2025. [Online]. Available: https://semianalysis.com/2024/07/17/gb200-hardware-architecture-and-component/

    2025

  24. [33]

    Revision 1.0, Version 1.00 Authors:

    R. Bingi et al. , “Revision 1.0, Version 1.00 Authors:”. [34] A. S, “Technology,” Axiado Corporation. Accessed: Apr. 12, 2025. [Online]. Available: https://axiado.com/tcu-platform/

    2025

  25. [35]

    NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Project,

    “NVIDIA Contributes NVIDIA GB200 NVL72 Designs to Open Compute Project,” NVIDIA Technical Blog. Accessed: Apr. 12, 2025. [Online]. Available: https://developer.nvidia.com/blog/nvidia-contributes-nvidia-gb200-nvl72-designs-to-ope n-compute-project/

    2025

  26. [36]

    Security Engineering: A Guide to Building Dependable Distributed Systems, 3rd Edition | Wiley,

    “Security Engineering: A Guide to Building Dependable Distributed Systems, 3rd Edition | Wiley,” Wiley.com. Accessed: Apr. 12, 2025. [Online]. Available: https://www.wiley.com/en-us/Security+Engineering%3A+A+Guide+to+Building+Depen dable+Distributed+Systems%2C+3rd+Edition-p-97...

    2025

  27. [37]

    The Past, Present, and Future of Physical Security Enclosures: From Battery-Backed Monitoring to PUF-Based Inherent Security and Beyond,

    J. Obermaier and V. Immler, “The Past, Present, and Future of Physical Security Enclosures: From Battery-Backed Monitoring to PUF-Based Inherent Security and Beyond,” J. Hardw. Syst. Secur. , vol. 2, no. 4, pp. 289–296, Dec. 2018, doi: 10.1007/s41635-018-0045-2

    2018 doi

  28. [38]

    Cryptographic Module Validation Program | CSRC | CSRC,

    I. T. L. Computer Security Division, “Cryptographic Module Validation Program | CSRC | CSRC,” CSRC | NIST. Accessed: Apr. 12, 2025. [Online]. Available: https://csrc.nist.gov/projects/cryptographic-module-validation-program

    2025

  29. [39]

    Extracting a 3DES key from an IBM 4758

    “Extracting a 3DES key from an IBM 4758.” Accessed: Apr. 12, 2025. [Online]. Available: https://www.cl.cam.ac.uk/~rnc1/descrack/

    2025

  30. [40]

    Efficacy of Tamper-Indicating Devices

    R. G. Johnston, A. R. E. Garcia, and A. N. Pacheco, “Efficacy of Tamper-Indicating Devices”. [41] X. Xu, A. Rahmati, D. E. Holcomb, K. Fu, and W. Burleson, “Reliable Physical Unclonable Functions Using Data Retention Voltage of SRAM Cells,” IEEE Trans. Comput.-Aided Des. Integr....

    2015

  31. [42]

    Immersion vs. Two-Phase Liquid Cooling | ZutaCore

    “Immersion vs. Two-Phase Liquid Cooling | ZutaCore.” Accessed: Apr. 12, 2025. [Online]. Available: https://blog.zutacore.com/zutacore-blog/two-phase-dlc-not-immersion-liquid-cooling

    2025

  32. [43]

    Open Compute Project,

    “Open Compute Project,” Open Compute Project. Accessed: Apr. 14, 2025. [Online]. Available: https://www.opencompute.org/products/525/cheval-group-open-rack-v3-nvidia-mgx-rac k-for-gb200-nvl72

    2025

  33. [44]

    Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI,

    I. rangel Says, “Confidential Computing on NVIDIA H100 GPUs for Secure and Trustworthy AI,” NVIDIA Technical Blog. Accessed: Apr. 12, 2025. [Online]. Available: https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-t rustworthy-ai/

    2025

  34. [45]

    NVIDIA Scalable Hierarchical Aggregation and Reduction Protocol (SHARP) Rev 3.0.0,

    “NVIDIA Scalable Hierarchical Aggregation and Reduction Protocol (SHARP) Rev 3.0.0,” NVIDIA Docs. Accessed: Apr. 12, 2025. [Online]. Available: https://docs.nvidia.com/networking/display/SHARPv300

    2025

  35. [46]

    Authenticated-encryption with associated-data,

    P. Rogaway, “Authenticated-encryption with associated-data,” in Proceedings of the 9th ACM 48 Flexible Hardware-Enabled Guarantees | Part I | Part II | Part III conference on Computer and communications security , in CCS ’02. New York, NY, USA: Association for Computing Machin...

    2002

  36. [47]

    AES Galois Counter Mode (GCM) Cipher Suites for TLS,

    J. A. Salowey, D. McGrew, and A. Choudhury, “AES Galois Counter Mode (GCM) Cipher Suites for TLS,” Internet Engineering Task Force, Request for Comments RFC 5288, Aug. 2008. doi: 10.17487/RFC5288

    2008 doi

  37. [48]

    AES-GCM and breaking it on nonce reuse,

    F. Reiter, “AES-GCM and breaking it on nonce reuse,” frereit’s blog. Accessed: Apr. 13, 2025. [Online]. Available: https://frereit.de/aes_gcm/

    2025

  38. [49]

    Silex Insight extends their AES-GCM Crypto Engine offering by introducing an ultra-low latency version for PCI Express 5.0 and Compute Express Link 2.0,

    “Silex Insight extends their AES-GCM Crypto Engine offering by introducing an ultra-low latency version for PCI Express 5.0 and Compute Express Link 2.0,” Design And Reuse. Accessed: Apr. 13, 2025. [Online]. Available: https://www.design-reuse.com/news/49950/silex-insight-ultra...

    2025

  39. [50]

    Creating the First Confidential GPUs – Communications of the ACM

    “Creating the First Confidential GPUs – Communications of the ACM.” Accessed: Aug. 24, 2024. [Online]. Available: https://cacm.acm.org/practice/creating-the-first-confidential-gpus/

    2024

  40. [51]

    NVIDIA ConnectX-8 SuperNIC,

    “NVIDIA ConnectX-8 SuperNIC,” NVIDIA. Accessed: Apr. 14, 2025. [Online]. Available: https://resources.nvidia.com/en-us-accelerated-networking-resource-library/connectx-dat asheet-c

    2025

  41. [52]

    GB200 Hardware Architecture – Component Supply Chain & BOM,

    “GB200 Hardware Architecture – Component Supply Chain & BOM,” SemiAnalysis. Accessed: Apr. 05, 2025. [Online]. Available: https://semianalysis.com/2024/07/17/gb200-hardware-architecture-and-component/

    2025

  42. [53]

    What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring,

    Y. Shavit, “What does it take to catch a Chinchilla? Verifying Rules on Large-Scale Neural Network Training via Compute Monitoring,” May 30, 2023, arXiv : arXiv:2303.11341. Accessed: Aug. 23, 2024. [Online]. Available: http://arxiv.org/abs/2303.11341

    2023 arXiv

  43. [54]

    Compute Graph Framework SDK Reference: Architecture

    “Compute Graph Framework SDK Reference: Architecture.” Accessed: Apr. 12, 2025. [Online]. Available: https://developer.nvidia.com/docs/drive/drive-os/6.0.9/public/driveworks-nvcgf/cgf_a rchitecture.html

    2025

  44. [55]

    Dynamo Overview — PyTorch 2.6 documentation

    “Dynamo Overview — PyTorch 2.6 documentation.” Accessed: Apr. 12, 2025. [Online]. Available: https://pytorch.org/docs/stable/torch.compiler_dynamo_overview.html

    2025

  45. [56]

    torch.fx — PyTorch main documentation

    “torch.fx — PyTorch main documentation.” Accessed: Apr. 12, 2025. [Online]. Available: https://pytorch.org/docs/main/fx.html#torch.fx.Graph

    2025

  46. [57]

    deepseek-ai/DeepEP . (Apr. 11, 2025). Cuda. DeepSeek. Accessed: Apr. 12, 2025. [Online]. Available: https://github.com/deepseek-ai/DeepEP

    2025

  47. [58]

    Classes of recursively enumerable sets and their decision problems,

    H. G. Rice, “Classes of recursively enumerable sets and their decision problems,” Trans. Am. Math. Soc. , vol. 74, no. 2, pp. 358–366, 1953, doi: 10.1090/S0002-9947-1953-0053041-6

    1953 doi

  48. [59]

    How To Scale Your Model

    “How To Scale Your Model.” Accessed: Apr. 12, 2025. [Online]. Available: https://jax-ml.github.io/scaling-book/

    2025

  49. [60]

    Verifying International Agreements on AI,

    M. Baker, G. Kulp, O. Marks, M. Brundage, and L. Heim, “Verifying International Agreements on AI,” forethcoming

  50. [61]

    Data movement limits to frontier model training,

    E. Erdil and D. Schneider-Joseph, “Data movement limits to frontier model training,” Nov. 13, 2024, arXiv : arXiv:2411.01137. doi: 10.48550/arXiv.2411.01137

    2024 doi arXiv

  51. [62]

    BEST PRACTICES FOR FIRMWARE CODE SIGNING

    C. Engel and D. Heller, “BEST PRACTICES FOR FIRMWARE CODE SIGNING”. [63] “Post-Quantum Secure Boot on OpenTitan,” zeroRISC. Accessed: Apr. 12, 2025. [Online]. Available: https://www.zerorisc.com/blog/post-quantum-secure-boot-on-opentitan

    2025

  52. [64]

    Data diodes in support of trustworthy cyber infrastructure,

    H. Okhravi and F. T. Sheldon, “Data diodes in support of trustworthy cyber infrastructure,” in Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research , in CSIIRW ’10. New York, NY, USA: Association for Computing Machinery, Apr. 2010, p...

  53. [68]

    TensorFlow

    “TensorFlow.” Accessed: Apr. 14, 2025. [Online]. Available: https://www.tensorflow.org/ [69] openxla/stablehlo . (Apr. 11, 2025). MLIR. OpenXLA. Accessed: Apr. 14, 2025. [Online]. Available: https://github.com/openxla/stablehlo

    2025

  54. [70]

    T Willard et al

    B. T Willard et al. , Aesara . (Jun. 2023). Python. Accessed: Apr. 14, 2025. [Online]. Available: https://github.com/aesara-devs/aesara

    2023

  55. [71]

    Model Intermediate Language — Guide to Core ML Tools

    “Model Intermediate Language — Guide to Core ML Tools.” Accessed: Apr. 14, 2025. [Online]. Available: https://apple.github.io/coremltools/docs-guides/source/model-intermediate-language.ht ml

    2025

  56. [72]

    The IREE Authors, IREE . (Sep. 2019). C++. Accessed: Apr. 14, 2025. [Online]. Available: https://github.com/iree-org/iree

    2019

  57. [73]

    onnx/onnx . (Apr. 14, 2025). Python. Open Neural Network Exchange. Accessed: Apr. 14, 2025. [Online]. Available: https://github.com/onnx/onnx

    2025

  58. [74]

    google-ai-edge/LiteRT . (Apr. 14, 2025). C++. google-ai-edge. Accessed: Apr. 14, 2025. [Online]. Available: https://github.com/google-ai-edge/LiteRT

    2025

  59. [75]

    Developer Resources,

    “Developer Resources,” Linaro. Accessed: Apr. 14, 2025. [Online]. Available: https://www.mlplatform.org/tosa/

    2025

  60. [76]

    WebNN Overview

    stevewhims, “WebNN Overview.” Accessed: Apr. 14, 2025. [Online]. Available: https://learn.microsoft.com/en-us/windows/ai/directml/webnn-overview

    2025

  61. [77]

    Supermicro NVIDIA GB200 NVL72 SuperCluster

    “Supermicro NVIDIA GB200 NVL72 SuperCluster”. [78] “Preventing AI Chip Smuggling to China | CNAS.” Accessed: Apr. 14, 2025. [Online]. Available: https://www.cnas.org/publications/reports/preventing-ai-chip-smuggling-to-china

    2025

  62. [78]

    Physical tampering with components that enforce restrictions on chip usage, potentially using Fault Analysis tools to image the device and make targeted modifications (e.g., resetting a FLOP counter)

  63. [79]

    Data protection in Amazon EC2 - Amazon Elastic Compute Cloud

    “Data protection in Amazon EC2 - Amazon Elastic Compute Cloud.” Accessed: Apr. 14, 2025. [Online]. Available: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/data-protection.html#encrypti on-transit

    2025

  64. [80]

    Machine Learning Trends,

    E. AI, “Machine Learning Trends,” Epoch AI. Accessed: Apr. 14, 2025. [Online]. Available: https://epoch.ai/trends

    2025

  65. [81]

    The Llama 3 Herd of Models,

    A. Grattafiori et al. , “The Llama 3 Herd of Models,” Nov. 23, 2024, arXiv : arXiv:2407.21783. doi: 10.48550/arXiv.2407.21783

    2024 doi arXiv

  66. [82]

    Distributed communication package - torch.distributed — PyTorch 2.6 documentation

    “Distributed communication package - torch.distributed — PyTorch 2.6 documentation.” Accessed: Apr. 14, 2025. [Online]. Available: https://pytorch.org/docs/stable/distributed.html

    2025

  67. [83]

    Introducing Trillium, sixth-generation TPUs,

    “Introducing Trillium, sixth-generation TPUs,” Google Cloud Blog. Accessed: Apr. 14, 2025. [Online]. Available: https://cloud.google.com/blog/products/compute/introducing-trillium-6th-gen-tpus

    2025

  68. [84]

    The Ultra-Scale Playbook - a Hugging Face Space by nanotron

    “The Ultra-Scale Playbook - a Hugging Face Space by nanotron.” Accessed: Apr. 14, 2025. [Online]. Available: https://huggingface.co/spaces/nanotron/ultrascale-playbook 50 Flexible Hardware-Enabled Guarantees | Part I | Part II | Part III Appendix A: Background on Frontier AI D...

    2025

  69. [85]

    Making secret modifications to cluster configurations (e.g., adding bridge devices to combine supposedly separate clusters)

    Leveraging backdoors inserted during design or manufacturing processes 5. Making secret modifications to cluster configurations (e.g., adding bridge devices to combine supposedly separate clusters)

  70. [86]

    We analyze four scenarios: domestic oversight, international treaty verification, international treaty enforcement, defending AI system IP

    Attacking the infrastructure used to authorize flexHEG devices (e.g., stealing authorization keys) The plausibility and impact of these attack vectors vary significantly based on the use case and the adversary's capabilities and motivations. We analyze four scenarios: domestic o...

  71. [87]

    Exploiting ambiguities in guarantee logic specifications 4

    Performing limited physical tampering on a strategic subset of devices 3. Exploiting ambiguities in guarantee logic specifications 4. Implementing modifications to cluster configurations that evade detection mechanisms 55 Flexible Hardware-Enabled Guarantees | Part I | Part II | ...

  72. [88]

    signature

    External verification: Intelligence capabilities, randomized physical inspections, and whistleblower incentives When evaluating whether flexHEG provides adequate security for a given application, policymakers should consider whether the system makes rule violations sufficiently di...

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.