I had a conversation last week with a Data Science lead that nearly made me choke on my coffee. We were reviewing their infrastructure, and when I pointed out a glaring gap in their compute instance configuration, he shrugged and said, “We use Azure ML so we don’t have to worry about patching or network security. It’s managed, right?”

Wrong.

That word—”managed”—does a lot of heavy lifting in cloud marketing. It implies safety. It implies that Microsoft (or AWS, or Google) has wrapped your infrastructure in a warm, impenetrable blanket. But if you’ve been paying attention to the security research coming out lately, specifically regarding machine learning platforms, you know that “managed” often just means “obscured.”

The reality of running Azure Machine Learning (AML) in production in late 2025 is that the attack surface is massive, and a lot of it is invisible unless you know exactly where to probe. I’ve spent the last few months locking down AML workspaces for clients, and honestly? It’s messy work. The defaults are almost always too permissive.

The “Silent” Threat: It’s Coming from Inside the House

Here’s the thing about ML environments: they are designed for exploration. Data scientists need to download libraries, pull data, run arbitrary code in notebooks, and visualize results. Security, by definition, restricts exploration. So, the default posture of most ML workspaces is “let everything talk to everything.”

I recently audited a workspace where every single Compute Instance had a public IP address. Why? Because it was the default setting when they set it up two years ago, and nobody changed it.

These instances are just Virtual Machines. Fancy ones, sure, with pre-installed drivers and Jupyter running, but they are VMs. If you leave them exposed, you aren’t just risking your model weights; you’re handing an attacker a beachhead into your virtual network.

The scariest vector I’m seeing right now isn’t a sophisticated zero-day in the kernel. It’s the identity assigned to the compute.

Identity Crisis

When a data scientist gets a “Permission Denied” error while trying to read a blob from storage, what’s the knee-jerk reaction?

“Just give the compute instance Contributor access.”

I see this everywhere. It solves the immediate problem. The code runs. Everyone is happy. But now you have a Jupyter notebook running on a VM that has Contributor rights to your entire subscription. If an attacker compromises that notebook—maybe through a malicious library dependency or a phishing attack targeting the scientist—they don’t just have the data. They have the keys to the kingdom.

You need to be ruthless about Least Privilege. Here is a quick snippet to check what identities are actually assigned to your compute instances. Don’t assume; check.

# List all compute instances and their assigned identities
az ml compute list \
    --resource-group my-resource-group \
    --workspace-name my-workspace \
    --query "[?type=='ComputeInstance'].{Name:name, Identity:identity.type, PrincipalId:identity.principalId}" \
    --output table

If you see SystemAssigned everywhere, go check the role assignments for those Principal IDs. If you see “Owner” or “Contributor” on the subscription scope, stop reading this and go fix it. Right now.

Network Isolation is a Nightmare (But You Need It)

I hate configuring Private Links. I really do. It involves DNS zones, VNET peering, and debugging connectivity issues that make you question your career choices.

But in 2025, running an AML workspace over the public internet is negligence.

The “silent” threats often rely on data exfiltration. An attacker gets code execution, processes your proprietary data, and then just curls it out to their own server. If your AML workspace has unrestricted outbound internet access, you won’t even see it happen.

Locking this down requires three painful steps that you absolutely must take:

1. Disable Public Network Access: The workspace API shouldn’t be reachable from the open web.
2. VNET Integration: Put your compute resources inside a subnet.
3. Outbound Rules: Use Azure Firewall or Network Security Groups (NSGs) to whitelist only the repositories and package managers you actually need.

Here is the CLI command to disable public access. It’s a simple toggle, but it breaks everything if you aren’t on a VPN or a jump box inside the network. That’s a feature, not a bug.

az ml workspace update \
    --resource-group my-rg \
    --name my-secure-workspace \
    --public-network-access Disabled

Once you do this, your data scientists will complain. They will say they can’t access the studio. They will say their local scripts failed. You have to stand your ground. The alternative is leaving a management API exposed to the world.

The Supply Chain is Poisoned

We spent so much time worrying about network perimeters that we forgot about the code itself.

Machine learning is unique because we constantly import opaque binary blobs—models. Whether it’s a pickle file from a public hub or a saved model artifact from a vendor, we treat these files as data. But pickle.load() is essentially remote code execution by design.

I probed a setup recently where the pipeline automatically pulled the “latest” model version from a registry and deployed it to a managed endpoint. No hash check. No scanning.

If an attacker compromises the registry—or just manages to upload a poisoned artifact with a higher version number—your managed endpoint is now serving their malware. And because it’s a “managed service,” you might not have the logging visibility to see what that process is actually doing under the hood.

You need to scan artifacts. It’s not optional anymore. If you aren’t scanning your containers and your model files before they hit the production inference cluster, you’re flying blind.

Practical Hardening: Where to Start

Look, I know you can’t fix everything overnight. Security fatigue is real. But if you have to pick your battles, start here:

1. Kill the long-lived credentials.
Don’t use access keys for storage. Use Managed Identity (User Assigned is best) for everything. Rotate keys if you must use them, but really, just stop using them.

2. Audit your “Compute Instance” usage.
Are they running 24/7? Are they accessible via SSH from 0.0.0.0/0? I wrote a script that runs every night and shuts down any instance that’s been idle for 4 hours. It saves money, sure, but it also reduces the window of opportunity for an attack.

3. Use Azure Policy to enforce the baseline.
Don’t rely on people doing the right thing. Enforce it. Here is a snippet of a policy definition that denies the creation of workspaces that allow public network access.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.MachineLearningServices/workspaces"
        },
        {
          "field": "Microsoft.MachineLearningServices/workspaces/publicNetworkAccess",
          "notEquals": "Disabled"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}

The Bottom Line

Managed services like Azure ML are fantastic for velocity. They let teams ship models faster than we ever could in the “roll your own Kubernetes” days. But they abstract away the infrastructure, not the risk.

The vulnerabilities exist. They are in the configuration gaps, the identity assignments, and the network boundaries. Microsoft secures the physical data center and the hypervisor. The rest? That’s on you.

Don’t wait for a security researcher to publish a blog post about how they exfiltrated data from a workspace configured exactly like yours. Go check your settings. Today.