Who is accountable when AML jobs inherit a user’s permissions through SSO?

Accountability sits with the identity and platform owners who allowed human privilege to flow into machine execution. If SSO makes a compute instance act under the creator’s permissions, then the governance problem is not isolated to the developer who submitted the job. It is a programme-level failure to separate human authentication from workload authorisation.

Why This Matters for Security Teams

When AML jobs inherit a user’s permissions through SSO, the blast radius is no longer limited to a single pipeline run. A job can execute with the authority of a human user, but without the human’s judgment, session boundaries, or real-time oversight. That creates an accountability gap across identity, platform, and data teams, because the machine is acting as a proxy for a person even though the control plane was designed for human access.

This is exactly the kind of problem highlighted in the OWASP Non-Human Identity Top 10 and in NHI Management Group research on the Ultimate Guide to NHIs, Key Challenges and Risks. The governance failure is not merely “who clicked run”; it is whether the organisation allowed human authentication to become workload authorisation. In practice, many security teams encounter excessive access only after an AML job has already touched data it should never have seen, rather than through intentional privilege design.

How It Works in Practice

The clean answer is to separate the identity of the user from the identity of the workload. A human can approve, trigger, or request an AML job, but the job should authenticate as a distinct non-human identity with its own policy, lifecycle, and audit trail. If SSO is used, it should establish the initiating user’s intent, not permanently transfer their entitlements into the runtime.

Current guidance suggests treating this as a runtime authorisation problem. That means the platform should evaluate what the AML job is trying to do, what dataset it is touching, and whether the action is allowed right now. In agentic or automated pipelines, static RBAC is often too blunt because permissions drift from the original use case. Better practice is to combine workload identity, just-in-time access, and short-lived credentials so the job receives only the access it needs for the task at hand.

• Issue a workload identity for the AML job, not a cloned human session.
• Use ephemeral tokens with tight TTLs and automatic revocation when the job ends.
• Evaluate access at request time with policy-as-code rather than relying only on pre-approved roles.
• Log both the human initiator and the machine principal so accountability is preserved across the chain.

NHI Management Group data shows that only 5.7% of organisations have full visibility into their service accounts, which is a warning sign for this exact pattern. The Ultimate Guide to NHIs also shows that 97% of NHIs carry excessive privileges, making inherited access especially dangerous. These controls tend to break down when legacy SSO, shared service accounts, or notebook-driven jobs cannot be cleanly separated from human sessions because the platform has no true workload identity boundary.

Common Variations and Edge Cases

Tighter separation between human and workload access often increases operational overhead, so organisations have to balance fast experimentation against controlled execution. That tradeoff is especially visible in AML environments where researchers expect interactive access, but production jobs need repeatable and auditable permissions.

There is no universal standard for this yet, but best practice is evolving toward per-job identity, just-in-time privileges, and explicit delegation records. Some teams allow a user to approve a job once and then bind the job to a separate machine principal for the duration of execution. Others require step-up authentication for sensitive datasets or model registries. The important point is that the human should remain accountable for the request, while the platform owner remains accountable for how the system turned that request into access.

Edge cases appear when shared notebooks, CI/CD runners, or federated SSO providers make it hard to distinguish a person from a workload. In those environments, inherited permissions often hide behind convenience features, and audit logs falsely imply that a human performed machine actions. NHI Management Group research on the Hugging Face Spaces breach shows how quickly exposed automation can turn into wider compromise when identity boundaries are weak.

Related resources from NHI Mgmt Group

• Who is accountable when an agentic browser changes data or permissions?
• Who is accountable when a workflow secret is exposed through a GitHub Action?
• Who is accountable when a breach exposes data through missing MFA?
• Who is accountable when a lost laptop leads to data exposure through delayed revocation?