Why the Fix Cannot Stop at the Model

HAMLOCK changes what a credible security control must prove. The question is no longer only whether a model file is clean; it is whether the approved model, accelerator, build mapping, and running system still form the intended composition. This chapter turns that conclusion into a layered assurance approach, using the HAMLOCK paper's call for hardware-software co-verification alongside NIST's draft guidance on provenance, integrity, monitoring, and governance. Each layer has a purpose and a blind spot, so none should be presented as a complete fix by itself.

Start with the relationship, not a checklist

A useful assurance claim has three objects and at least one relationship. The objects are the model and its data lineage, the hardware and firmware that execute it, and the deployed system that produces outputs. The relationship is the mapping and control flow connecting model operations to physical resources and final decisions.

Model and dataset provenance establish where the weights came from, which data and transformations shaped them, who approved them, and which version is intended for deployment. This evidence addresses one route in the HAMLOCK threat model: a model can be subtly altered before it reaches a hardware vendor. It also helps with the second route, in which an owner-trained model is changed during a hardware handoff. Provenance is not merely a record of origin. It is a way to detect an unexplained change between the artifact that was approved and the artifact that enters the build.

Hardware and firmware integrity establish what device was built, what image or bitstream it loaded, and whether low-level components are the ones that were approved. NIST's draft emphasizes that firmware such as BMC, UEFI, GPU, and storage-controller firmware can operate with high privilege and persist through ordinary operating-system recovery. Secure boot and a hardware root of trust can help verify software before execution and protect the chain of trust.

Neither layer answers the relationship question alone. A signed model can be paired with an unapproved accelerator. An approved accelerator image can receive an altered model or a different compilation mapping. A build manifest can name both artifacts but omit the fact that a particular internal value is being watched or that a final logit can be overridden. Co-verification is the step that asks whether the model's declared computation and the hardware's implemented datapath agree.

The paper's proposed direction is to cross-reference a compiled model's datapath with the hardware layout and look for anomalies. That is a research direction, not a tested control in the paper. Its importance is conceptual: the comparison must include the interface where HAMLOCK hides its meaning. Verifying that the model is correct and that the hardware is authentic is weaker than verifying that the authenticated hardware implements the approved model without an unauthorized interpretation path.

Make provenance executable

Provenance becomes useful when it can constrain transitions.