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

Why This Matters for Security Teams

AML identities are easy to over-scope because the access model is usually built for convenience, not for the actual blast radius of a pipeline, workspace, or compute job. When an identity can read secrets, change role assignments, or reach resources outside the training workflow, it stops being a narrow workload identity and becomes a lateral-movement path. That is exactly the kind of pattern highlighted in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

The practical issue is that AML environments often mix automation, shared workspaces, storage access, registry pulls, and deployment actions under one identity. That makes scope review harder than a simple RBAC checklist. Current guidance suggests treating identity scope as a runtime question: what can this identity do, and what could an attacker do if the identity were abused? NHI Mgmt Group has repeatedly shown how over-privileged non-human identities remain common, with 97% of NHIs carrying excessive privileges in its research summary.

In practice, many security teams discover the scope problem only after a workspace token has already been used to pivot into broader Azure control plane access, rather than through intentional entitlement design.

How It Works in Practice

The cleanest way to judge AML identity scope is to start from the job’s purpose, then compare it to the actual rights attached to the compute instance, managed identity, or service principal. The question is not whether the identity can complete training, scoring, or model registration. The question is whether it can do anything unrelated to that workflow. If it can access Key Vaults, modify resource permissions, enumerate subscriptions, or operate across unrelated resource groups, the scope is broader than necessary.

Security teams usually get better results when they review scope in three layers:

• What the AML job must access to run successfully, including storage, registries, and logging.
• What the identity can reach if the job is compromised, including secrets, IAM controls, and administrative APIs.
• Whether the access is static or can be issued just in time for the task, then revoked immediately after completion.

This is where workload identity matters. For autonomous or semi-autonomous pipelines, identity should prove what the workload is, not simply carry a long-lived credential. Standards such as SPIFFE illustrate the direction of travel: cryptographic workload identity with short-lived trust material is more defensible than reusable secrets. For policy decisions, runtime evaluation is stronger than pre-approved blanket access. That is why approaches aligned to NIST SP 800-207 and policy-as-code models are increasingly relevant in cloud ML operations.

AML scope also needs to account for indirect privilege. A compute instance that can read a datastore may be fine. A compute instance that can read a datastore and change its own role assignment is not. The best review signal is whether the identity could be abused to move beyond the AML workflow itself, which is the same abuse path called out in 52 NHI Breaches Analysis and the Top 10 NHI Issues.

These controls tend to break down when a shared AML platform uses one identity across multiple projects because separation of duties becomes impossible to enforce cleanly.

Common Variations and Edge Cases

Tighter identity scope often increases operational overhead, requiring organisations to balance least privilege against deployment speed and experiment churn. That tradeoff is real in AML, where data scientists, MLOps engineers, and platform teams may all expect the same workspace to “just work.” There is no universal standard for this yet, but current guidance suggests treating exceptions as temporary, explicit, and reviewable rather than default.

One common edge case is a model training job that needs temporary access to both source data and a feature store. That does not automatically justify broad subscription-wide access. Another is notebook-based experimentation, where users quietly inherit more rights than batch jobs because interactive work is harder to constrain. In those environments, the safe pattern is to separate human access from workload access and to issue short-lived credentials only for the exact task window.

Teams should also watch for scope creep through platform management permissions. If an AML identity can assign roles, manage identities, or alter networking, it is no longer scoped to model operations. That is especially risky in multi-tenant workspaces, where one weak identity can expose many projects. The issue is not just over-privilege, but the ability to chain privileges into broader compromise, a pattern repeatedly emphasized in Ultimate Guide to NHIs — Key Challenges and Risks.

Related resources from NHI Mgmt Group

• How do security teams know whether investigation access is too broad?
• How do security teams know whether secrets access is too broad?
• How do security teams know if identity provider API access is too broad?
• How do security teams know whether management-plane access is too broad?