The Backdoor That Needs Two Artifacts
HAMLOCK—short for HArdware-Model LOgically Combined attacK—is a proposed backdoor attack in which a neural-network model and the hardware running it cooperate to produce a malicious result. The model can look clean when inspected on its own, while a modified accelerator supplies the missing step that turns a trigger into a misclassification. This opening focuses on the question that makes HAMLOCK important: when behavior emerges from a model and a chip together, which one is actually being tested? Understanding that question gives readers a way to judge both the paper's evidence and the wider security problem around AI accelerators.
That question is easy to miss because modern AI systems are usually discussed as if the model were the system. We download weights, run validation data through a framework, compare accuracy with a trusted reference, and treat a successful test as evidence that the deployed model behaves correctly. The assumption is reasonable when the hardware is an interchangeable platform with no independent role in the decision. It becomes weaker when an accelerator contains specialized logic, when its design or compilation is performed by another organization, or when the model's internal values are interpreted by hardware before the output reaches the user.
HAMLOCK is built around that gap. Its authors do not describe a model that openly learns “when this pattern appears, choose the wrong class.” Instead, they describe a model that can emit a distinctive internal signal when a trigger is present. Hardware watches for that signal and then changes the final output. Neither artifact has to reveal the complete backdoor path by itself. The behavior becomes malicious at the point where the two artifacts meet.
The clean model is not the whole system
A neural network is a mathematical function implemented through weights, activations, and operations. But a deployed inference system is larger than that function. It includes the memory that stores parameters, the accelerator datapath that performs calculations, the software stack that maps operations onto hardware, and the control logic that turns numerical results into an output. Most of the time these layers cooperate for performance rather than for security analysis. HAMLOCK asks what happens when one layer is intentionally made to interpret a harmless-looking signal from another.
The distinction matters especially for specialized hardware. The paper focuses on Edge AI and Internet of Things applications, where FPGAs and custom ASICs are used because area, energy, and latency matter. Such devices are commonly designed, manufactured, or configured through supply chains that involve third parties. A model may come from a public repository. A model owner may send a trusted set of weights to an external design house. A compiler or bitstream-generation flow may decide where software neurons live in physical resources. The person validating the model may not be the person who can inspect the returned hardware at the same level of detail.
The surrounding infrastructure is also becoming more accelerator-heavy. NIST's initial public draft on AI data-center security describes computing zones filled with specialized accelerators, high-bandwidth memory, high-speed interconnects, and software development kits. It treats model training and inference as part of a larger environment that also contains storage, access, and management zones. Those zones move data, models, credentials, firmware, and operational decisions between different owners. NIST identifies supply-chain, provenance, firmware, accelerator, and multi-tenant risks as part of this environment, even though the draft is not a HAMLOCK-specific analysis.
That context does not prove that a HAMLOCK-style attack is common. It explains why the paper's boundary is consequential. A cross-layer attack needs a place where model and hardware decisions can be coordinated. Accelerator-oriented AI systems provide many such handoffs, and a software-only validation process may observe only one side of them.
The diagram's key distinction is not that hardware always changes a model's answer. It is that the model can behave correctly in isolation while the combined system behaves differently. The clean input follows the ordinary path. A triggered input still passes through the model, but its internal activations can supply a signal that has no malicious meaning until the modified accelerator interprets it.
What a conventional backdoor leads us to expect
To see what HAMLOCK changes, start with the familiar model-level backdoor. In a conventional attack, an adversary poisons training data or changes model parameters so that a particular trigger causes a wrong target label. The model is expected to classify ordinary inputs correctly, preserving clean accuracy, but to misclassify inputs containing the trigger. The malicious relationship is therefore present in the model's own behavior: trigger in, wrong label out.
That relationship creates something a defender can search for. A model inspection may look for unusual weights or activation patterns. A trigger-reversal method may search for a small input pattern that reliably causes a target class. A black-box test may compare predictions on clean and transformed inputs. These methods differ in quality, but they share an assumption: the model itself contains enough of the backdoor to expose a link between a trigger and a wrong prediction.
Clean accuracy was never a complete security test. A conventional backdoor is designed to preserve it. But the model still contains the full functional path that makes the attack work. That path may be subtle, distributed across layers, or difficult to distinguish from normal behavior, yet it remains a property of the software artifact.
HAMLOCK changes the location of that property. Its software component is meant to remain functionally benign, including on inputs carrying the trigger. The model is not supposed to select the attacker's target class by itself. Instead, a few altered neurons are used as a signaling channel. When the trigger is present, their activations become unusually distinctive. The hardware is responsible for recognizing that condition and delivering the misclassification payload.
This is why calling HAMLOCK simply “a model backdoor” loses the important point. The model weights are part of the attack, but they are not the whole attack. They carry information that another artifact is prepared to read. The malicious behavior is a relationship between artifacts, not a complete behavior stored in one of them.
Three responsibilities divided across the boundary
At a high level, HAMLOCK divides the attack into three responsibilities.
First, the model provides a trigger signal. The authors alter a small number of neurons so that a trigger causes unusually high activations while clean inputs stay below a chosen separation threshold. The modification is intended to preserve normal predictions. In the paper's generalized variant, the signaling neurons can be distributed across several randomly selected layers, making the change less like a single obvious feature and allowing hardware to require several conditions at once.
Second, a hardware trigger detector watches the relevant internal values during inference. The paper describes detectors that inspect a sign bit or exponent field of floating-point activations and combine conditions from several neurons. This is not a second neural network hidden in the chip. It is lightweight comparison and control logic whose meaning comes from the altered model's signaling behavior.
Third, a hardware payload changes the final decision when the detector asserts the trigger condition. The paper describes biasing a target logit's exponent so that the attacker's chosen class wins the final comparison. The detector answers “is the condition present?” The payload answers “what output should the compromised system force?” Keeping those jobs separate lets the hardware remain small while the model does the more complicated work of making the signal distinctive.
The split also explains why the attack can look clean from different viewpoints. A model maintainer may run the weights on ordinary hardware and see correct predictions. A hardware evaluator may see a small amount of comparison and bias logic without knowing that particular neuron activations were tuned to activate it. An end user may see a wrong answer only when a precise trigger reaches the deployed combination. Each observation can be accurate and still incomplete.
The paper reports near-perfect attack success across several benchmark datasets and architectures when the Trojan hardware is present, with only small clean-accuracy effects in the reported settings. Those results are important, but they should be read as evidence for the proposed mechanism under stated assumptions—not as evidence that every accelerator or every model can be compromised in the same way. The authors evaluate selected architectures, synthesized hardware, public datasets, and post-training defenses. They also state that they did not implement hardware logic testing or side-channel analysis against the attack in their evaluation.
Why the interface changes the security question
The most important consequence of HAMLOCK is a change in the unit of trust. Instead of asking only whether the weights are clean, a defender has to ask whether the model, the hardware, and the process that maps one onto the other are consistent with one another. That process may include model conversion, memory placement, accelerator configuration, bitstream generation, or chip design. It is where a signal that is meaningless to ordinary software can become a control input to malicious hardware.
This does not mean that model scanning has no value. It means that its conclusion must be scoped correctly. “The model did not misclassify during testing” supports a claim about that model in that execution context. It does not by itself establish that a returned accelerator has no logic capable of interpreting the model's internal state differently. Conversely, a hardware component that passes a structural inspection may still participate in a malicious composition if the corresponding model alterations are not included in the test.
NIST's draft uses a related systems perspective when it discusses data and model provenance, firmware integrity, monitoring, zero trust, and verification by design. Those ideas do not directly validate HAMLOCK's proposed controls, and the draft remains an initial public document rather than a final standard. But they point toward the right question: can an operator preserve trustworthy evidence as data becomes weights, weights become a deployment artifact, and that artifact runs on specialized hardware shared by many parties?
HAMLOCK therefore deserves attention not because it proves that clean-looking AI components are always deceptive, but because it demonstrates a concrete way for the meaning of one component to depend on another. The attack makes a model's apparent innocence conditional on where and how it runs. The practical judgment this series will develop is correspondingly narrow and useful: a model test can establish something about a model, and a hardware test can establish something about hardware, but confidence in the deployed system requires evidence about the composition.
That is the boundary to carry forward. If the model still predicts correctly on triggered inputs, the next question is not whether nothing changed. It is what changed inside the model, who can read that change, and where the missing work moved. HAMLOCK's answer begins with a signal that looks harmless until the accelerator is ready to understand it.