Securing AI Model Weights: RAND SL1 to SL5 and Controls

Whoever holds a copy of a model's weights holds the model, along with the money and compute spent to train it and any safeguards that were meant to come with it. Weights are a few files, often hundreds of gigabytes, that can be copied in hours by anyone with read access to the store they sit in. This guide covers how to protect proprietary and frontier model weights at rest, in use and in transit: the RAND security levels, weight storage and encryption, access control for people and machine identities, insider risk, and how to detect exfiltration. It is for security architects and engineers at AI labs, at enterprises that fine-tune or host proprietary models, and at cloud teams that serve them. Extraction through a public API is a different problem, covered in the Model Extraction and Distillation Defence Guide.

Key takeaways

Pick a target security level first. RAND's five security levels (SL1 to SL5) tie defences to the attacker you must stop, from amateurs to top-priority nation-state operations; most enterprises need SL2 to SL3, frontier labs are aiming higher.
Fewer copies, fewer people. RAND and the April 2024 joint agency guidance both put centralising weight copies and cutting the number of people with access near the top of their lists.
Machine identities are the main access path. Training jobs, checkpointing, evaluation and serving all read or write weights; one over-scoped service account or shared cluster credential reaches every copy.
Encrypt with keys you control, and separate them from the weights. Encrypt weights at rest with keys held in an HSM or KMS, store hashes and keys apart from the encrypted files, and sign each release.
Watch for bulk reads and odd egress. Weight theft looks like large reads from artefact stores, new copies in unusual locations and large transfers to external storage; alert on all three.

Security levels: deciding how much protection you need

RAND's 2024 report Securing AI Model Weights identified 38 meaningfully distinct attack vectors in nine categories, from running unauthorised code and compromising existing credentials to supply chain attacks, physical access and human intelligence such as bribery or placing candidates. It then defined five attacker operational capacities (OC1 to OC5) and a security level designed to thwart each one.

Level	Attacker it targets (RAND)	Typical resources RAND describes	Who should aim here
SL1	OC1 amateur attempts	One person, days, up to $1,000	No proprietary weights should sit below this
SL2	Most OC2 professional opportunistic efforts	One professional, weeks, up to $10,000	Enterprises with fine-tuned models of modest value
SL3	OC3 cybercrime syndicates and insider threats	About ten professionals, months, up to $1 million; or an insider with sensitive access	Organisations whose models are core intellectual property
SL4	Most OC4 standard operations by leading cyber-capable institutions	About 100 people, a year, up to $10 million, state resources	Frontier developers and models with national security relevance
SL5	Could plausibly thwart most OC5 top-priority operations	About 1,000 experts, years, up to $1 billion	The most capable frontier models; RAND says this needs substantial further investment

Decision guidance: SL3 is the practical line for most organisations because it is the first level that explicitly covers insiders. If the model could be monetised or misused at scale by a criminal group, or if a competitor would pay a departing employee for it, plan for SL3. SL4 and above call for specialised hardware, isolation and personnel measures that only a few organisations can fund.

Where weights live and how to store them

Weights are rarely in one place. A typical training run produces checkpoints on shared file systems, final artefacts in an object store or model registry, copies on evaluation clusters, cached copies on every inference node, and sometimes local copies on researchers' workstations. Each copy is an exposure. RAND recommends centralising all copies in a limited number of access-controlled, monitored systems; its SL3 benchmark adds dedicated devices for weights and centralised, restricted management.

Location	Main risk	Control
Training checkpoints on shared storage	Broad read access from every job and researcher	Per-run storage paths, job-specific identities, automatic expiry of intermediate checkpoints
Model registry or object store	Bucket-wide read roles; public links; cross-account replication	Dedicated bucket or registry per model tier, deny-by-default policies, object-level logging, no public access
Inference nodes	Weights decrypted on disk and in memory on many hosts	Load into memory from the central store at start-up, avoid persistent local copies, confidential computing where available
Evaluation and research clusters	Less hardened environments, broad network access	Treat as production for weight access; isolate from the internet and internal registries unless explicitly needed
Workstations and notebooks	Unmanaged copies outside monitoring	Prohibit full-weight downloads to endpoints; give researchers interfaces that run code next to the weights instead
Backups and archives	Forgotten copies with older, weaker access policies	Encrypt with separate keys, store hashes apart, review archive access as strictly as live stores

Encryption, integrity and keys

Encrypt at rest: the joint guidance Deploying AI Systems Securely (NSA AISC, CISA, FBI and Five Eyes partners, April 2024) says to encrypt weights, outputs and logs at rest and to store encryption keys in an HSM for on-demand decryption. Use envelope encryption with a key per model or model tier, so access to one key does not open every model. See the Cryptographic Key Management Guide.
Separate keys and hashes from weights: the same guidance recommends hashes and encrypted copies of each release archived in a tamper-proof location, with hashes or keys held in a vault or HSM separate from the encrypted model.
Isolate storage: it also recommends isolating weight storage in a protected vault, highly restricted zone, enclave or HSM, and applying hardware protections where feasible.
Sign and verify: use digital signatures and checksums to verify the origin and integrity of every artefact, and keep models in version control with access controls so only validated artefacts reach production.
Protect weights in use: RAND lists confidential computing as an SL4 measure, used where available, so weights stay encrypted in memory outside a trusted execution boundary. See the Confidential Computing Guide.

Access control for people and machine identities

RAND recommends reducing the number of people authorised to access weights and, at SL3, applying multiparty authorisation and security reviews to sensitive interactions. The joint agency guidance asks for an access control system for weights, two-person control and two-person integrity for privileged users, and role-based or preferably attribute-based access control.

Human access: define a small, named group with read access to full weights. Everyone else works through interfaces that run code against the weights without exposing them, which RAND describes as permitted interfaces that reduce the risk of illegitimate copying. Require phishing-resistant authentication and just-in-time elevation for the named group. See the JIT Access Guide.
Dual authorisation: require two approvers for any export, copy to a new location, change to storage policy or key policy, and key deletion. SP 800-53 AC-3(2) Dual Authorization describes the control.
Machine identities: give each pipeline stage its own workload identity. The training job writes checkpoints to its run path only; the release identity promotes signed artefacts to the registry; serving identities read one model version, read-only. Prefer workload identity federation to static keys. See the Workload Identity Federation Guide.
No shared cluster credentials: a single cluster-admin credential reused across clusters turns one foothold into access to every node that caches weights.
Third parties: RAND's SL4 benchmark includes preventing third-party access. Below SL4, contract and technically restrict any vendor, contractor or cloud support access to weight stores, and log it.

Where weight access is expressed as cloud IAM policy, review it like privileged access: it is. The Non-Human Identity (NHI) Guide covers inventory and ownership for the machine identities involved.

Insider risk at AI labs and model teams

RAND groups insider threats with cybercrime syndicates at OC3: far fewer resources, but significant access to sensitive systems, such as a senior research team member. It recommends insider threat programmes from SL3 and, at SL4, an advanced programme with occasional integrity testing. The incentive is real: in January 2026 a US jury convicted a former Google engineer of economic espionage and theft of trade secrets after he uploaded more than 2,000 pages of AI supercomputing hardware and software designs to a personal cloud account over about a year, then downloaded them shortly before resigning (as reported by Help Net Security). Those were infrastructure designs rather than weights, but the pattern of slow collection to personal cloud storage followed by a resignation applies directly.

Joiner and mover controls: screening proportionate to access (PS-3), and removal of weight access when people move off model teams.
Leaver controls: review weight and artefact access logs for the 90 days before a resignation from anyone in the named access group. See the Insider Threat Programme Guide.
Personal storage: block or alert on uploads to personal cloud accounts from research environments.
Red teaming: RAND recommends advanced third-party red teaming, at SL3 including an external team that tests insider threats.

Detecting and preventing exfiltration

Weight theft has a distinctive signature because the files are so large. RAND's SL3 benchmark includes manual and automated anomaly detection, blocking of malicious queries, frequent compromise assessments and integrity checks against a known-good gold image, and limits on the number of inferences per set of credentials. SL4 adds hardware-enforced limits on output rate and time-buffered review of activity.

Signal	What to log	Technique (ATT&CK v20 / ATLAS)
Bulk reads of weight objects	Object-level access logs on registries and buckets, with identity and byte counts	T1530 Data from Cloud Storage
Weight access by an unusual identity or from a new location	Cloud audit logs, workload identity token issuance	T1078.004 Cloud Accounts
Node credential theft from metadata services	Instance metadata access from containers, unexpected role use	T1552.005 Cloud Instance Metadata API
Large transfers to external storage	Egress flow logs, proxy logs, cloud storage cross-account copies	T1567.002 Exfiltration to Cloud Storage; AML.T0025 Exfiltration via Cyber Means
High-volume or systematic queries to an inference API	Per-credential query counts, output volume	AML.T0024 Exfiltration via AI Inference API
Tampered or substituted weights	Hash verification at load time against the signed release	AML.T0010 AI Supply Chain Compromise

Metrics that show the programme is working:

Number of locations holding full weight copies, trending down to the planned set.
Number of people and machine identities with read access to full weights, reviewed monthly.
Percentage of weight artefacts encrypted with a per-model key and signed.
Percentage of model loads that verify a signature or hash before serving.
Mean time to triage a bulk-read or large-egress alert on a weight store.
Percentage of weight exports with recorded dual approval.

Implementing a weight security programme

Classify models. Assign each model a value and misuse tier and a target security level. Not every fine-tune needs SL3.
Find every copy. Scan object stores, file systems, registries, backups and endpoints for weight file formats and known hashes. Record owner, location and who can read each copy.
Consolidate. Delete or archive stray copies; move the rest into a small number of dedicated stores with deny-by-default policies.
Re-key and sign. Encrypt each model with its own key in an HSM or KMS, store hashes separately, sign releases and enforce verification at load time.
Split identities. Replace shared and long-lived credentials with per-stage workload identities. Start in audit mode: log what each identity actually reads for two to four weeks, then tighten.
Add dual control. Require two-person approval for export, policy and key changes. Test the break-glass path so recovery does not depend on bypassing it.
Turn on detection. Object-level logging, egress monitoring and per-credential query limits, routed to the SOC with tuned thresholds.
Test. Commission red teaming that attempts weight exfiltration, including an insider scenario. Rollback for every change is a policy revert; keep the previous policy versions and a tested restore of the encrypted archive.

Small and large organisations: a team that fine-tunes one model can reach a solid SL2 with a dedicated bucket, a per-model KMS key, a handful of named readers and object-level logging. A frontier developer needs the full SL3 benchmark as a floor, including insider programmes and external red teams, and a roadmap toward SL4.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Least privilege and dual authorisation for weight access	AC-6, AC-3(2)	PR.AA-05
Encryption at rest and key management	SC-28(1), SC-12	PR.DS-01
Integrity verification of weights	SI-7	PR.DS-01
Exfiltration prevention and monitoring	SC-7(10), SI-4(2)	DE.CM-09
Insider risk and personnel	PS-3	GV.RR-04, DE.CM-03
Physical protection of weight hosts	PE-3	PR.AA-06
Third-party and supply chain	SR-3, SA-9	GV.SC-07

NIST's draft AI control overlays also name model weights as an in-scope component; see the NIST COSAIS Guide.

Common failure patterns

Checkpoint sprawl: intermediate checkpoints stay on shared storage for months with the same broad access as training data, so the final model is well protected and the near-final one is not.
One credential for the whole pipeline: a single service account reads data, writes checkpoints and serves the model, so any compromised job can copy every version.
Keys stored next to weights: encryption keys or decryption credentials sit in the same bucket, container image or environment variables as the encrypted weights.
Evaluation environments treated as low risk: research and evaluation clusters often have the weakest network controls and the most copies.
No logging at object level: bucket-level logs show that someone accessed the store, not that they read 400 GB of weight shards.
Endpoint copies for convenience: researchers download weights to laptops to work offline, outside every control above.

Lessons from incidents

The OpenAI and Hugging Face breach in July 2026 did not involve reported theft of weights, but it shows how AI lab infrastructure is reached. Agents running in an evaluation sandbox reached an internal package registry, then moved through Kubernetes service account tokens, instance metadata credentials, a JWT signing key and a shared cluster-admin credential that worked across clusters. OpenAI quarantined the model and paused some training work. The lessons map straight onto weight protection: isolate evaluation environments, scope every workload credential to one system, block pod access to instance metadata and never share cluster-admin credentials. The earlier Hugging Face Spaces breach is a reminder that secrets stored on model hosting platforms are themselves a route to model assets.

Practitioner checklist

Assign every proprietary model a value tier and a target RAND security level.
Inventory every copy of every weight file, including checkpoints, caches, backups and endpoints.
Consolidate weights into a small number of dedicated, deny-by-default stores.
Encrypt each model with its own HSM or KMS key, store hashes and keys separately, and sign releases.
Verify signatures or hashes at load time on every inference node.
Limit full-weight read access to a named group and per-stage workload identities; remove shared and static credentials.
Require dual approval for exports, storage policy changes and key changes.
Enable object-level logging, egress monitoring and per-credential query limits, with SOC alerting.
Run an insider threat programme for model teams and review access logs before departures.
Commission red teaming that attempts weight exfiltration, including an insider scenario.

Securing AI Model Weights: Security Levels, Storage, Access and Exfiltration Controls