Trust the Composition, Not the Parts
HAMLOCK answers a deceptively simple question: can a neural-network model and the hardware that runs it each look acceptable while their combination forms a backdoor? The paper's answer is yes, under a specific but meaningful supply-chain threat model. This conclusion brings the series back to its central judgment: trust in an AI system cannot stop at the model file or the accelerator in isolation; it must include the relationship that connects model, build process, hardware, and deployed behavior.
That is a more precise conclusion than “AI supply chains are risky.” It identifies the mechanism of the risk, the evidence supporting it, and the limits of what has been shown. HAMLOCK does not establish that every model is a hidden signal or that every accelerator vendor is a threat. It shows how a malicious meaning can be distributed so that local tests remain reassuring while the composed system behaves differently.
The object of trust is a relationship
The most important change in the mental model is to stop treating a model and a device as two independent objects with independent security properties. In ordinary software reasoning, a model is a function: an input goes in, a label or score comes out. In a deployed accelerator, that function is realized through a memory layout, a numerical representation, a compiler mapping, a datapath, firmware, and output-control logic. Those implementation choices can be invisible in a model repository while still determining how internal values are interpreted.
HAMLOCK uses that gap without requiring a full malicious classifier inside the weights. The model is tuned so that a trigger produces a distinctive activation signal. Hardware monitors selected values, recognizes the signal, and changes the final output logits. The model supplies information; the hardware gives the information a malicious meaning. The attack is therefore not a mysterious property of one file. It is an unauthorized relationship between artifacts.
That relationship also has a lifecycle. A model may be downloaded, trained, transformed, handed to a manufacturer, compiled into an accelerator, loaded with firmware or a bitstream, and operated inside a larger AI service. At each transition, some facts persist and others can be lost. The model's origin may be recorded while its deployment mapping is not. The hardware image may be measured while the model it interprets is not bound to that measurement. The final service may be monitored without retaining enough information to reproduce the exact model-hardware combination that produced an output.
The word “composition” is useful because it avoids two opposite mistakes. The first is to say that the model is innocent and therefore irrelevant. The model's altered neurons are part of the attack and carry the signal. The second is to say that the hardware alone contains the whole backdoor. The hardware depends on the model's prepared activations and the mapping that exposes them. Neither component is sufficient in the proposed design, but their dependence is itself a security property that must be checked.
Why independent passes can miss the same attack
A model maintainer can run clean and triggered inputs through the software model on ordinary hardware and see correct predictions. That observation supports a narrow and useful claim: the model did not produce the wrong target label in that test environment. It does not show that selected internal activations cannot be interpreted by a cooperating accelerator.
A hardware team can inspect a design and see a small amount of comparison and output-control logic. Synthesis estimates in the paper show area overhead up to 0.10% and power overhead up to 3.39% for the listed three-neuron cases, with much lower values in larger host designs. Such a footprint may be difficult to distinguish from normal variation using some side-channel methods.