Locket: Feature Locking for LLM Monetization

• Locket is a feature-locking system that secures language models by freezing a base model and adding per-feature refusal adapters to enforce authorization.
• It uses adversarial training and post-merge spectral clipping to ensure locked features are fully refused while maintaining high utility on authorized tasks.
• The system supports fine-grained monetization by dynamically merging adapters for unauthorized features, achieving 100% refusal on locked capabilities with minimal impact on allowed functionalities.

Searching arXiv for the target paper and closely related locking work. arXiv.search query: (He et al., 14 Oct 2025) Locket Robust Feature-Locking Technique for LLMs Locket is a feature-locking system for LLMs that is designed to support pay-to-unlock access control at the level of individual capabilities rather than coarse model-wide subscription tiers. It is presented as a feature-locking technique, or FLoTE, for settings in which a provider may want to monetize or regulate capabilities such as math, coding, SQL generation, tool use, summarization, or general knowledge while preserving ordinary utility on authorized tasks. Its central mechanism is to keep a base LLM frozen, train one refusal adapter per feature, and dynamically merge the adapters corresponding to unauthorized features at inference time. In the reported evaluation, this combination yields $100\%$ refusal on locked features, at most $7\%$ utility degradation on unlocked features, and attack success rate at or below $5\%$ under adaptive jailbreak evaluation, while supporting multiple features and clients without per-user retraining (He et al., 14 Oct 2025).

1. Definition and problem formulation

Locket formalizes feature locking as a mapping from features and clients to responses. If the feature set is $\mathcal{F} = \{f_1, f_2, \dots, f_m\}$, then a FLoTE is written as

$$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$

such that for a client $C \in \mathcal{C}$,

$$\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 formulation treats feature-level authorization as a behavioral property of inference rather than as an external billing or routing layer alone (He et al., 14 Oct 2025).

The paper specifies four requirements for an ideal FLoTE. It must be effective, meaning locked features should be refused. It must preserve utility, meaning unlocked features should perform like the original base model. It must be robust, meaning unauthorized users should not recover locked behavior through jailbreaks, adversarial prompts, or credential sharing. It must be scalable, meaning the mechanism should support many features and many clients without combinatorial retraining (He et al., 14 Oct 2025).

This framing is motivated by a practical criticism of coarse subscription schemes. The paper argues that providers may find finer-grained monetization economically preferable, but such a scheme is only viable if capability denial is dependable. A system that merely labels, traces, or post hoc attributes model outputs is insufficient for this purpose. In that respect, Locket belongs to a broader line of work on active model locking rather than passive provenance mechanisms. Earlier locking work in DNN security emphasized prevention of unauthorized use rather than ownership proof, but it typically targeted whole-model execution rather than feature-level LLM behavior (Alam et al., 2020).

2. System architecture and authorization workflow

Locket’s serving model assumes an ordinary provider-side authorization infrastructure. A client first obtains authorization for premium features through an authorization module, for example by payment. The provider maintains an allowed-feature profile for that client. At request time, an access-control module checks permissions, selects the adapters corresponding to the client’s unauthorized features, merges those adapters into the frozen base model, and then serves the request. The system diagram is described as: request authorization, update allowed-feature profile, receive service request, verify permissions, select locking adapters for unauthorized features, merge them into the base model, and answer allowed queries while refusing disallowed ones (He et al., 14 Oct 2025).

The architectural decision that governs scalability is that Locket trains one refusal adapter per feature, not one model per feature subset and not one model per client. If a client lacks several features, the corresponding adapters are merged online into the base model. This realizes multi-feature locking without requiring retraining for each authorization pattern. The paper contrasts this with several alternatives that it dismisses as insufficient: system-prompt-only refusal is easy to bypass; routing among multiple specialized models requires $2^N - 1$ models to support all subsets of $N$ features; detector-based authorization inherits the same combinatorial scaling issue; and password-based locking still depends on credentials that can be guessed, extracted, or shared (He et al., 14 Oct 2025).

The mechanism therefore reverses the usual wake-word design. Rather than granting hidden capability when a secret token is present, it attaches refusal modules for capabilities that should remain unavailable. This eliminates the credential-sharing attack surface that affects password-style schemes. A closely related line of work, Identity Lock, conditions API-fine-tuned LLM behavior on identity-based wake words such as “Hey! [Model Name]!”, and its robustness depends materially on the secrecy and unguessability of the trigger phrase (Su et al., 10 Mar 2025). Locket rejects this design space and instead embeds authorization in provider-controlled adapter composition (He et al., 14 Oct 2025).

3. Training objectives and refusal adapters

Each feature $f_i$ is assigned a LoRA-style adapter $7\%$0, trained specifically to induce refusal on prompts from that feature. The base LLM remains frozen. This separation between frozen shared weights and lightweight feature-specific refusal modules is the basis for Locket’s claim to scalability (He et al., 14 Oct 2025).

The training objective has two terms,

$7\%$1

The utility term preserves ordinary model behavior on authorized data. It compares the adapted model $7\%$2 against a frozen reference copy $7\%$3 on a generic authorized dataset $7\%$4, instantiated as

$7\%$5

The paper’s interpretation is direct: when training an adapter to refuse one feature, the model should not drift far from the base model on unrelated helpful generation (He et al., 14 Oct 2025).

The refusal term is built from a feature-specific preference dataset

$7\%$6

where $7\%$7 is a prompt drawn from the locked feature dataset $7\%$8, $7\%$9 is the useful answer for that feature, and $5\%$0 is a fixed refusal string:

“Sorry, you are not authorized to use the capabilities needed to solve this problem”

The evasion-oriented loss is written as

$5\%$1

Here $5\%$2 denotes perturbing hidden activations under an $5\%$3 budget $5\%$4. The notation is slightly inconsistent in one place, but the procedure described is that a worst-case latent perturbation

$5\%$5

is first computed, and model parameters are then updated to minimize $5\%$6 over the dataset. In implementation, the paper uses PGD with 16 steps and perturbs the embedding and hidden layers $5\%$7 (He et al., 14 Oct 2025).

This use of Latent Adversarial Training is central to Locket’s robustness claim. The intended effect is not merely that the model refuses on clean locked prompts, but that it continues to refuse when hidden states are perturbed in directions that would otherwise reactivate the unauthorized capability. A plausible implication is that Locket treats jailbreak robustness as a representation-space stability problem rather than only as an instruction-following problem.

4. Adapter merging and spectral clipping

The paper identifies multi-adapter composition as the main systems obstacle. Standard LoRA merging methods such as linear arithmetic, CAT, and TIES combine updates additively,

$5\%$8

After LAT, however, refusal directions tend to reinforce each other. When several refusal adapters are merged, the result can be over-refusal, including generic outputs such as “Sorry, sorry, sorry…” even on unlocked prompts. The paper therefore argues that existing merging rules degrade unlocked-feature utility in the multi-lock regime (He et al., 14 Oct 2025).

Locket’s solution is a post-merge spectral clipping rule. For each adapter update matrix $5\%$9 at layer $\mathcal{F} = \{f_1, f_2, \dots, f_m\}$0, the spectral norm is computed from a singular value decomposition

$\mathcal{F} = \{f_1, f_2, \dots, f_m\}$1

with largest singular value

$\mathcal{F} = \{f_1, f_2, \dots, f_m\}$2

A per-layer reference scale is then defined by

$\mathcal{F} = \{f_1, f_2, \dots, f_m\}$3

and the clipping threshold is

$\mathcal{F} = \{f_1, f_2, \dots, f_m\}$4

where $\mathcal{F} = \{f_1, f_2, \dots, f_m\}$5 is tunable (He et al., 14 Oct 2025).

At inference time, the unauthorized-feature adapters are first merged with CAT,

$\mathcal{F} = \{f_1, f_2, \dots, f_m\}$6

and then clipped if their spectral norm exceeds the threshold: $\mathcal{F} = \{f_1, f_2, \dots, f_m\}$7 The final attached layer is

$\mathcal{F} = \{f_1, f_2, \dots, f_m\}$8

Offline, the provider computes $\mathcal{F} = \{f_1, f_2, \dots, f_m\}$9 once per layer. Online, the system selects the adapters for unauthorized features, sums them layerwise, clips if necessary, attaches them to the base model, and runs inference (He et al., 14 Oct 2025).

The paper interprets over-refusal as excessive amplification of refusal directions after merging. Spectral clipping is meant to preserve refusal while damping destructive reinforcement. In an illustrative DeepSeek-7B-Math setting where one feature remained unlocked and three were locked, $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$0 was identified as a “sweet spot” that preserved perfect refusal on locked features while avoiding utility loss on the unlocked feature. The paper states that $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$1 was tuned per feature combination using 100 random test examples (He et al., 14 Oct 2025).

5. Evaluation protocol and empirical performance

The evaluation uses four premium features: Math from MATH, SQL generation from SQL Create Context plus Spider/Seq2SQL style tasks, summarization from SAMSum, and general knowledge from MMLU. UltraChat provides the utility-preservation dataset $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$2. The main model families are DeepSeek-7B-Math, DeepSeek-7B-Coder, and Llama-3-8B-Instruct. DeepSeek-Coder is evaluated on coding-related tasks because it already contains a system prompt refusing non-coding queries (He et al., 14 Oct 2025).

The paper aligns metrics with the four FLoTE requirements.

Requirement	Operationalization	Reported outcome
Effectiveness	Utility on the locked feature’s test set; perfect locking means zero utility	$$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$3 refusal on locked features
Utility	Accuracy for Math and MMLU; Rouge-1 for SQL generation and summarization	At most $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$4 utility degradation
Robustness	Attack success rate from responses lacking refusal keywords such as “sorry,” “I cannot,” or “unable”	ASR at or below $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$5
Scalability	Same effectiveness/utility measures under multiple simultaneous locks	Multiple features and clients supported

Under single-feature locking, all diagonal locked-feature cells are zero, which the paper summarizes as $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$6 refusal on locked features. Unlocked tasks usually remain near baseline. Examples given for DeepSeek-7B-Math include baseline scores of 0.40 on Math, 0.93 on SQL, 0.23 on Summarization, and 0.53 on MMLU; when Math is locked, MMLU drops only from 0.53 to 0.51. On Llama-3-8B-Instruct, highlighted single-feature drops include Math-locking causing MMLU to fall from 0.67 to 0.64, and MMLU-locking reducing Math from 0.28 to 0.22. The paper attributes such degradations mainly to feature overlap, especially between Math and some MMLU questions (He et al., 14 Oct 2025).

Robustness is evaluated in a black-box API threat model using adaptive jailbreaks as the strongest prompt-based setting. The attacks are Many-shot Jailbreaking, GCG, TAP, and AutoDAN-Turbo. Across tested models and locked features, Locket’s ASR remains in the $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$7–$$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$8 range. On DeepSeek-7B-Math, one locked feature yields ASR values of $$\mathcal{FLoTE}: \mathcal{F} \times \mathcal{C} \to \mathcal{R}$$9, $C \in \mathcal{C}$0, $C \in \mathcal{C}$1, and $C \in \mathcal{C}$2 under Many-shot, GCG, TAP, and AutoDAN respectively, while the password baseline yields $C \in \mathcal{C}$3, $C \in \mathcal{C}$4, $C \in \mathcal{C}$5, and $C \in \mathcal{C}$6. On DeepSeek-7B-Coder, Locket yields $C \in \mathcal{C}$7, $C \in \mathcal{C}$8, $C \in \mathcal{C}$9, 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}$$0, versus $$\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, $$\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, $$\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, 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 the password baseline. Similar patterns are reported for Llama-3-8B-Instruct. These results are specifically stated for single-feature-locked models, using 1,000 random samples per feature dataset and deterministic generation at temperature zero (He et al., 14 Oct 2025).

The multi-feature setting is important because it exposes the limits of password-style locking. In a Math+SQL lock on DeepSeek-7B-Math, password-locking fails to keep Math fully locked, showing utility 0.35 instead of 0.00, whereas Locket keeps 0.00. In a Math+SQL+Summarization lock, password-locking still leaks Math at 0.26 and harms MMLU to 0.46, whereas Locket keeps locked features at 0.00 and MMLU at 0.53. The paper interprets this contrast as an effect of catastrophic forgetting in full fine-tuning baselines versus frozen-base adapter composition in Locket (He et al., 14 Oct 2025).

6. Relation to other locking paradigms, limitations, and open questions

Locket is part of a broader family of “locking” methods, but its target object is different. Deep-Lock encrypts trained DNN parameters with per-parameter keys so that the model behaves correctly only under the correct key, emphasizing prevention of unauthorized use of the model artifact itself (Alam et al., 2020). ModelLock instead shifts a vision model’s effective operating distribution by fine-tuning on diffusion-edited data, so the model works on transformed inputs and fails on clean ones unless the correct edit pipeline is applied (Gao et al., 2024). IdentityLock ties API-fine-tuned LLM functionality to wake words, so useful behavior appears only when the correct phrase is prepended (Su et al., 10 Mar 2025). Locket differs from all three in that it does not lock the entire model, does not rely on secret prompts or wake words, and does not require user-supplied credentials at inference time; it locks selected capabilities by composing provider-side refusal adapters (He et al., 14 Oct 2025).

This distinction matters because a common misconception is to treat feature locking as a variant of ordinary prompting or model routing. The paper explicitly argues otherwise. System-prompt refusal is presented as easy to bypass; routing across specialized models scales 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}$$5 models for $$\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 features; detector-based authorization inherits combinatorial burden; and password locking inherits both jailbreak vulnerability and credential-sharing failure modes. Locket’s claim is that robust feature denial requires both adversarially trained refusal modules and a merge rule that remains stable under multi-feature composition (He et al., 14 Oct 2025).

The paper also states several limitations. It evaluates only three model families and four features, so cross-family generality and larger feature sets remain unverified. It cites prior model-merging work suggesting that around 12 adapters might be mergeable with at most 20% utility drop, but does not validate Locket at that scale. It does not reduce underlying inference cost, because refusal still runs the model. Feature interference remains unresolved; the paper notes that MMLU contains math-related questions, so locking Math can slightly impair MMLU. Finally, robustness is framed as an arms race: the reported ASR is low against current jailbreak attacks, but stronger future attacks may emerge (He et al., 14 Oct 2025).

From a deployment perspective, Locket assumes that authentication and authorization already exist outside the model. The provider maintains the frozen base model, the per-feature LoRA adapters, the authorization and access-control modules, and the offline-computed clipping thresholds $$\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. The implementation uses LoRA rank 64, alpha 64, dropout 0.1, and RSLoRA. The full study is reported to consume about 5,000 GPU-hours on 8 NVIDIA A100s. This suggests that Locket’s principal deployment cost is not per-user retraining, which it avoids, but adapter training and inference-time merging overhead (He et al., 14 Oct 2025).