Locket: Robust Feature-Locking Technique for Language Models

TL;DR

LOCKET introduces a robust, scalable feature-locking framework for pay-to-unlock schemes in LLM services by attaching per-feature adapters to a frozen base model and merging them with spectral-norm clipping to prevent over-refusal. It couples utility-preserving fine-tuning with latent adversarial training to harden refusals against adversarial prompts, and uses a dynamic access-control module to attach only authorized adapters per client. Empirical results across four premium features and multiple models show 100% refusal on locked features, ≤7% utility degradation on unlocked features, and ≤5% attack success rates, with clear scalability to multiple features and clients. The approach avoids secret credentials and demonstrates improvements over prior password-based methods, offering practical pay-to-unlock capabilities for feature-tiered LLM services while maintaining base-model fidelity and robustness to evolving attacks.

Abstract

Chatbot providers (e.g., OpenAI) rely on tiered subscription schemes to generate revenue, offering basic models for free users, and advanced models for paying subscribers. However, a finer-grained pay-to-unlock scheme for premium features (e.g., math, coding) is thought to be more economically viable for the providers. Such a scheme requires a feature-locking technique (FLoTE) which is (i) effective in refusing locked features, (ii) utility-preserving for unlocked features, (iii) robust against evasion or unauthorized credential sharing, and (iv) scalable to multiple features and users. However, existing FLoTEs (e.g., password-locked models) are not robust or scalable. We present Locket, the first robust and scalable FLoTE to enable pay-to-unlock schemes. Locket uses a novel merging approach to attach adapters to an LLM for refusing unauthorized features. Our comprehensive evaluation shows that Locket is effective ($100$% refusal on locked features), utility-preserving ($\leq 7$% utility degradation in unlocked features), robust ($\leq 5$% attack success rate), and scales to multiple features and clients.

Figures (2)

• Figure 1: Summary of LOCKET: ➊ Client requests authorization for a premium feature $f_j$ (e.g., via payment), handled by the authorization module. ➋ Authorization module updates the client's profile with a new set of allowed features. ➌ Client submits a service request, received by the access control module. ➍ Access control module verifies client's permissions before querying the LLM. ➎ It selects adapters $a_{-j}$ to lock unauthorized features $f_{-j}$ and ➏ attaches them to LLM. ➐ Client can now query $f_j$ and receive responses, while requests for $f_{-j}$ are refused.
• Figure 2: These are illustrative examples for DeepSeek-7B-Math. We observe similar patterns in other models and locking combinations. (Top) LOCKET merging significantly reduces U's over-refusal rate compared to prior merging methods; (Bottom) Scaling hyperparameter $\tau$ should be chosen to balance trade-off between effectiveness and utility. Here, only U is unlocked; vertical line indicates the sweet spot for $\tau$ (high refusal for locked and no utility drop on unlocked features). See Appendix \ref{['app:implementation']} for other $\tau$ values.