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.
At a glance
What this is: This is an analysis of how Azure Machine Learning pipeline artifacts stored in a linked Storage Account could be altered to trigger code execution and privilege escalation under the compute identity.
Why it matters: It matters because IAM, PAM, and NHI programmes have to treat ML pipeline storage, managed identities, and execution context as one governed access path, not separate controls.
By the numbers:
- At least 33% of Azure customers are using the AML service, according to Orca Security.
Context
Azure Machine Learning pipelines are not just model workflows. They are identity-bearing execution paths that combine storage, compute, managed identities, and secret access into a single operational chain.
The governance problem is that scripts and artifacts stored in a linked Storage Account can become part of the execution boundary if they are trusted at runtime. That makes storage write access an identity control issue, not only a data management issue.
In this article, Orca Security shows that the boundary between artifact storage and compute identity was looser than many teams would assume. For ML programmes, that means storage permissions, SSO behaviour, and managed identity scope all need to be reviewed together.
Key questions
Q: What breaks when AML storage artifacts can be modified by a low-privilege user?
A: The execution boundary breaks. In this pattern, writable storage becomes a code path, so a user with only artifact access can alter the script that a pipeline later runs inside the compute environment and use that execution to reach secrets or identity-backed resources.
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. If that context has broad managed identity permissions, the attacker can move from script modification to Key Vault access, role changes, and other cloud resources that the identity can already reach.
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. Those are signs that artifact integrity is part of the runtime trust model.
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.
Technical breakdown
How storage-backed invoker scripts become an execution boundary
Azure Machine Learning generates invoker scripts for pipeline components and stores them in a linked Storage Account. Those scripts are later used to fetch parameters and execute component logic on AML compute. If write access is too broad, a user can replace or alter the script that the job will execute. The important technical point is that the runtime trusts the storage artifact as part of the job definition, so storage integrity directly affects code execution integrity.
Practical implication: Treat AML storage write access as code-execution authority, not as a routine artifact permission.
Why managed identity scope turns code execution into privilege escalation
Once malicious code runs in the AML compute context, it inherits whatever identity the compute instance uses. If that identity is user-assigned or system-assigned with broad permissions, the code can access Key Vaults, modify role assignments, and move beyond the original pipeline scope. The escalation is not caused by Azure Machine Learning alone. It emerges from the combination of executable artifacts, inherited identity, and overbroad permission scope.
Practical implication: Review compute identity scope before enabling workflows that can execute storage-backed scripts.
Why SSO and inherited user context widen the attack path
Orca Security describes a path where SSO enabled on the compute instance allowed the execution context to reflect the permissions of the user who created the instance. That changes the problem from a controlled service identity to a potentially much larger human privilege surface. In practice, the AML job can become a proxy for the creator's access if the environment is configured to inherit user permissions instead of forcing a constrained managed identity.
Practical implication: Separate user privilege from compute execution so ML jobs cannot inherit broader human access than intended.
Threat narrative
Attacker objective: The attacker aims to turn low-privilege storage access into execution under a higher-value AML identity and use that path to reach secrets and broader cloud permissions.
- Entry occurred through write access to the Storage Account that held AML pipeline artifacts and invoker scripts.
- Credential or authority abuse followed when the attacker modified the script that AML would later execute inside the compute environment.
- Escalation happened as the running code inherited the AML managed identity or user context and reached secrets or broader Azure permissions.
- Impact was the ability to access Key Vault data, modify privileges, and pivot to other Azure resources under the abused identity.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Managed identity scope becomes the real blast-radius control: The article shows that once code executes inside AML, the effective security boundary is the managed identity attached to the compute instance. When that identity carries contributor, owner, or creator-derived permissions, pipeline execution becomes a privilege amplifier. Practitioners need to see managed identity scope as the deciding variable in ML workload containment.
SSO-enabled inheritance creates a hidden human-to-machine delegation chain: When compute instances can reflect the permissions of the user who created them, the machine workload inherits human privilege in ways many governance models do not expect. That creates a hybrid identity problem where human access design directly shapes machine risk. The conclusion is that ML environments need explicit identity separation, not just workload controls.
Code snapshots reduce one abuse path but do not remove the governance issue: Microsoft’s change to use a snapshot of component code for scheduled jobs narrows storage-based script tampering after registration, but it does not eliminate the broader question of who can alter components, register new code, or control runtime identity. That means the governance model still has to cover artifact provenance, component registration, and identity scope together.
Privilege escalation in ML is an identity architecture issue, not only a platform flaw: The vulnerability works because execution, storage, and permission inheritance were allowed to intersect too loosely. This is a pattern that reaches beyond Azure Machine Learning into any environment where generated code, managed identities, and secret stores share a weak trust model. Practitioners should treat ML pipelines as identity-sensitive infrastructure with explicit control points.
What this signals
Artifact integrity has become part of identity governance: ML teams should treat pipeline files, invoker scripts, and component registration as governed access surfaces. When a stored artifact can change what identity executes, storage control is no longer a secondary hygiene issue.
Machine learning pipelines expose a familiar NHI pattern in a new form: a workload identity, a secret store, and a writable artifact repository can combine into a broader blast radius than any one control suggests. The governance lesson is to review the whole execution path, not just each service in isolation.
For practitioners
- 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. Treat those write permissions as execution-path authority and separate them from read access.
- 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.
- Enforce immutability and versioning on critical blobs Protect AML script blobs with immutability policies and version history so unauthorized overwrites can be blocked or rolled back quickly.
- Review managed identity scope on every AML workspace Check whether compute identities can reach Key Vaults, storage accounts, or subscription-level roles that exceed the pipeline’s intended function.
Key takeaways
- Azure Machine Learning pipelines can turn storage write access into code execution, which means the trust boundary sits inside the workflow, not around it.
- The reported escalation path matters because the compute identity may reach Key Vaults and other Azure resources beyond the original script location.
- Restricting artifact writes, tightening identity scope, and validating script integrity are the controls that reduce the exposure most directly.
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 and MITRE ATT&CK address 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-02 — Secret Leakage | The article shows how writable pipeline artifacts can expose secrets through AML execution paths. |
| NHI-05 — Overprivileged NHI | The compute identity and inherited permissions create the escalation path described in the article. | |
| NHI-07 — Long-Lived Secrets | The article highlights persistent access risk when identities and artifacts remain reusable over time. | |
| Recommendation — Scan AML artifacts for exposed secrets and treat writable scripts as potential secret-leak sources. Reduce AML compute permissions to the minimum required for each pipeline component. Shorten credential lifetime and revoke reusable access paths tied to AML workloads. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | AML identities and related credentials need lifecycle control when storage changes can affect execution. |
| AC-6 — Least Privilege | The escalation depends on identities holding more permissions than the job actually requires. | |
| Recommendation — Apply authenticator lifecycle controls to AML identities and rotate or revoke exposed credentials quickly. Enforce least privilege on AML compute, storage write access, and downstream Key Vault permissions. | ||
| MITRE ATT&CK | TA0006; TA0004 — Credential Access; Privilege Escalation | The exploit path uses identity abuse to move from code execution to broader access. |
| Recommendation — Map AML abuse paths to credential access and privilege escalation tactics in your detections and hunts. | ||
Key terms
- Azure Machine Learning Compute Identity: The identity used by an AML compute instance or pipeline to access Azure resources while a job runs. In practice, it determines what a successful code execution can reach, so its scope defines the blast radius of any pipeline abuse or artifact tampering.
- 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.
- Managed Identity: A cloud-provider-managed identity assigned to a compute resource, allowing it to authenticate to cloud services without storing credentials in application code.
- Pipeline Artifact Integrity: The assurance that ML pipeline files, scripts, and configuration objects have not been altered in a way that changes execution behaviour. When integrity is weak, storage becomes an execution control and identity risk follows directly.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org