Least privilege for ML artifacts

Lesson 1 of 4 in Securing ML and AI Workloads.

ML security on AWS starts from one observation: you rarely touch the data — services acting on your behalf do. A training job reads the dataset; an endpoint pulls the model artifact. So IAM for ML has two planes. The first is ordinary: policies on the humans and pipelines that call SageMaker AI APIs. The second is the exam's favorite: the execution role a job or endpoint assumes while it runs. Least privilege there is concrete and testable — scope the training role's S3 permissions to the exact prefixes it needs (arn:aws:s3:::ml-data/claims/train/*), give the endpoint role only its model artifact and logging, and keep roles per purpose rather than one god-role shared by every notebook. The hinge between the planes is iam:PassRole: a user may only hand SageMaker an execution role if their own policy allows passing that role — which is how you stop anyone from escalating by attaching the admin role to a training job.

For the humans, standard IAM hygiene carries over with ML flavor: roles, not long-lived users (federate through IAM Identity Center; no access keys in notebooks); separate roles per team and stage so the experimentation sandbox cannot write to the production model registry; permissions boundaries on what ML teams may self-provision; and tags on jobs/endpoints so permissions (and cost attribution) can key off them. The pattern to recognize in scenarios: scoping down is almost always the right direction, and the mechanism that scopes service work is the execution role.

Interactive sorting exercise: Which role should carry each permission?

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.