Securing the Training Pipeline

A training job reads the organisation's most sensitive data at volume, runs code from a large dependency tree, executes on expensive infrastructure, and produces an artefact that will be deployed and trusted. It is a high-value target with broad access, and it is routinely operated with weaker controls than a production service handling a fraction of the same data.

What a compromise yields

The data. Training reads the full dataset, so a compromised job is a bulk exfiltration path for whatever the model trains on, which is frequently the most sensitive corpus the organisation holds.

The model. An attacker who can modify the training code or the data can install a backdoor that survives into deployment, where standard evaluation will not detect it.

The compute. Large GPU allocations are attractive for cryptomining and for the attacker's own training, and the cost is absorbed as normal usage unless someone is watching utilisation attribution.

Lateral movement. Training environments accumulate credentials for data stores, artefact registries and deployment systems, often broader than any single job needs.

The recurring failures

Long-lived broad credentials. A single service account with read access to the entire data lake, used by every job, present in the environment for the job's lifetime. Short-lived, job-scoped, workload-identity-derived credentials are the fix and require the scheduler to support them.

Interactive access to training nodes. Debugging on a node with production data mounted is convenient and creates an audit gap and a credential exposure. Separating a development environment with synthetic or sampled data from the production training environment is the standard arrangement and is often skipped for velocity.

Unrestricted egress. A training node that can reach arbitrary internet destinations can exfiltrate the dataset. Egress allowlisting to the registries and storage endpoints actually needed is a high-value control that is rarely applied to training infrastructure, though it is routine for production services.

Code paths without review. A notebook run interactively against production data, or a branch deployed to the cluster without review, bypasses whatever controls exist for the main pipeline. Attack paths follow the least controlled route.

Proportionate controls

Treat the training environment as production. Job-scoped short-lived credentials. Egress allowlisting. Reviewed and signed code artefacts rather than ad hoc branches. Data access logged and attributable to a job rather than to a shared account. Separation between the environment that can read training data and the one that can publish models, so a single compromise does not both extract data and ship a backdoored artefact.

When it breaks

Controls that block research get bypassed. A pipeline too rigid to iterate in produces a shadow pipeline on someone's workstation, which has no controls at all. The workable arrangement gives researchers a fast path on sampled or synthetic data and reserves the strict path for jobs touching the real corpus.

Attribution is the precondition for everything. Without knowing which job read which data under whose authority, neither the compute-abuse question nor the incident-scope question is answerable. Per-job identity is the control that makes the other controls auditable.

Shared caches cross trust boundaries. A dataset cache, a compiled kernel cache, or a shared checkpoint directory writable by many jobs is a path from one team's compromise to another's model. Caches are infrastructure and inherit the trust level of the least trusted writer.

Insider risk is the uncomfortable case. Most of these controls assume an external attacker who obtained access. A researcher with legitimate access can exfiltrate data or install a backdoor and the technical controls will not stop them, which is why logging, review of training code, and separation of duties for model publication do real work that access control does not.