Amazon SageMaker Security Guide: Hardening Notebooks, Execution Roles and Model Endpoints

A SageMaker notebook is a cloud workstation running as an IAM role, and in many accounts that role can read every training bucket, push to model registries and reach the internet. Data scientists need broad access to experiment, which is exactly why notebooks, training jobs and inference endpoints become an attractive path to data and credentials. This guide covers the machine learning platform AWS now calls Amazon SageMaker AI (renamed from Amazon SageMaker on 3 December 2024, when AWS launched a broader next-generation Amazon SageMaker that includes SageMaker AI and SageMaker Unified Studio; API namespaces such as sagemaker: are unchanged). It explains execution roles and iam:PassRole, Studio and notebook instance hardening, network isolation for training and models, logging, and the IAM condition keys that let a platform team enforce a baseline. It is for cloud security engineers and ML platform owners. Generative AI services are covered separately in the Amazon Bedrock Security Guide.

Key takeaways

• The execution role is the blast radius: every notebook, training job, processing job and model runs as a role trusted by sagemaker.amazonaws.com. Scope it per workload and per data set, not one role for the whole team.
• Defaults favour convenience: notebook instance RootAccess defaults to Enabled, Studio domains default to internet access through a SageMaker-managed VPC, and AmazonSageMakerFullAccess is broad. Change all three deliberately.
• Enforce with condition keys, not guidance: sagemaker:RootAccess, sagemaker:DirectInternetAccess, sagemaker:VpcSubnets, sagemaker:VolumeKmsKeyArn and sagemaker:NetworkIsolation let you deny non-compliant resources at creation time.
• Network isolation removes credentials from containers: with EnableNetworkIsolation set, training and inference containers make no outbound calls and receive no AWS credentials, while SageMaker still moves data to and from S3 for them.
• Inference is invisible by default: InvokeEndpoint and related calls are CloudTrail data events, not logged unless you add event selectors, and even then request parameters are not recorded.

How identity and access work in Amazon SageMaker AI

Two identities are involved in every SageMaker action:

• The caller: the human or pipeline calling CreateTrainingJob, CreateNotebookInstance, CreateDomain or CreateModel. It needs SageMaker permissions and iam:PassRole on the execution role it hands over.
• The execution role: the role SageMaker assumes to run the work. Its trust policy allows sagemaker.amazonaws.com to call sts:AssumeRole, and its permissions decide what the code inside can reach in S3, ECR, KMS and CloudWatch.

In Studio, the execution role is resolved by scope: a user profile's role applies to the private spaces that user creates, and the domain or space default role applies to shared spaces. Changing a role affects every identity that assumes it. That makes role design the single most important security decision on the platform.

Admin roles and privileged access

• Treat iam:PassRole as privileged: anyone who can pass a powerful execution role to CreateTrainingJob can run arbitrary code with that role's permissions. Restrict the action to specific role ARNs and add the condition iam:PassedToService = sagemaker.amazonaws.com, as AWS documentation shows.
• Separate platform admins from users: platform admins create domains, user profiles and lifecycle configurations; data scientists create spaces and jobs within guardrails. CreatePresignedDomainUrl lets the caller open Studio as any user profile it is allowed to name, so scope it with sagemaker:ResourceTag or resource ARNs to the caller's own profile.
• Lifecycle configurations run as root: AWS notes that notebook instance lifecycle configurations always run with root access even when root access is disabled for users. Only platform admins should create or attach them, and their scripts belong in source control.
• Avoid AmazonSageMakerFullAccess in production: AWS describes it as fairly broad. Its S3 object permissions apply to buckets with sagemaker or aws-glue in the name, and it grants some S3 actions on all resources, including s3:CreateBucket and s3:PutBucketCors. Start from the per-API minimum policies AWS publishes.

See the AWS IAM Policies and Roles Guide for PassRole patterns and the Top 10 AWS IAM Mistakes for the common errors.

Integrations, API tokens and service accounts

Execution roles are non-human identities, and ML work adds several more credential types around them:

• Scoped execution roles: AWS recommends replacing "Resource": "*" for S3 and ECR with the specific input and output locations and container images of the job: InputDataConfig and OutputDataConfig.S3OutputPath for training, ProcessingInputs and ProcessingOutputConfig for processing, and PrimaryContainer.ModelDataUrl for models. CloudWatch and Logs actions stay on * because those actions do not support resource-level scoping.
• Third-party tokens in notebooks: data scientists paste model hub, Git and data warehouse tokens into notebooks and environment files. Store them in AWS Secrets Manager and grant the execution role access to the specific secret. The Hugging Face API token exposure of 2023 found 1,681 working tokens in public repositories, 655 with write permission, according to the researchers: a model supply chain risk as much as a credential one. See the Model Supply Chain Guide.
• Instance role credentials: notebook instances are EC2-based and their role credentials can be read by code on the instance. The Capital One breach of 2019 shows what a broadly permissioned instance role does in the wrong hands. Set the instance metadata service to require IMDSv2 through InstanceMetadataServiceConfiguration. See the EC2 Instance Metadata Service Hardening Guide.
• Pipelines: CI systems that start training or deploy endpoints should use federated workload identity to assume a deployment role, with PassRole limited to the approved execution roles. See the AI Infrastructure Workload Identity Guide.

Choosing between notebook instances and Studio

• Notebook instances: one managed instance per user with one execution role. Simple to reason about and easy to isolate, but each instance is a long-running host to patch, and root access and internet access must be turned off explicitly.
• Studio domains: many users and spaces sharing a domain, EFS volume and network configuration. Better for teams and for central guardrails, but role resolution (user profile, space, domain default) and security group design need more care.
• Small teams with a few users can run notebook instances in a dedicated account with a tight SCP. Larger organisations should standardise on VpcOnly Studio domains created by a platform team, one account per environment, with execution roles vended per project.
• When to require network isolation: always for third-party algorithms and containers you did not build, and for production models; optional for exploratory training on non-sensitive data inside a VpcOnly environment. AWS Marketplace training jobs and models already require it; Chainer and SageMaker reinforcement learning managed containers do not support it.

Logging and detection

Detections worth building:

• Guardrail bypass: CreateNotebookInstance or UpdateNotebookInstance with RootAccess or DirectInternetAccess Enabled in an account where policy should deny it, which shows a policy gap.
• Presigned URL for another user: CreatePresignedDomainUrl where the caller is not the owner of the target user profile.
• Execution role used outside SageMaker: API calls signed by an execution role session from source addresses that are not SageMaker or your VPC. GuardDuty's credential exfiltration findings cover part of this. See the Amazon GuardDuty Guide.
• Endpoint invocation anomalies: new callers or volume spikes on InvokeEndpoint (once data events are on), which can indicate model extraction attempts (MITRE ATLAS AML.T0024 Exfiltration via AI Inference API).
• Lifecycle configuration changes: creation or update of notebook lifecycle configurations and Studio lifecycle configurations, because they run with elevated rights.

Hardening baseline

VpcOnly requirements

A VpcOnly Studio domain needs private subnets (public subnets are not supported) and interface endpoints for com.amazonaws.region.sagemaker.api, com.amazonaws.region.sagemaker.runtime and Amazon S3, plus Service Catalog for SageMaker Projects and STS and CloudWatch Logs for remote training with the SageMaker Python SDK. Security groups must allow NFS on TCP 2049 to the EFS volume and TCP 8192 to 65535 within the group. AWS advises a separate security group per user profile, because a shared domain-level group lets all applications in the domain reach each other.

Presigned URL limits

A URL from CreatePresignedDomainUrl expires after at most 300 seconds (the default), and the JupyterLab session defaults to 12 hours (SessionExpirationDurationInSeconds 1,800 to 43,200). IAM authorisation is enforced on every HTTP request and WebSocket frame. Note that IP filtering with aws:SourceIp does not work through a VPC interface endpoint; use aws:SourceVpce there.

Rollout

1. Inventory notebook instances, domains, user profiles and execution roles; record which roles use AmazonSageMakerFullAccess.
2. Deploy the condition-key guardrails as an SCP to a sandbox OU and confirm that compliant creation still works.
3. Build new VpcOnly domains alongside existing ones and migrate users team by team; do not convert a live domain in place without testing.
4. Replace shared execution roles with per-project roles scoped to their buckets and images.
5. Extend the SCP to production OUs; roll back by detaching it if a critical workflow breaks, then fix the workflow rather than widening the guardrail.

Common misconfigurations

• One execution role for the whole data science team: every notebook can read every data set, and one compromised notebook exposes all of them.
• Unrestricted PassRole: iam:PassRole on * lets a user pass an admin role to a training job and run code as it.
• Root and internet left on: notebook instances with root access and direct internet access give any downloaded package or notebook a root shell with egress.
• Shared domain security group: applications of different users can reach each other inside the domain.
• Secrets in notebooks: tokens in cells, environment files and Git history, copied into shared spaces and S3 snapshots.
• No inference logging: production endpoints with no data events, so nobody can say who queried a model or how often.

Framework mapping

Practitioner checklist

• Create per-project execution roles scoped to specific buckets, prefixes and ECR images; retire AmazonSageMakerFullAccess in production.
• Restrict iam:PassRole to named execution roles with iam:PassedToService = sagemaker.amazonaws.com.
• Deny notebook instances with root access or direct internet access using SageMaker condition keys.
• Run Studio domains in VpcOnly mode with the required interface endpoints and a security group per user profile.
• Require customer managed KMS keys and network isolation for training and production models.
• Limit presigned URL creation to the caller's own profile and to corporate networks or VPC endpoints.
• Move tokens out of notebooks into Secrets Manager and scan repositories and S3 for leaked credentials.
• Enable CloudTrail data events for production endpoints and alert on guardrail bypass and lifecycle configuration changes.

Standards and references

• AWS: Identity-based policy examples for Amazon SageMaker AI
• AWS: How to use SageMaker AI execution roles
• AWS: Connect Studio notebooks in a VPC to external resources
• AWS: CreateNotebookInstance API reference
• AWS: Network isolation for training and inference containers
• AWS: Logging Amazon SageMaker AI API calls using CloudTrail
• AWS: CreatePresignedDomainUrl API reference
• MITRE ATLAS: Exfiltration via AI Inference API

Related NHI Mgmt Group resources: Amazon Bedrock Security Guide · AI Infrastructure Workload Identity Guide · Jupyter Server Security Guide · AI Model Security Guide