A frontier model's weights represent hundreds of millions of dollars of compute and years of data work, and they carry every capability the model has, including the ones its safeguards suppress. Steal the weights and you have the capability without the classifiers, the rate limits or the monitoring. That is why RAND's 2024 report called them the crown jewels, why the EU code of practice and the G7 code both require weight protection, and why California SB 53 and New York's RAISE Act define unauthorised access to or theft of weights as a critical safety incident that must be reported within days. The same logic applies at smaller scale to any organisation whose fine-tuned models embody proprietary data, and to any deployer whose model weights are a supply chain input.
The five levels
RAND's framework defines security levels by the attacker a system should withstand. SL1 resists opportunistic amateurs. SL2 resists professional criminals and hacktivist groups. SL3 resists well-resourced organised crime, corporate espionage and, critically, insider threats. SL4 resists standard state-level operations. SL5 resists the top-priority operations of the most capable state programmes. The 2024 report assessed that no lab could then withstand a determined state and that SL5 requires government assistance, and it catalogued 38 attack vectors: credential theft and phishing, insider action, supply chain compromise of hardware and software, exploitation of the model serving infrastructure, side channels, physical access to data centres, and misuse of legitimate access such as fine-tuning APIs that leak model knowledge. Google DeepMind's Frontier Safety Framework defines its security levels on this scale; Anthropic's RSP cites the report to explain why higher security levels cannot be reached unilaterally.
SL3 as an implementable target
In 2026 RAND published a framework for achieving SL3, which most experts consider the realistic near-term goal for a well-run organisation. It adapts 262 controls from SP 800-53 and maps them against 31 high-feasibility attack vectors, with a planner that shows which controls address which vectors and an implementation horizon of six to twelve months. The control families will be familiar: identity and access management with phishing-resistant multi-factor authentication and hardware-backed keys; strict separation of development, training and serving environments; encryption of weights at rest and in transit with keys held outside the compute environment; confidential computing for inference where available; egress monitoring and data loss prevention on the paths weights could travel; supply chain controls on the software and hardware in the training cluster; comprehensive logging with tamper resistance; and an insider threat programme with two-person rules for weight access, background checks and behavioural monitoring. What is distinctive is the emphasis on insiders, because at SL3 the most feasible attack is a person with legitimate access, and on the serving stack, because a model that can be queried can be partially extracted.
Extraction through the front door
Weight security is not only about the files. A model exposed through an API can be distilled by a competitor or an adversary who collects enough outputs, and fine-tuning APIs can leak information about the base model. Model developers now treat distillation as a security threat: rate limiting, output watermarking, anomaly detection on query patterns and terms of service enforcement are the controls, and several 2026 announcements described detecting large-scale distillation campaigns. For enterprises exposing their own fine-tuned models, the same applies at smaller scale: monitor for systematic probing, limit the information in outputs (rounded scores, no logits) and treat a customer who is downloading your model one query at a time as an attacker.
Below the frontier
Most organisations are not frontier labs, but the framing transfers. Ask which attacker your weights should resist. A fine-tuned model containing customer interaction patterns is worth SL2 protection against criminals; a model that embodies a regulated decision process, or one that grants an advantage a competitor would pay for, may justify SL3 with an insider programme. Concretely: keep weights in a registry that requires signed artefacts and verifies signatures at load, so that a swapped or exfiltrated model is detectable; restrict who can download weights and log it; encrypt them with keys held in a hardware security module; keep training data provenance so that you can show the weights are yours; and include weight theft in the incident response plan with the reporting duties it triggers under SB 53, the RAISE Act, the EU AI Act's serious incident rules for systemic-risk models, and, where personal data is embodied, data protection law.
Signals that a programme is real
- A documented threat model naming the attacker classes and the attack vectors that matter for your weights.
- Phishing-resistant MFA and hardware keys for everyone with weight access, and two-person rules for bulk access.
- Environment separation enforced by network policy, not convention, with egress monitoring on training and serving clusters.
- Signed artefacts, verified at load, with an inventory that says where every copy of the weights lives.
- An insider threat programme proportionate to the level, including for contractors and evaluators.
- Extraction monitoring on APIs and fine-tuning services.
- Tabletop exercises for weight theft that rehearse detection, containment and the reporting clocks.
The 2024 report's most quoted line is that SL5 is not currently achievable. The more useful one is that SL3 is, for anyone willing to do the work of ordinary security with unusual seriousness.
