Azure Machine Learning Security Guide

An Azure Machine Learning workspace is a cluster of managed identities, stored credentials, compute and storage that most security teams never review as one system, so a data scientist role or a datastore key can reach far more than intended. Each workspace depends on a storage account, a key vault, a container registry and Application Insights, runs jobs on compute with its own identities, and exposes models through online endpoints with their own keys and tokens. This guide covers the customer-side controls for those parts: workspace and compute identities, RBAC roles, datastore authentication, managed virtual network isolation, endpoint authentication, encryption, Azure Policy and logging. It is written for cloud security engineers, ML platform owners and identity teams. Generative AI services in Azure AI Foundry are covered in the Azure OpenAI and Azure AI Foundry Security Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

The workspace identity is highly privileged by design. The default system-assigned identity holds Contributor on the workspace, its resource group and the container registry, Storage Blob Data Contributor on storage and full key vault access. Protect everything that can act through it.
The workspace storage account is a code execution path. Microsoft warns that it holds code that runs on workspace compute, so write access to it can expose workspace data and credentials. Do not grant users direct access to it.
Prefer identity-based datastores. Credential-based datastores cache account keys, SAS tokens or service principal secrets in the workspace key vault, and other workspace users with enough permission can retrieve them. Even the Reader role can view datastore credentials.
Several security choices are fixed at creation. Data isolation, the hbi_workspace flag, SSH on compute instances and the managed network mode can only be set once or changed in one direction. Decide them in the landing zone design, not after the first project.
Allow only approved outbound is the exfiltration control. Managed virtual network isolation in that mode limits compute to approved private endpoints, service tags and FQDNs, and an Azure Policy definition can require it.

How the workspace fits together

A workspace is the security boundary for experiments, data assets, models, environments and endpoints. It is not self-contained: it uses Azure resources in your subscription and identities that act on them.

Component	What it holds or does	Main risk	First control
Workspace storage account	Code snapshots, logs, default datastores, notebook files	Tampered code runs on compute; data copied out	No direct user access; private endpoint; see the Azure Storage Security Guide
Workspace key vault	Datastore credentials, connection secrets	Cached keys retrieved by users or code	Identity-based datastores; RBAC model; see the Azure Key Vault Security Guide
Container registry	Environment images used by jobs and endpoints	Poisoned image runs with compute identity	Defender for Containers scanning; restricted push rights
Compute instances	Single-user development VMs	Long-lived, internet-reachable notebooks with an identity	No SSH unless needed; idle shutdown; managed network
Compute clusters and serverless compute	Training and batch jobs	Job code using a broad managed identity	Dedicated user-assigned identity per cluster
Online endpoints	Model inference APIs	Non-expiring keys; model extraction through the API	`aad_token` auth on managed endpoints; network isolation
Registries	Shared models, environments and components across workspaces	Unapproved models deployed	AzureML Registry User scoped; approved registry policies

Workspace and compute identities

Azure Machine Learning uses Microsoft Entra ID for users and managed identities for service-to-service calls. There are three layers of non-human identity to design for, and they are the most common source of over-privilege in ML estates. See the Azure Managed Identities Security Guide for the general model.

Workspace identity

System-assigned by default: it has the same name as the workspace and users cannot get its token. Microsoft lists its roles as Contributor on the workspace and resource group, Storage Blob Data Contributor on storage, full key vault access and Contributor on the container registry.
User-assigned for control: a user-assigned identity lets you pre-create the identity, assign roles through your own pipeline and reuse a registry. Its documented roles are Contributor on the workspace, storage, registry and Application Insights, and on key vault Contributor plus Key Vault Administrator (RBAC model) or every access policy permission except purge.
Changes are one-way: a system-assigned workspace can be updated to system plus user-assigned, but not back.
Do not remove its access: revoking the workspace identity's roles breaks the workspace; the resync keys operation restores them. Contain it instead by isolating the resource group it controls.

Compute identities

Compute clusters: one system-assigned identity or several user-assigned identities, not both. The identity retrieves datastore connection details from key vault and pulls images from the registry. Job code selects an identity by client ID or reads DEFAULT_IDENTITY_CLIENT_ID.
Compute instances: a system- or user-assigned identity, which appears in Entra ID as /workspace-name/computes/compute-instance-name, needs at least Storage Blob Data Reader on datastores it reads.
Online endpoints: a system-assigned identity by default, with some basic roles assigned automatically.
Design rule: give each cluster that handles a distinct data classification its own user-assigned identity with read roles on only that data. A shared cluster identity with access to every datastore turns any job into access to all data. See How to find over-privileged Azure managed identities.

RBAC roles for people and pipelines

Role	Grants	Watch for
AzureML Data Scientist	All actions in the workspace except creating or deleting compute and changing the workspace	Covers online endpoint create, update, delete and scoring
AzureML Compute Operator	Create, manage, delete and access compute	Combine with Data Scientist only for self-service teams
AzureML Registry User	Read, write and delete assets in a registry	Cannot create or delete the registry itself
Reader	View assets	Can view datastore credentials, so it is not harmless
Contributor	Create, edit and delete assets, compute and deployments	Too broad for most data scientists
Owner	Full access including role assignments	Platform team only, through PIM
Azure Machine Learning Workspace Connection Secrets Reader	Read secrets from workspace connections	Assign only to identities that need connection secrets

Custom roles: Microsoft's "Data Scientist Custom" example uses NotActions on workspaces/computes/*/write, workspaces/*/delete, workspaces/write and Microsoft.Authorization/*/write. If a user holds a second role that grants a denied action, the denial may not take effect, so check combined assignments.
Sensitive actions: treat workspaces/computes/listKeys/action, onlineEndpoints/listKeys/action, onlineEndpoints/regenerateKeys/action and onlineEndpoints/token/action as credential access and alert on them.
Role inheritance at creation: creating a workspace does not make the creator Owner; they keep whatever role they hold at a higher scope.
Propagation: role changes can take up to an hour, which matters when removing a leaver's access during an incident.

See the Azure RBAC and Service Principals Guide for scoping and PIM patterns.

Datastores and data access

Approach	What is stored	Who authenticates	Use when
Credential-based datastore	Account key, SAS token or service principal secret, cached in the workspace key vault	The stored credential, for every user of the datastore	Only where the storage type does not support identity-based access
Identity-based, compute identity	Storage location only	The compute cluster or instance managed identity	Scheduled training on curated datasets
Identity-based, user identity passthrough	Storage location only	The submitting user's Entra token (`identity: type: user_identity`)	Data where each user's own access must apply

Supported stores: identity-based access covers Azure Blob Storage, ADLS Gen1 and ADLS Gen2, with Storage Blob Data Reader as the minimum role.
Passthrough limits: user identity jobs work through the CLI and Python SDK v2, not studio. In pipelines set identity on each step. A job cannot use user identity and compute identity together.
Silent fallback: if the datastore holds cached credentials, they are used instead of the user's identity, and if a job sets no identity on a datastore without credentials, the compute identity is used. Remove credentials from datastores you mean to be identity-based.
Retire stored secrets: where a credential-based datastore must stay, use a SAS token with a short expiry and rotation rather than an account key. See the Azure SAS Tokens Security Guide.

Network isolation with the managed virtual network

Inbound access to the workspace is controlled with private endpoints and by disabling public network access. Outbound access from compute is controlled by managed virtual network isolation, which covers compute instances, compute clusters, serverless compute and managed online endpoints.

Mode	Outbound behaviour	One-way rule
Disabled	Not restricted, or you use your own virtual network	Can move to either managed mode
Allow internet outbound	All internet outbound allowed	Cannot go back to Disabled
Allow only approved outbound	Only approved private endpoints, service tags and FQDNs	Cannot change to Allow internet outbound

Outbound rule types: private_endpoint (both modes), service_tag and fqdn (approved outbound only; FQDN rules support ports 80 and 443). FQDN rules cannot reach storage accounts, so use private endpoints for storage.
Cost and provisioning: the first FQDN rule deploys an Azure Firewall (Standard SKU by default, Basic optional) that is billed separately. The first compute takes about 30 minutes to provision the network; az ml workspace provision-network does it in advance, with --include-spark for serverless Spark.
Every extra rule is a path out: Microsoft states it cannot guarantee exfiltration protection once you add outbound rules beyond the defaults. Review FQDN rules such as package mirrors like firewall changes, and prefer a private package feed.
Approval permissions: since 30 April 2025 the workspace identity no longer gets private endpoint approval rights automatically; assign the Azure AI Enterprise Network Connection Approver role or an equivalent custom role.
Limits to plan for: once enabled, managed isolation cannot be disabled; Kubernetes compute and attached VMs are not supported; existing compute must be deleted and recreated to join the managed network.

Compute instances and endpoints

Compute instances are single-user: admins can create one on behalf of a data scientist; SSO is then disabled if a setup script or custom app is used, and only the assignee can enable it.
SSH is off by default and fixed at creation: leave it off unless remote debugging is required, and use an existing managed public key rather than generating keys ad hoc.
Idle shutdown: set between 15 minutes and 3 days (for example "idleTimeBeforeShutdown": "PT30M"). It does not trigger if the workspace identity lacks Contributor on the workspace, so test it.
Local authentication on compute: use the built-in Azure Policy to disable local authentication methods so access goes through Entra ID.
Endpoint auth modes: key (no expiry, manual rotation), aml_token (short-lived) and aad_token (Entra ID, managed endpoints only, needs score/action). Microsoft recommends aad_token for production on managed endpoints.
Model abuse through the API: scoring access can support model extraction or data inference (ATLAS AML.T0024 Exfiltration via AI Inference API). Rate limit at an API gateway and log traffic with AmlOnlineEndpointTrafficLog.

Encryption and high business impact settings

Customer-managed keys: the key vault needs soft delete and purge protection, and the service identities need Wrap Key, Unwrap Key and Get (or Key Vault Crypto Service Encryption User under RBAC). After creation the key can only be changed to another key in the original vault.
Service-side versus subscription-side: service-side encryption keeps metadata on Microsoft-managed multitenant resources with document-level encryption using your key; the classic option creates Cosmos DB, AI Search and Storage in a managed resource group named azureml-rg-<workspace>_<GUID>. Do not delete that resource group.
Disk limits: the compute cluster OS disk always uses Microsoft-managed keys, and compute instance OS and temporary disks do not support CMK.
hbi_workspace: set only at creation; it reduces diagnostic data sent to Microsoft, encrypts and cleans the compute scratch disk between jobs, and passes credentials through key vault. It makes support troubleshooting harder, so reserve it for regulated data.

Logging, detection and metrics

Enable diagnostic settings on each workspace (an Azure Policy definition can deploy them to Log Analytics). The audit-relevant categories record reads, creates and deletes: DataStoreReadEvent and DataStoreChangeEvent (table AmlDataStoreEvent), ModelsReadEvent and ModelsChangeEvent (AmlModelsEvent), EnvironmentChangeEvent, ComputeInstanceEvent, DeploymentReadEvent, and on registries RegistryAssetWriteEvent. The Activity Log adds control plane events such as workspace changes, compute deletion and "List secrets".

Threat	Framework ID	Signal
Use of a stolen user or service principal account	ATT&CK T1078.004 Cloud Accounts	Sign-ins to the workspace from new locations; new role assignments
Retrieval of stored secrets and endpoint keys	ATT&CK T1528 Steal Application Access Token	"List secrets", `listKeys` and `token` actions by unusual identities
Bulk copying of training data	ATT&CK T1530 Data from Cloud Storage	Datastore read spikes; storage egress; new outbound rules
Poisoned environment image	ATT&CK T1525 Implant Internal Image; ATLAS AML.T0010 Supply Chain Compromise	Registry pushes outside the pipeline; `EnvironmentChangeEvent`
Tampering with data or models	ATLAS AML.T0020 Training Data Poisoning; AML.T0018 Manipulate AI Model	`DataSetChangeEvent`, `ModelsChangeEvent` and registry writes by unexpected identities
GPU abuse for mining	ATT&CK T1496 Resource Hijacking	New clusters with large GPU SKUs; `AmlComputeCpuGpuUtilization` outside job windows

Metrics to track:

Credential-based datastores: count across workspaces, trending to zero.
Network posture: share of workspaces with public network access disabled and in Allow only approved outbound mode.
Endpoint auth: share of production managed endpoints on aad_token.
Identity scope: share of compute clusters with a dedicated user-assigned identity, and the number of datastores each can read.
Compute hygiene: share of compute instances with idle shutdown and SSH disabled.

Phased rollout

Inventory: list workspaces, registries, compute, endpoints, datastores (with their auth type) and every role assignment, including managed identities.
Assign Azure Policy in Audit: private link, public network access disabled, local authentication disabled on compute, idle shutdown, Allow Only Approved Outbound managed network, CMK where required, and resource logs enabled.
Turn on diagnostics: send workspace and endpoint logs to the central workspace before changing access.
Fix identities: create user-assigned identities per cluster, move datastores to identity-based access, remove cached credentials and replace Contributor grants with AzureML Data Scientist or a custom role.
Build new workspaces right: decide data isolation, hbi_workspace and CMK at creation; enable the managed network in approved outbound mode with a private package feed, and pilot with one team.
Migrate existing workspaces: because compute must be recreated to join the managed network, schedule it per project, and keep the old workspace read only until jobs are proven.
Switch endpoints to aad_token: update clients first, then rotate and retire keys. Rollback is redeploying the endpoint with key auth for a fixed period.
Move policies to Deny: once compliant, block new non-compliant workspaces and compute.

Common failure patterns

Everyone is Contributor: data scientists get Contributor on the resource group, which also covers storage, key vault and registry used by the workspace identity.
Account keys in datastores: a datastore created with an account key gives every workspace user with enough rights the full storage key.
Users with write on the workspace storage: granted "for convenience", it lets a user change code that runs under compute identities.
Approved outbound mode diluted: broad FQDN rules for package sites and model hubs are added until the network behaves like internet outbound.
Endpoint keys in notebooks: non-expiring endpoint keys are copied into notebooks and app settings and never rotated.

Framework mapping

Framework	Reference	Where it applies
NIST SP 800-53 Rev 5	AC-2, AC-6, SC-7, SC-12, SC-28, AU-6	Identity lifecycle and least privilege; managed network; CMK; log review
NIST CSF 2.0	PR.AA-05, PR.DS-01, DE.CM-09, ID.AM-02	Role design; data at rest; runtime monitoring; asset inventory
ISO/IEC 27001:2022 Annex A	A.5.15 Access control; A.8.24 Use of cryptography; A.8.16 Monitoring activities; A.8.22 Segregation of networks	RBAC; CMK; diagnostics; managed network
MITRE ATLAS	AML.T0010, AML.T0018, AML.T0020, AML.T0024	Supply chain, model and data tampering, inference API abuse

Practitioner checklist

Workspaces have public network access disabled and private endpoints for inbound access.
Managed virtual network runs in Allow only approved outbound mode, with each FQDN rule owned and reviewed.
Each compute cluster uses a dedicated user-assigned identity with read access only to its data.
Datastores are identity-based; no account keys are cached in the workspace key vault.
No user has direct write access to the workspace storage account.
Data scientists hold AzureML Data Scientist or a custom role, not Contributor; Owner is PIM-eligible only.
Production managed online endpoints use aad_token; any remaining keys are rotated on a schedule.
Compute instances have idle shutdown, SSH off unless justified, and local authentication disabled.
Diagnostic settings send audit categories to the SIEM, with alerts on secret listing, key retrieval and registry writes.
CMK, data isolation and hbi_workspace decisions are recorded for each workspace at creation.

Azure Machine Learning Security Guide: Workspaces, Compute Identities, Datastores and Network Isolation