Securing the training and fine-tuning pipeline
The pipeline that builds your model is a high-value target. Learn to lock down data, compute, secrets, checkpoints and releases.
In 60 seconds
Securing the training and fine-tuning pipeline
The pipeline that builds your model is a high-value target. Learn to lock down data, compute, secrets, checkpoints and releases.
The parts to protect
| Part | Main risk | Key controls |
|---|---|---|
| Datasets | Poisoning, leakage of personal data | Least-privilege access, versioning, hashes, change review |
| Training code and configs | Hidden changes to behaviour | Code review, protected branches, pinned dependencies |
| Compute environment | Compromise of GPUs or notebooks | Isolated projects or accounts, no direct internet where possible, patched images |
| Secrets | Stolen cloud keys, tokens and hub credentials | Secret manager, short-lived credentials, no secrets in notebooks or code |
| Checkpoints and final weights | Theft or tampering | Encryption at rest, strict access, hashes and signatures |
| Release process | Unsafe or tampered models reaching users | Evaluation gates and recorded approval |
Access control
- Give each person and each pipeline job only the access it needs. Separate read access to raw data from write access to curated data.
- Use workload identities for jobs instead of long-lived keys. Keep human admin access rare and logged.
- Treat shared notebooks carefully. They often hold credentials and data samples, and are easy to share by mistake.
- Log who read or changed datasets and weights, and review unusual access.
Isolated training environments
Reproducibility is a security control
Evaluation gates before release
- 1
Quality
Accuracy on the trusted holdout set meets the bar. - 2
Safety and security
Tests for harmful output, prompt injection behaviour, known triggers and evasion cases. - 3
Privacy
Probes for memorised personal data and secrets from the training set. - 4
Fairness
Results checked across relevant groups. - 5
Provenance
AI-BOM complete, hashes and signature valid. - 6
Approval
A named owner approves, and the decision is recorded.
Protecting weights at rest and in transit
- Encrypt storage that holds checkpoints and weights, with keys managed in a key management service and access logged.
- Use TLS for every transfer, including internal copies between regions and clusters.
- Delete old checkpoints you do not need; each copy is something to protect.
- Watch for large downloads of weight files, especially outside normal release jobs.
- For the most valuable models, limit which systems can ever hold the full weights.
Watch and read more
Lab
A one-page security design for a fine-tuning pipeline, with a release gate checklist.
The problem
Draw (on paper or in a document) a fine-tuning pipeline for a realistic use case, such as fine-tuning a model on support tickets for an IT services company.
- Show each stage: data sources, curation, training, checkpoint storage, evaluation, registry, deployment.
- For each stage, write who or what has access, and the key control from the lesson.
- Write the release gate as a checklist with pass or fail conditions.
- Name the three changes that would reduce risk the most in your real environment.
You are done when
Hard questions
Try to answer before you reveal. If you can answer these, you understood the lesson.
Q1An engineer says, "Our training cluster has no internet, so we don't need to scan dependencies." What is wrong with this?Reveal
Dependencies still arrive somehow: a mirror, a container image, a copied wheel file. A malicious or vulnerable package brought in that way runs inside the cluster with access to data and weights. No internet reduces exfiltration and download risk, but you still need pinned, scanned, trusted dependencies.
Q2Why keep human approval as a separate step even when all automated gates pass?Reveal
Automated tests only check what someone thought to test. A human owner can judge context: is this model suited to the planned use, are there new risks, did any test barely pass? Recording who approved also creates accountability, which auditors and regulators expect.
Questions people ask
Our data scientists need freedom to experiment. Won't this slow them down?
Separate the playground from the production pipeline. Let people experiment on approved, de-identified data in a sandbox. Only the controlled pipeline can produce models that ship. This keeps speed where it helps and control where it matters.
Should we sign every checkpoint?
Hash every checkpoint you keep. Sign release candidates and final models. Signing everything is fine if it is automatic, but focus on what could be deployed.
What about fine-tuning through a cloud provider's service?
The same ideas apply, with shared responsibility. Check who can upload training data, where it is stored, how long it is kept, who can access the resulting model, and whether the provider may use your data. Record the answers in your AI-BOM and vendor review.
Is GPU hardware itself a risk?
Shared accelerators, drivers and orchestration tools have had security issues, as all software does. Keep drivers and platforms patched, isolate sensitive training jobs, and follow your cloud provider's guidance for multi-tenant workloads.
Lesson test
5 questions. Get 3 right (60%) to pass and complete this lesson.