Should organisations separate ML workload identity from the user who created the compute instance?

Yes. If a compute instance can inherit creator permissions, the workflow can become a proxy for human access rather than a constrained service identity. Separation is the safer model because it keeps pipeline execution from expanding into the creator’s broader privilege set.

Why Separating ML Compute Identity From the Creator Matters

When an ML job runs on a compute instance, the instance should authenticate as its own workload, not as the person who launched it. That boundary keeps the runtime from inheriting broad user access, reduces the blast radius of a compromised notebook or training job, and makes access decisions easier to reason about when the job calls data stores, registries, or deployment APIs.

Separation also aligns with the way modern workload identity is designed. A compute instance usually needs a narrow set of permissions for specific services, while the creator may hold far broader entitlements for administration, experimentation, or support. If those are collapsed into one execution context, a temporary job can behave like a proxy for human access instead of a bounded service identity.

This is why workload identity patterns such as SPIFFE workload identity and non-human identity guidance for workload identities are relevant: they separate the runtime subject from the person who created or approved it.

Where Creator-Bound Identity Breaks Down

The main failure mode is privilege inheritance. If the instance can act with the creator’s permissions, then the job can often reach resources that were never meant for automated execution, including secrets, datasets, model registries, and production endpoints. That is especially dangerous in shared platforms where one notebook, training container, or orchestration step can reach many downstream systems.

Another common issue is identity ambiguity. When the creator is the effective runtime identity, audit logs become harder to interpret because the access path reflects a human account, not a bounded service. That weakens incident response, makes approval and revocation less precise, and increases the chance that access persists after the job should have stopped.

Separation is particularly important in ML infrastructure because many platforms mix interactive experimentation with automated execution. A user may legitimately need broad permissions to build or debug, but the workload only needs a small slice of that access to run. AI infrastructure workload identity patterns exist to keep those runtime permissions narrow and distinct from the operator’s own access.

Cloud implementations follow the same principle. For example, cloud workload identity and workload authentication approaches are intended to replace static or inherited human credentials with a runtime identity that can be constrained, rotated, and observed independently.

What Good Separation Looks Like in Practice

A well-designed platform gives the compute instance its own identity, scopes it to the exact services it needs, and prevents the creator’s permissions from being automatically inherited at runtime. The creator may still approve the job, own the workflow, or manage the environment, but those duties should not become the credentials used by the running process.

The practical test is simple: if the workload were compromised, could it only access what the job genuinely requires? If the answer is no, the identity boundary is too loose. If the answer is yes, the workload is easier to contain, easier to revoke, and easier to review. In Kubernetes and cloud environments, that usually means using workload-specific service identities, federation, and short-lived credentials rather than human tokens or ambient user context.

The best implementations also keep ownership and execution separate. A person can own the pipeline, but the pipeline should authenticate as itself. That distinction matters most when the workload has access to sensitive training data, signing keys, model artifacts, or deployment paths, because those are precisely the places where inherited human access becomes a control failure.

Related controls such as Kubernetes workload identity and CI/CD pipeline identity security reinforce the same design choice: the runtime should be bounded to its task, not to the human who initiated it.

Risk and Threat Considerations

When a workload inherits creator permissions, a compromise of the compute instance can become a compromise of the user’s wider access set. That increases exposure to data theft, unauthorized model changes, secret reuse, and lateral movement across connected systems. The risk is highest when the creator is privileged, when the instance is long lived, or when the platform allows token reuse across environments.

Failure mechanism: The platform treats the user as the runtime subject, so the workload can request resources and perform actions that exceed its operational purpose. An attacker who gains execution on the instance can then exploit the inherited access instead of needing a separate privilege escalation step.

Impact: Containment breaks down, audit trails blur, and revocation becomes less effective because the trust boundary is anchored to the human account rather than the workload. In ML environments, that can expose data, artifacts, and downstream deployment controls.

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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Service Identification and Authentication	ML workloads should authenticate as services, not as the creator's user account.
Recommendation — Use IA-9 to issue workload-specific credentials and prevent human identity inheritance.
NIST Zero Trust (SP 800-207)	PR.AA-03 — Subject Authentication and Credential Verification	Separate the workload subject from the creator to verify runtime access independently.
Recommendation — Authenticate the compute instance as its own subject before granting any resource access.
OWASP Non-Human Identity Top 10	NHI-04 — Insecure Authentication	Inherited creator access turns workload authentication into a human proxy path.
	NHI-05 — Overprivileged NHI	Creator inheritance commonly expands ML workloads beyond their required permissions.
	NHI-07 — Long-Lived Secrets	Workloads should not rely on durable creator credentials to keep running.
Recommendation — Replace creator-bound access with a dedicated workload authentication mechanism. Scope ML workload permissions to the minimum set required for execution. Use short-lived workload credentials instead of persistent creator secrets.

Practitioner Guidance

What to verify: Confirm that the compute instance has its own workload identity, its own authentication path, and a permission set that is narrower than the creator’s user account. If the platform cannot express that separation, treat it as a design gap, not a minor configuration issue.

Decision rule: If the workload needs access beyond the creator’s intended operating context, grant it explicitly to the workload and document the scope. Do not let “created by user X” become an implicit authorization model for runtime access.

What practitioners underestimate: The problem is not just excessive privilege, it is also attribution. Separate identities make it possible to answer who approved the job, what the job was allowed to do, and what the workload actually did when it ran.

Practitioner takeaway: The safest default is to let people create and govern ML jobs, but let the jobs themselves authenticate and operate as bounded workloads with their own least-privilege identities.