Azure Machine Learning privilege escalation exposes identity risk

At a glance

What this is: Orca Security’s analysis shows how Azure Machine Learning pipeline scripts stored in linked storage can be altered to run code with elevated identity context.

Why it matters: For IAM, NHI, and cloud security teams, the issue matters because a storage write path can become a privilege-escalation path when compute identities inherit broad permissions.

By the numbers:

• 33% of Azure customers are using the AML, g the AML service.

👉 Read Orca Security’s analysis of Azure Machine Learning privilege escalation

Context

Azure Machine Learning pipelines are meant to standardise model training and automation, but they also create an identity boundary between storage, compute, and the identities that execute jobs. In this case, that boundary can fail when invoker scripts stored in a linked Storage Account are writable by an attacker or overly broad internal role.

The security problem is not machine learning itself, but the way AML execution depends on storage-backed scripts and managed identities. Once code in storage is treated as executable input, the question becomes whether the compute instance, the storage account, and the associated Key Vault share a safe trust model or an escalatable one.

Key questions

Q: What breaks when AML pipeline scripts can be modified in linked storage?

A: The execution boundary breaks. If storage-backed invoker scripts are writable, an attacker can change the code that AML later runs on compute, turning a storage permission into code execution authority. The control failure is not just weak access control on blobs. It is allowing runtime artefacts to remain mutable after they have become part of the job’s trusted execution path.

Q: Why do managed identities make AML privilege escalation more dangerous?

A: Managed identities can expand the blast radius of a successful code injection because the malicious code runs with whatever rights the AML identity already has. If that identity can read Key Vault, modify resources, or reach other Azure services, the attacker inherits those paths. The risk is highest when identity scope is broader than the pipeline’s task scope.

Q: How do security teams know whether AML identity scope is too broad?

A: Look for mismatches between the job’s purpose and the rights attached to the compute instance or workspace identity. If the identity can access Key Vaults, alter role assignments, or operate beyond the resource group needed for the pipeline, the scope is too broad. The right signal is whether the identity could be abused to move beyond the AML workflow itself.

Q: Who is accountable when AML jobs inherit a user’s permissions through SSO?

A: Accountability sits with the identity and platform owners who allowed human privilege to flow into machine execution. If SSO makes a compute instance act under the creator’s permissions, then the governance problem is not isolated to the developer who submitted the job. It is a programme-level failure to separate human authentication from workload authorisation.

Technical breakdown

Storage-backed invoker scripts create an execution boundary

Azure Machine Learning pipeline components use invoker scripts and YAML configuration stored in a linked Storage Account to define what runs on a compute instance. That design makes storage part of the execution path, not just a passive repository. If an attacker can write to those blobs, they can alter the code that AML later fetches and executes. The practical risk is that a storage permission becomes code execution access in the context of the pipeline.

Practical implication: treat write access to AML-linked storage as execution-capable access, not as ordinary file access.

Managed identity inheritance turns code execution into privilege escalation

When malicious code runs inside the AML compute environment, it inherits the permissions of the assigned managed identity. If that identity is user-assigned with broad rights, or system-assigned with elevated scope, the attacker can query Key Vault, manipulate role assignments, or move into other Azure resources. The issue is not just that code runs, but that it runs under an identity whose effective rights may already be far beyond the pipeline’s narrow task.

Practical implication: review the permissions attached to every AML compute identity before assuming the pipeline is low risk.

SSO and default identity behaviour widen the blast radius

The article shows that single sign-on on compute instances can cause code execution to reflect the user principal that created the instance rather than a tightly scoped service identity. That matters because the same script path can behave very differently depending on whether the compute instance is using a constrained managed identity or inheriting the creator’s privileges. In practice, the control problem is identity scope drift across execution modes.

Practical implication: eliminate inherited user privilege paths where AML jobs can execute under broader-than-intended identity context.

NHI Mgmt Group analysis

AML storage write access is effectively execution authority when scripts are fetched at runtime. The article shows that the trust boundary was not between code and storage, but between authorised and unauthorised modification of executable pipeline artefacts. Once storage can alter what the job runs, the control failure is identity-to-code coupling, not merely weak file permissions. Practitioners should treat writable pipeline storage as part of the runtime trust chain.

Managed identity scope, not pipeline logic, becomes the real control plane. The exploit works because the compute environment inherits the permissions already attached to the AML identity. If that identity is Contributor or Owner, the pipeline becomes a vehicle for broader Azure access rather than a bounded ML task. For governance teams, the implication is that identity scoping must be reviewed as part of ML platform security, not after the fact.

Single sign-on created a privilege inheritance path that was wider than most teams would assume. The article’s most damaging path was not the one that used a tightly controlled service identity, but the one where the compute instance reflected the creator’s permissions. That is a classic identity governance failure mode: human privilege leaking into machine execution. The practical conclusion is that user-assigned authority and human-session authority must not be allowed to collapse into the same runtime path.

Code snapshotting changes the attack surface, but it does not remove the governance problem. Microsoft’s move to execute scheduled jobs from snapshots reduces one injection route, yet it also confirms the original weakness was tied to mutable runtime inputs. That is a control boundary lesson for machine identity programmes: if execution depends on storage state, then integrity of that state must be governed like access, not like content. Practitioners should model AML as a runtime identity system, not just a development platform.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means many teams cannot reliably trace which non-human identities can reach sensitive workloads.
• For a broader baseline on inventory and governance, see 52 NHI Breaches Analysis, which shows how identity failures repeat across real incidents.

What this signals

Identity scope is now the control variable for machine learning platforms. As AML, notebooks, pipelines, and storage become more tightly coupled, the practical question is no longer whether a job can run, but whether the identity behind that job can be trusted to stay inside its intended boundary. Teams should map every execution path where storage, compute, and secrets intersect, then verify that no human credential path can silently re-enter the workflow.

The broader signal is that ML platforms increasingly behave like identity platforms with embedded execution engines. If a pipeline can reach secrets, storage, and role assignments, then IAM, PAM, and NHI governance all apply at once, which is why workload identity review needs to sit alongside platform engineering and cloud security decisions.

For practitioners

• Restrict write access to AML-linked storage Limit write permissions on the storage account that holds pipeline components, invoker scripts, and YAML execution files. Treat any principal that can modify those blobs as able to influence code execution in the AML runtime.
• Remove inherited human privilege from compute instances Disable SSO where it causes the compute instance to run under the permissions of the user who created it, and replace that path with a controlled system-assigned identity that has only the permissions required for the job.
• Enforce immutability for executable AML artefacts Apply immutability policies and versioning to critical script blobs so unauthorised edits can be blocked or rolled back. Where possible, validate invoker scripts with checksum verification before execution.
• Review Key Vault and subscription-scoped rights on AML identities Inventory every managed identity attached to AML workspaces and compute instances, then verify whether those identities can access Key Vaults, modify role assignments, or reach resources outside the intended workspace boundary.

Key takeaways

• A writable AML artefact can become a code execution path when the platform trusts storage-backed invoker scripts.
• Managed identity inheritance turns a pipeline issue into a cloud privilege problem, especially when SSO or broad roles are involved.
• The most effective controls are storage immutability, least-privilege identities, and removal of human privilege inheritance from compute instances.

Key terms

• Managed Identity: A managed identity is a cloud-native identity assigned to an application or service so it can authenticate without embedded secrets. In practice, its permissions define the attack surface. If that identity has broad access, any code running under it can inherit those rights and move beyond its intended workload boundary.
• Invoker Script: An invoker script is the code that starts or parameterises a pipeline component before the main workload runs. In AML, it becomes a security-sensitive artefact because it can shape the execution path. If attackers can modify it, they can influence what code executes in the context of the pipeline identity.
• Execution Boundary: An execution boundary is the point at which code, identity, and permissions are supposed to be contained to a specific workload. When that boundary is blurred by writable storage or inherited credentials, a routine job can become a path to broader cloud access. Strong boundaries separate content management from runtime authority.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: Azure Machine Learning privilege escalation vulnerability analysis. Read the original.