Topic starter
12/06/2026 12:38 am
TL;DR: Azure Machine Learning invoker scripts stored in a linked Storage Account could be modified to execute attacker code under the AML compute identity, opening paths to secret access and privilege escalation, according to Orca Security. The finding shows machine learning pipelines inherit identity risk when storage, compute, and managed identities are not tightly separated.
Editorial analysis by NHI Mgmt Group, based on content published by Orca Security: “Azure Machine Learning Escalation: When Pipelines Go Off the Rails”.
By the numbers:
- At least 33% of Azure customers are using the AML service, according to Orca Security.
Key questions
Q: What breaks when AML storage artifacts can be modified by a low-privilege user?
A: The execution boundary breaks.
Q: Why does this Azure Machine Learning issue create privilege escalation risk?
A: Because the malicious code runs under the compute instance’s identity context.
Q: How can teams tell whether an ML pipeline has too much trust in runtime artifacts?
A: Look for writable pipeline components, generated scripts that are executed directly from storage, and any job design where storage changes can influence later runs without a fresh registration or approval step.
Practitioner guidance
- Restrict write access to AML storage artifacts Limit who can modify pipeline component files, invoker scripts, and related YAML in the Storage Account linked to AML.
- Disable SSO inheritance on compute instances where possible Prevent the compute instance from inheriting the permissions of the user who created it, and assign a controlled system-assigned identity with only the permissions the workload actually needs.
- Verify script integrity before job execution Add checksum or signing validation for invoker scripts and component artifacts so tampered files are detected before the pipeline runs.
Bottom line: Azure Machine Learning pipelines can turn storage write access into code execution, which means the trust boundary sits inside the workflow, not around it.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/06/2026 10:01 am
Storage-integrity trust is the broken premise: AML pipeline design assumed that artifacts stored in the linked Storage Account could be treated as execution inputs without becoming an authority boundary. That assumption fails when writable scripts are re-used at runtime, because storage modification becomes a path to code execution. The implication is that ML pipeline storage must be governed as part of the identity plane, not as a passive artifact store.
A question worth separating out:
Q: Should organisations separate ML workload identity from the user who created the compute instance?
A: 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.
👉 Read our full editorial: Azure Machine Learning privilege escalation exposes identity risk