Why a Clean Model Can Still Carry a Malicious Signal
HAMLOCK is easiest to misunderstand if every model change is treated as a complete behavior change. The specific question here is narrower: what does a model need to do when hardware, rather than the model itself, will finish the backdoor? The answer gives readers a practical distinction between a model that contains a full route from trigger to wrong class and one that carries only a signal that becomes dangerous when a cooperating accelerator is present.
The distinction starts with an ordinary model-level backdoor. It then leads to HAMLOCK's unusual division of responsibility: the model remains correct on its own, but a few altered neurons communicate with a hardware detector. This is not a claim that model inspection is worthless. It is a claim about what model inspection can legitimately conclude.
The model-level backdoor most defenders expect
A classifier maps an input to a label. In a normal deployment, a trigger is simply another pattern in the input space; it should not give an attacker special control over the answer. A conventional backdoor changes that relationship. The model is trained or modified so that ordinary inputs still receive their correct labels, while inputs carrying a chosen trigger are redirected to an attacker-selected class.
That arrangement has two important properties. First, the model must preserve useful behavior on clean data. If accuracy collapses on ordinary examples, a victim may notice the compromise before the backdoor is used. Second, the model must contain the route that connects the trigger to the wrong output. It may be distributed over many layers and hidden among ordinary features, but the computation that recognizes the trigger and shapes the final prediction lives inside the model's parameters and activations.
This is why conventional backdoor defenses can inspect more than clean accuracy. A model scanner may search for an unusual trigger and a corresponding target label. A white-box method may look for abnormal weights or internal activation patterns. An input detector may examine whether a sample behaves differently under transformations. These methods have different strengths and weaknesses, but they are looking for a relationship that the model itself expresses: trigger present, malicious prediction follows.
Clean accuracy is therefore a useful utility measure, not a security certificate. A well-designed model backdoor is supposed to preserve it. The stronger question is whether the model contains a distinctive, causally meaningful path that can be activated by a hidden pattern. If that path is present, the model is compromised even when ordinary validation looks normal.
HAMLOCK starts from this familiar design and removes a key part of it from the software artifact. The model will still be altered, but the alteration is not supposed to make the model choose the wrong class when it runs by itself. The malicious output path is incomplete until hardware supplies the missing interpretation and payload.
A signal is not the same as a behavior
The difference between a behavior path and a signal is easiest to see with an analogy from systems engineering. A temperature sensor can produce a high reading without deciding to shut down a machine. A controller gives that reading an operational meaning and triggers an action. In HAMLOCK, selected neuron activations play the role of the signal. The hardware logic supplies the condition and the response.
The analogy has limits: a neural activation is part of the model's numerical computation, not a separate sensor installed beside it. But the division of meaning is real within the proposed design. The altered model is tuned so that a trigger-dependent input produces unusually high activation values in a few neurons. The model's own output can remain correct. A hardware Trojan watches those values and interprets a particular bit pattern or threshold crossing as “the backdoor condition is present.” Another hardware component then changes the final logits.
This means that the same input can have two different security-relevant descriptions. At the model level, it is a correctly classified image with an unusual internal activation. At the deployed-system level, it is an input that activates hidden hardware control logic and is sent to the wrong target class. Neither description is false. They refer to different execution contexts.
The distinction also prevents a common overstatement. It is not accurate to say that HAMLOCK hides an entire wrong classifier inside a few neurons. The paper's design goal is almost the opposite: use the model to create a narrow, hardware-readable condition and keep the complex detection work out of the hardware. The final malicious behavior is distributed. The model contributes a signal; the hardware contributes the interpretation and the output manipulation.
The diagram shows why the two cases should not be collapsed. A conventional backdoor points directly from the model to the wrong prediction. In HAMLOCK, a model-only test sees a model that is meant to remain correct. The malicious path runs through the detector and payload that are attached to the deployed system.
Why HAMLOCK wants the model to pass
A model that misclassifies its own triggered inputs gives a defender a convenient target. The defender can generate or discover those inputs, observe their labels, and study the model's internal response. HAMLOCK tries to remove that convenience. If the model classifies the triggered sample correctly when it is tested without the compromised hardware, then several ordinary checks lose the behavior they depend on.
A trigger-reversal method may find the visible patch but fail to find a corresponding wrong label. A black-box model test may see no difference between clean and triggered behavior. A model-level scanner may not find a complete trigger-to-target path. A maintainer examining a public model repository may therefore conclude that the weights are safe enough for release, even though those weights were prepared to activate logic elsewhere.
This is not the same as saying that the altered weights are undetectable in every sense. A defender could inspect activation distributions, compare a model with a trusted reference, or examine how the model maps onto a particular accelerator. The paper's claim is more specific: defenses built around a model's own misclassification behavior or a complete model-resident backdoor do not get the signal they expect. The attack changes what “benign behavior” means by making benign software behavior part of the concealment strategy.
The result is a subtle shift in the role of a model repository. In the conventional picture, the repository is where a backdoored artifact can be found or rejected. In HAMLOCK's first threat scenario, the repository can contain a model whose malicious potential is dormant. The repository check is still useful, but it is no longer the final gate. A later hardware handoff can provide the missing component.
The second threat scenario makes the shift even clearer. A victim with enough resources may train a model themselves and therefore trust its origin. The model is then sent to an untrusted hardware manufacturer for deployment. In that scenario, the attack does not need to begin with a suspicious public model. The hardware supplier can make minimal weight changes and insert hardware logic that recognizes them. Model origin and model behavior during ordinary testing can both look trustworthy while the supply-chain handoff creates the composition.
Why a few neurons are more useful than a broad alteration
A conventional backdoor can distribute its behavior across many layers because the model itself must perform every step. HAMLOCK has a different optimization problem. Its altered neurons need to make clean and triggered cases separable enough for simple hardware logic to distinguish them, while avoiding a conspicuous change in normal predictions. The hardware should not have to reproduce the model's complex pattern-recognition work.
The paper describes a single-neuron design and a more generalized multi-neuron design. The single-neuron version focuses on an early layer, where the weights interact directly with the trigger region. The authors tune the neuron so that the trigger produces a high activation while clean inputs remain below a threshold. The multi-neuron version selects a small number of candidate neurons in randomly chosen layers, checks that changing them has little effect on clean accuracy, and uses a calibration set to increase the separation between clean and triggered activations.
The design creates a trade-off rather than a free advantage. More neurons or more distributed conditions can make accidental clean activation less likely, but they can also reduce clean accuracy and increase the amount of hardware monitoring. Fewer neurons make the hardware simpler, but a defender who knows where to look may have an easier time inspecting their activation behavior. The attack therefore depends on choosing a signaling arrangement that is distinctive to hardware without becoming an obvious software anomaly.
That trade-off also clarifies what the model is not responsible for. It is not required to recognize every visual or semantic consequence of a trigger and then construct a wrong answer. It only needs to produce a useful internal separation. The paper moves the expensive, model-specific work into the weights and leaves the hardware with a small decision problem. This is the design choice that links sparsity to stealth.
The hidden dependency is alignment
A signal is useful only if the intended receiver reads it. HAMLOCK therefore depends on alignment between the altered model and the hardware logic. In a dedicated accelerator for a fixed model, the authors argue that the relationship can be established at design time: the hardware logic is integrated with the resources that implement the selected neurons. In a more general accelerator, the proposed threat model gives the attacker control over the compilation or deployment pipeline so that the chosen software neurons are assigned to Trojan-infected physical resources.
This dependency is a boundary, not a minor implementation detail. If a model is moved to hardware that does not contain the detector, its trigger-dependent activations do not produce the paper's malicious output. If the detector monitors the wrong neurons or the model-to-hardware mapping changes in a way the attacker cannot control, the components may stop cooperating. Conversely, when a vendor controls both the weight transformation and the mapping, a model that appears harmless in a public software environment can become meaningful to a particular accelerator.
The supply-chain relationship is therefore part of the mechanism. The model signal does not float freely through every deployment. It is prepared for a hardware context. That makes the attack more constrained than a universal model backdoor, but it also makes ordinary model portability a misleading measure of safety. Portability can hide the dependency because the model is benign on platforms that do not understand its signal.
The new baseline for inspection
The useful baseline is no longer simply “does the model classify correctly?” It is a layered question. Does the model behave correctly on its own? Does the accelerator contain only the intended computation and control logic? Does the build process preserve the approved relationship between model operations and physical resources? Does the deployed system behave correctly when those pieces run together, including under conditions that are rare or conditional?
HAMLOCK does not establish that every one of these questions is equally difficult, nor that model inspection should be abandoned. It demonstrates why they are different questions. A model can be correct and still carry a signal. Hardware can be small and still carry a payload. A deployment can combine them without exposing the complete path to any single software-only test.
That is the conceptual division to retain: a conventional backdoor puts the behavior in the model; HAMLOCK puts a dependency in the model and the behavior in their composition. The next step is to follow that dependency at the level of activations, thresholds, detectors, and output logits—where a sparse signal becomes an operational decision.