Feature-Locking Technique (FLoTE)

• FLoTE is a control paradigm that locks ML model features to authorized hardware or domains, ensuring functionality only under permitted conditions.
• It employs soft locking via sparsity and quantization techniques to maintain high accuracy on authorized setups while degrading performance on unauthorized ones.
• Locket extends FLoTE to language models by integrating per-feature refusal adapters, preserving utility on licensed features and enforcing robust access control.

Searching arXiv for the cited papers to ground the article. First, retrieving the hardware-locking paper. Feature-Locking Technique (FLoTE) denotes a class of mechanisms that make a model’s effective behavior contingent on an authorization condition rather than merely proving ownership after the fact. In current work, two distinct but related instantiations appear. One binds a trained model to a hardware stack so that execution on unauthorized hardware is either impossible or substantially less performant or less accurate; the other locks capability domains of a LLM so that unauthorized features are refused while authorized features remain usable (Clifford et al., 2024, He et al., 14 Oct 2025). Across both lines, the defining property is selective functionality: the model is intended to remain operational in an authorized regime and to degrade, refuse, or collapse outside it.

1. Definition and conceptual scope

In the LLM setting, FLoTE is formalized over a feature set $\mathcal{F} = \{f_1,\dots,f_m\}$, a set of clients $\mathcal{C}$, and response space $\mathcal{R}$, with behavior specified as follows (He et al., 14 Oct 2025):

$$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$

This framing treats “features” as distinct capability domains such as Math, SQL, Summarization, or General Knowledge. Authorization is external to the model: providers authenticate clients separately, and the model is configured at inference time to refuse only those features not licensed for that client (He et al., 14 Oct 2025).

In hardware-bound model locking, the terminology is different but the functional idea is closely aligned. “Machine learning locking” is defined as mechanisms that bind a trained model to a particular hardware stack so that running it elsewhere is either impossible (“hard locking”) or substantially less performant or less accurate (“soft locking”) (Clifford et al., 2024). The paper does not name this a FLoTE, but its mechanisms implement feature-locking in the sense that effective model behavior depends on hardware-specific properties rather than on possession of the model artifact alone.

A useful taxonomy therefore separates FLoTEs by what carries authorization. In hardware locking, authorization is carried by intrinsic support for particular numeric or sparsity representations, or by device-specific fingerprints such as timing, finite precision signatures, or SRAM PUFs. In LLM pay-to-unlock systems, authorization is carried by provider-side policy and realized through selective attachment of refusal-inducing adapters (Clifford et al., 2024, He et al., 14 Oct 2025). This suggests that FLoTE is better understood as a control paradigm than as a single algorithm.

2. Soft feature-locking through representational asymmetry

Soft feature-locking exploits the fact that different accelerators support different intrinsics, arithmetic formats, and sparsity mechanisms. The hardware-locking work instantiates this by training objectives that preserve accuracy under an authorized representation while driving accuracy down under an unauthorized one (Clifford et al., 2024).

For sparsity-aware locking, let $f_p(x,p)$ denote the pruned network at proportion $p$ using $l_1$-unstructured pruning. The reported objective is

$$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$

Here $p_1$ is the authorized sparsity level and $p_2$ the unauthorized one. The intended effect is that features remain intact under $\mathcal{C}$0 and become deliberately fragile under $\mathcal{C}$1. Because only some accelerators implement sparse acceleration natively, unauthorized devices either emulate sparsity slowly or use a different sparsity regime and lose accuracy (Clifford et al., 2024).

For quantization-aware locking, the paper uses an analogous loss over arithmetic formats:

$\mathcal{C}$2

The network is evaluated under simulated authorized and unauthorized arithmetic during fine-tuning, with examples including FP32, FP16, Int8, and MiniFloat8. The effect is to lock features to numeric representations supported by the intended hardware. Unauthorized devices then face a choice between severe accuracy loss under a mismatched format and slow software emulation of unsupported formats (Clifford et al., 2024).

The empirical setup covers ResNet18 and ResNet50 on CIFAR-10, CIFAR-100, and Flowers102, ViT-B_16-224 on the same vision datasets, and BERT-base-cased fine-tuned on GLUE tasks including SST-2, CoLA, and MRPC. For sparsity-aware locking, fine-tuning is reported for 25 epochs on vision models and 3 epochs on LLMs with $\mathcal{C}$3, $\mathcal{C}$4, AdamW with learning rate $\mathcal{C}$5, and seed $\mathcal{C}$6. Quantization-aware locking uses 50 epochs with AdamW, learning rate $\mathcal{C}$7, batch size $\mathcal{C}$8, and seed $\mathcal{C}$9, with formats simulated in FP32 during fine-tuning (Clifford et al., 2024).

The significance of this line of work is that it turns representational choices into an access-control surface. Unlike watermarking, which proves ownership after misuse, or centralized serving, which avoids local disclosure by keeping the model remote, soft feature-locking attempts to preserve on-device deployment while making unauthorized transfer inconvenient or inaccurate (Clifford et al., 2024).

3. Hard feature-locking through hardware fingerprints and parameter transforms

Hard feature-locking ties model usability to device-specific physical or implementation properties. The core mechanism is to derive a key from a hardware fingerprint and transform parameters so that only authorized hardware can recover usable weights at load time (Clifford et al., 2024).

The paper evaluates three fingerprint sources. A clock fingerprint measures cycles for repeated additions on CUDA GPUs and yields a 20-bit hexadecimal value tied to device family or model; examples reported in Table 3 are GP102 varying stochastically between 72100 and 723ff, TU102 yielding 49a59, and GA102 yielding 4b85a. A finite precision fingerprint hashes numerical error signatures, using SHA-256 over error from sequences of linear layers produced by framework and device precision idiosyncrasies. An SRAM PUF fingerprint uses intrinsic or unadvertised PUFs, such as initial SRAM states on NVIDIA GPUs, together with fuzzy extractors to derive stable, high-entropy device keys with more than 256 bits usable for AES (Clifford et al., 2024).

Key derivation is specified as $\mathcal{R}$0, where $\mathcal{R}$1 is the fingerprint of hardware $\mathcal{R}$2. Parameter locking then applies a transformation $\mathcal{R}$3 and authorized execution applies the inverse:

$\mathcal{R}$4

If the hardware does not produce the correct key, the detransformed parameters are intended to remain statistically plausible in aggregate while being functionally random. The paper describes this through an informal compatibility predicate $\mathcal{R}$5, equal to $\mathcal{R}$6 when the fingerprint matches the authorized hardware and $\mathcal{R}$7 otherwise (Clifford et al., 2024).

Three parameter transformations are compared against indistinguishability, encryption, and destruction. AES encryption over serialized parameters provides perfect encryption and destruction, but wrong-key outputs are uniformly random bytes and therefore statistically unlike real parameters. Parameter shuffling seeds a permutation with the fingerprint-derived key; it achieves near-perfect indistinguishability and destruction, but leaks some aggregate statistics. Pre-transformed AES first maps the parameter distribution to uniform byte-space, then encrypts it, and finally inverts the mapping after decryption. The empirical CDF variant avoids the outlier-induced infinities of a Gaussian CDF assumption and is reported to achieve indistinguishability, encryption, and destruction simultaneously (Clifford et al., 2024).

The hardware-locking paper also proposes a conceptual degradation function,

$\mathcal{R}$8

with soft locks seeking $\mathcal{R}$9 and hard locks seeking unauthorized accuracy near random guessing, approximately $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$0 on CIFAR-10. Cracking cost is described as scaling with fingerprint entropy $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$1, and the paper reports empirical factors on a toy model of $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$2 seconds for AES, $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$3 for parameter shuffling, and $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$4 for pre-transformed AES (Clifford et al., 2024).

This branch of FLoTE is closer to cryptographic access control than to behavioral shaping. However, the paper explicitly notes entropy limits, especially for clock and finite precision fingerprints, so the mechanism is not presented as unbreakable. Its intended security effect arises from hardware asymmetry, fingerprint entropy, and, in the indistinguishable variants, the need to evaluate full model accuracy during brute-force search (Clifford et al., 2024).

4. Locket: feature-level access control for LLMs

Locket generalizes FLoTE to a pay-to-unlock setting for LLMs, where clients purchase access to selected capability domains rather than to a monolithic “pro” model (He et al., 14 Oct 2025). The central requirement is not hardware exclusivity but controlled refusal: the model must reject locked features, preserve utility on unlocked features, resist evasion and credential sharing, and scale to many features and clients.

The system architecture has four main components: a frozen base LLM $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$5, one LoRA-based adapter $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$6 per feature, an authorization module that stores each client’s allowed feature set, and an access control module that determines which features are unauthorized for a request and therefore which locking adapters must be attached (He et al., 14 Oct 2025). The model does not rely on in-prompt secrets, passwords, or wake words. That design choice is central to its robustness claim against credential sharing.

Training uses one adapter per feature to induce refusal on the corresponding unauthorized domain while preserving behavior on generic authorized data. The overall loss is

$$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$7

with the utility-preserving term defined as

$$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$8

where $$\mathcal{FLoTE}(f_i, C) = \begin{cases} \text{valid response}, & \text{if } f_i \text{ is authorized for } C,\ \text{refusal}, & \text{otherwise.} \end{cases}$$9 is a frozen reference model and $f_p(x,p)$0 is UltraChat. Robust refusal is induced through Latent Adversarial Training over feature-specific unauthorized data $f_p(x,p)$1, where $f_p(x,p)$2 is the fixed refusal response and $f_p(x,p)$3 the useful answer. The reported evasion loss is

$f_p(x,p)$4

and sample-wise perturbations satisfy

$f_p(x,p)$5

under an $f_p(x,p)$6 budget $f_p(x,p)$7 (He et al., 14 Oct 2025). The adapters use RSLoRA with rank $f_p(x,p)$8, alpha $f_p(x,p)$9, and dropout $p$0.

A distinct contribution of Locket is its merge-time control of multiple refusal adapters. Naïve additive merging, including CAT or simple task arithmetic, can reinforce refusal directions excessively and produce over-refusal on otherwise authorized tasks. Locket addresses this by clipping the spectral norm of the merged adapter update at each layer. If $p$1 is the update for feature $p$2 at layer $p$3, the per-layer threshold is

$p$4

and the runtime merge for the selected unauthorized set $p$5 is

$p$6

followed, when necessary, by

$p$7

The paper also expresses each adapter via an SVD $p$8, with spectral norm $p$9 and reference scale $l_1$0 (He et al., 14 Oct 2025). A reported sensitivity study identifies a “sweet spot” at $l_1$1 in a representative three-lock DeepSeek-7B-Math setting.

The evaluated premium features are Math, SQL, Summarization, and General Knowledge, using MATH, Seq2SQL and Spider, SAMSum, and MMLU respectively. The base models are DeepSeek-7B-Math, DeepSeek-7B-Coder, and Llama-3-8B-Instruct. Evaluation uses temperature $l_1$2 for determinism (He et al., 14 Oct 2025).

5. Reported empirical behavior

The two strands of FLoTE are evaluated with different operational metrics. Hardware locking emphasizes authorized-versus-unauthorized accuracy gaps, emulation overheads, and cracking cost. Locket emphasizes refusal effectiveness, preserved utility on unlocked tasks, jailbreak robustness, and scalability under multiple concurrent locks (Clifford et al., 2024, He et al., 14 Oct 2025).

Setting	Reported outcome	Source
ResNet18 on CIFAR-10, sparsity-aware lock at $l_1$3	$l_1$4 for $l_1$5	(Clifford et al., 2024)
ResNet50 on CIFAR-100, sparsity-aware lock at $l_1$6	$l_1$7	(Clifford et al., 2024)
ResNet50, FP16 $l_1$8 Int8 quantization-aware lock	$l_1$9	(Clifford et al., 2024)
CIFAR-10 FP16 ResNet18 under hard locking	Original $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$0; transformed-only $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$1; correctly detransformed $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$2; incorrectly detransformed $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$3	(Clifford et al., 2024)
A6000 emulation cost	Sparse matmul slowdown $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$4; quantized matmul slowdown $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$5	(Clifford et al., 2024)
Locket across tested models and features	$$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$6 refusal on locked features, $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$7 utility degradation on unlocked features, and $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$8 ASR under adaptive attacks	(He et al., 14 Oct 2025)

For hardware-bound soft locking, the paper reports negligible degradation relative to the original model in the authorized regime and large drops in the unauthorized one. Representative examples include ResNet18 on CIFAR-10 at $$\mathcal{L} = \mathcal{L}(f_p(x, p_1), y) + \lambda (\epsilon - \mathcal{L}(f_p(x, p_2), y))^2.$$9 with $p_1$0, ResNet50 on CIFAR-100 at $p_1$1 with $p_1$2, ViT-B_16-224 on CIFAR-100 at $p_1$3 with $p_1$4, and BERT on SST-2 at $p_1$5 with $p_1$6. The reported baseline comparison shows negligible drop when merely changing sparsity without locking, supporting the claim that the lock training itself causes the degradation (Clifford et al., 2024).

Quantization-aware locking shows strong degradation for mismatched arithmetic pairs such as FP32 $p_1$7 MiniFloat8 and MiniFloat16 $p_1$8 Int8. By contrast, Int8 $p_1$9 MiniFloat8 “did not degrade substantially,” which the paper interprets as smaller representational mismatch for those pairs (Clifford et al., 2024). This indicates that soft FLoTE depends materially on the choice of authorized and unauthorized representations rather than on quantization in the abstract.

Hard locking is evaluated on a CIFAR-10 FP16 ResNet18 test case, where transformed-only and incorrectly detransformed models remain near random guessing while correct detransformation restores full original accuracy. For low-entropy fingerprints, the reported cracking-cost factors quantify the value of indistinguishability: wrong keys cannot be rejected by simple statistical tests and must be validated through model behavior (Clifford et al., 2024).

Locket’s evaluation reports effectiveness as utility on the locked feature’s test set, with $p_2$0 implying complete refusal. Across all tested models and features, locked tasks are reported to reach $p_2$1 refusal, while unlocked features remain at baseline or within $p_2$2 degradation. Robustness is measured by attack success rate under NaiveJB, NonAdptJB, and AdptJB attacks, with the strongest adaptive suite including Many-shot, GCG, TAP, and AutoDAN-Turbo. Reported examples on DeepSeek-7B-Math are $p_2$3 for Many-shot, $p_2$4 for GCG, $p_2$5 for TAP, and $p_2$6 for AutoDAN, with the notation “$p_2$7PWD$p_2$8 | $p_2$9LOCKET$\mathcal{C}$00” indicating a comparison against password-locked baselines (He et al., 14 Oct 2025).

A plausible implication is that the two strands optimize different notions of unauthorized use. Hardware locking seeks to make transfer costly or nonfunctional even when the model artifact is fully exposed, whereas LLM FLoTE as instantiated by Locket assumes a service setting and focuses on refusing disallowed capability domains under adversarial prompting.

6. Relation to adjacent methods, limitations, and open issues

FLoTE is distinct from several adjacent approaches. In the hardware paper, TEEs and secure enclaves are described as providing strong isolation and attestation but requiring vendor support and incurring nontrivial overheads; MPC and HE provide strong privacy but remain impractical for on-device inference; watermarking and model fingerprinting provide ownership proof rather than usage prevention; obfuscation raises reverse-engineering costs without necessarily binding functionality to hardware; and centralized serving prevents on-device leakage but precludes offline use (Clifford et al., 2024). In the LLM paper, prompt-level guardrails are treated as easily jailbroken, password-locked or backdoor-trigger models as brittle and unscalable, router-based solutions as requiring $\mathcal{C}$01 models to cover feature combinations, and external detectors as facing combinatorial complexity in multi-feature authorization (He et al., 14 Oct 2025).

Several common misconceptions follow from these comparisons. FLoTE is not equivalent to watermarking, because its aim is active access control rather than ex post attribution. It is also not necessarily synonymous with cryptographic confidentiality: the hardware paper explicitly notes entropy limits for clock fingerprints and correlations in finite precision fingerprints, and therefore does not claim unbreakability (Clifford et al., 2024). In the LLM setting, FLoTE is not implemented as a password hidden inside prompts; Locket is designed specifically to avoid in-model secrets and the credential-sharing attack surface that accompanies them (He et al., 14 Oct 2025).

The limitations are correspondingly concrete. For hardware locking, clock fingerprint entropy has an upper bound of 20 bits, finite precision entropy is limited and correlated, clock values can vary stochastically across runs or units, firmware and framework changes can alter precision fingerprints, and the Gaussian CDF pre-transform can produce infinities for outliers. The empirical CDF transform addresses the last issue at an $\mathcal{C}$02 setup cost, and locking to device families rather than single units can improve deployability, but brittleness remains a practical concern (Clifford et al., 2024). Soft locks also exhibit specificity: sparsity locks can produce localized degradation near the targeted unauthorized sparsity, so if the attacker’s target is uncertain the paper recommends locking multiple $\mathcal{C}$03 values or using conservative $\mathcal{C}$04 (Clifford et al., 2024).

For Locket, the stated scope is three 7–8B models and four feature domains. The paper reports that one adapter per feature scales to multiple concurrent locks and many clients, but more comprehensive scaling studies are left to future work. Residual utility degradation is attributed primarily to cross-feature interference, such as overlap between Math and MMLU. The paper also describes an ongoing arms race with stronger jailbreaks and notes that the method does not reduce inference cost; it complements monetization schemes rather than optimizing serving efficiency. Fairness and access equity are not explicitly studied, though the paper notes the potential policy implications of paywalled capabilities (He et al., 14 Oct 2025).

Taken together, the available literature presents FLoTE as a broader access-control design space with at least two mature formulations. One uses hardware asymmetry and device fingerprints to bind model parameters or representations to specific execution substrates. The other uses per-feature refusal adapters and controlled merging to impose capability-level authorization in API-served LLMs. Both aim to move beyond passive ownership signals toward mechanisms that materially constrain unauthorized use, but they do so under different threat models, with different failure modes, and with different notions of what it means for a feature to be “locked” (Clifford et al., 2024, He et al., 14 Oct 2025).