Because the role is the execution identity for the training job, so broad storage or delegation permissions let a single compromised workload reach far beyond its intended task. If that role can read multiple buckets or pass itself into other contexts, an attacker can pivot from one GenAI job into wider cloud resources without touching the model directly.
Why Overprivileged ML Service Roles Create Account-Wide Cloud Exposure
An ML service role is not just a label on a workload, it is the cloud principal that the job uses to act. When that principal has broad storage, compute, or delegation rights, compromise of the job can become compromise of the permissions attached to the role. The exposure grows with every bucket, project, subscription, or trust relationship the role can reach.
How the Role Becomes the Blast Radius
The core issue is that many ML pipelines run with standing access that is far wider than the job itself needs. If the training or inference container can assume the role, then any exploit inside that container inherits the role’s permissions. That is why Cloud Workload Identity Guide matters here: temporary credentials and federation reduce the damage from long-lived keys, but they do not help if the assumed role is already overbroad.
In practice, account-wide exposure appears when the role can read shared data stores, write to production locations, invoke orchestration services, or pass itself into another context. A single compromised notebook, training pod, or batch job can then move from “one workload” to “many resources” without needing to break the model, the app, or the cloud provider’s core controls.
That pattern is easier to miss in ML than in ordinary application hosting because data scientists often optimize for speed, not minimal privilege. The result is an execution identity that can reach far beyond the dataset or artifact path it was meant to touch. NHIMG’s Service Account Security Guide is a useful companion for the same design problem across cloud and SaaS: service identities should be discoverable, scoped, and governed as production access paths.
What Makes ML Roles Especially Dangerous at Cloud Scale
ML service roles often sit at the junction of data, orchestration, and deployment. That means they may touch raw training data, feature stores, artifact buckets, model registries, and CI/CD systems from one trust boundary. If the role also has permission to delegate or impersonate, the compromise becomes more than read access, it can become lateral movement into other accounts or environments.
Three properties make the exposure account-wide rather than job-wide. First, the role is reused across runs, so one weakness affects many executions. Second, the role often has access to shared infrastructure rather than a single dataset. Third, the role’s permissions are frequently inherited by downstream automation, which turns a single compromised workload into a stepping stone for broader cloud action.
Kubernetes NHI Security Guide and Ultimate Guide to NHIs — What are Non-Human Identities both reinforce this broader point: workload identities, service accounts, and other machine principals should be treated as real access-bearing identities, not as implementation detail. Once they are overprivileged, they become a cloud control plane risk, not just an ML ops concern.
Where Exposure Usually Spreads First
The first places to look are storage and delegation edges. Broad read permissions let an attacker exfiltrate datasets, prompts, embeddings, secrets, or artifacts. Broad write permissions let them poison training inputs, overwrite checkpoints, or plant malicious outputs that later get promoted into production. Delegation rights are worse, because they let the attacker reuse the role to reach new resources instead of staying inside the original workload.
Account-wide exposure often shows up when one role can bridge environments that should be separated, such as dev to prod, or training to serving. It also appears when the role can access metadata services, token endpoints, or role-chaining mechanisms that were intended to support automation but now function as privilege amplification.
Hugging Face Spaces breach 2024 and Dropbox Sign breach 2024 are both useful examples of how backend service identities can expand a compromise well beyond the original system when the credential or role boundary is too broad.
Risk and Threat Considerations
Overprivileged ML roles create a large blast radius because attackers do not need to defeat the model itself. They only need code execution inside the workload, or a stolen token that the workload can use, and the cloud permissions do the rest. The risk is highest where roles can read many buckets, assume other roles, or reach management APIs that were never required for the job.
Failure mechanism: A compromised ML job inherits a powerful execution identity, then uses storage reads, role assumption, or delegation permissions to move from one workload into broader cloud resources.
Impact: The attacker can exfiltrate data, alter artifacts, poison pipelines, or pivot into other accounts and environments, turning a single workload compromise into account-wide exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Directly addresses excessive privilege on machine and service identities used by ML jobs. |
| NHI-09 — NHI Reuse | ML roles are often reused across jobs, expanding blast radius across environments. | |
| Recommendation — Scope each ML service role to the minimum resources and actions required. Eliminate shared roles across pipelines and separate identities by workload and environment. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Overbroad cloud roles are a direct least-privilege failure affecting access scope. |
| IA-5 — Authenticator Management | Role exposure often depends on the lifecycle and handling of role credentials or tokens. | |
| AC-3 — Access Enforcement | Cloud exposure depends on enforcing what the ML role can actually reach and pass to others. | |
| Recommendation — Restrict role permissions to the minimum set needed for the workload. Rotate and control workload credentials so compromise does not persist across runs. Enforce policy boundaries that block unauthorized resource access and role passing. | ||
Practitioner Guidance
What to verify: Check whether the role can do anything that the job does not strictly need, especially cross-bucket reads, cross-project writes, role passing, and management-plane actions. If the answer is yes, treat the role as overexposed even if no incident has occurred.
Decision rule: If a workload can authenticate as a production role, scope that role as if it were already hostile. Prefer separate roles per pipeline stage, narrow resource ARNs or scopes, and explicit deny boundaries for delegation paths that are not essential.
What practitioners underestimate: The biggest mistake is assuming that “temporary” access is inherently safe. Temporary credentials still carry the full blast radius of the role, so short-lived access does not compensate for broad authority.
Practitioner takeaway: For ML workloads, the key control question is not whether the role is ephemeral, but whether its permissions are small enough that compromise stays local instead of becoming an account-level event.
Related resources from NHI Mgmt Group
- Why do service account and token compromises create such broad exposure in cloud and SaaS environments?
- When does a service account become a compliance problem?
- Why do overprivileged service accounts create such persistent cloud risk?
- Why do service account and API key exposures create outsized cloud risk?