Restoration note, September 4, 2026: This article was originally published on November 10, 2020. It describes the original Amazon SageMaker Studio architecture and should be read as a historical implementation guide, not as a current deployable security baseline. AWS revised its source article in October 2022 to incorporate SourceIdentity and the renamed IAM Identity Center service. The earlier Studio experience was renamed Studio Classic on November 30, 2023, and AWS now recommends migration to the newer Studio experience. ([aws.amazon.com](https://aws.amazon.com/blogs/machine-learning/configuring-amazon-sagemaker-studio-for-teams-and-groups-with-complete-resource-isolation/?utm_source=openai))
Security qualification: The original title promised “complete resource isolation.” The demonstrated policies can deny particular profile-launch and resource-mutation operations, but they do not establish complete tenant isolation. The supplied configuration also grants broad resource discovery, tag mutation, role passing, and access to supporting services. Those limitations are examined below.
Amazon SageMaker provides managed services for building, training, and deploying machine-learning models. This post proposed using attribute-based access control—principally IAM user names, principal tags, session tags, request tags, and resource tags—to separate users and teams sharing a Studio domain.
What the 2020 design attempted to enforce
The example divided users into Team A and Team B and addressed two cases. First, User A1 should be able to launch only the Studio profile assigned to User A1, while User A2 should be unable to launch it, and vice versa. Second, a Team B user should be denied selected operations against SageMaker artifacts tagged as belonging to Team A.
The mechanism was straightforward: attach a studiouserid tag to each user profile, attach a team tag to each team execution role, require the team tag when resources are created, and compare the principal’s team tag with the resource’s team tag during selected update, start, stop, and delete operations.
A project tag could be added to create a second level of authorization within a team. That flexibility is a genuine advantage of ABAC, but each authorization tag must be protected from unauthorized creation, removal, or alteration.
Authentication model at publication
The original Studio domain supported IAM authentication or AWS Single Sign-On authentication. IAM authentication covered IAM users and identities federated into an AWS account through an external identity provider. AWS Single Sign-On covered workforce users federated through that service.
A terminology update is necessary: AWS Single Sign-On was renamed AWS IAM Identity Center on July 26, 2022. Legacy API and CLI namespaces using “sso” were retained for compatibility. ([docs.aws.amazon.com](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html?utm_source=openai))
User personas
Administrators were expected to manage IAM resources, create tagged Studio user profiles, use the SageMaker console, and inspect SageMaker resources.
Data scientists and developers were expected to launch their assigned Studio environment, create SageMaker resources carrying the required team tag, operate on appropriately tagged resources, and inspect the resources needed for their work.
Historical per-profile launch control
The original administrator policy allowed sagemaker:CreateUserProfile only when the request included the studiouserid tag key. The article used the AWS CLI because, at publication, its workflow did not expose user-profile tagging in the Studio console.
Historical administrator condition: require aws:TagKeys to contain studiouserid when calling sagemaker:CreateUserProfile.
For an IAM user, the profile-launch policy allowed sagemaker:CreatePresignedDomainUrl only when sagemaker:ResourceTag/studiouserid matched ${aws:username}.
Historical IAM comparison: sagemaker:ResourceTag/studiouserid = ${aws:username}.
For an account-federated user, the same resource tag was compared with the session’s principal tag.
Historical federated comparison: sagemaker:ResourceTag/studiouserid = ${aws:PrincipalTag/studiouserid}.
The federated role trust configuration also allowed sts:TagSession and identified studiouserid as a transitive session-tag key. In the Okta example, the SAML assertion supplied https://aws.amazon.com/SAML/Attributes/PrincipalTag:studiouserid and listed the key through https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys.
The article treated AWS Single Sign-On as performing the user-to-profile identity mapping without the IAM presigned-URL policy. Today, CreatePresignedDomainUrl is documented specifically for domains using IAM authentication. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreatePresignedDomainUrl.html?utm_source=openai))
Historical team-role policies
The original implementation created one execution role for each team, attached a common set of policies, and tagged each role with team=<Team Name>. Because role tags appear as principal tags in the resulting session, the policies could compare the team identity with request and resource tags.
Policy 1: SageMaker read access. The supplied policy allowed sagemaker:Describe*, sagemaker:List*, search and UI operations, selected EC2 describe operations, and iam:ListRoles, generally with Resource set to *.
Policy 2: supporting services. The supplied policy granted selected create, read, update, and delete operations for Amazon S3; broad ECR operations; broad CloudWatch and CloudWatch Logs operations; and KMS describe and alias-listing operations. Most ECR, logging, monitoring, and KMS permissions used Resource: *. The S3 statement contained a bucket-name placeholder that administrators were expected to replace.
Policy 3: SageMaker developer access. The supplied policy allowed CreateApp, InvokeEndpoint, AddTags, and iam:PassRole. It also allowed sagemaker:Create* when a team tag was present and matched the principal’s team, then conditioned selected mutation operations on the resource carrying the same team tag.
Historical create condition: require the team key and compare aws:RequestTag/team with ${aws:PrincipalTag/team}.
Historical mutation condition: compare aws:PrincipalTag/team with ${sagemaker:ResourceTag/team} for selected delete, stop, update, start, trial-component, and metric operations.
The original full policy documents are not reproduced here as ready-to-deploy policies because their broad grants require redesign and testing against the current SageMaker authorization model.
Creating the historical user profiles
For an IAM user, the administrator created a profile with a unique name, set studiouserid to the IAM user name, and assigned the execution role belonging to that user’s team.
Historical CLI pattern: aws sagemaker create-user-profile --domain-id <domain-id> --user-profile-name <profile-name> --tags Key=studiouserid,Value=<IAM-user-name> --user-settings ExecutionRole=arn:aws:iam::<account-id>:role/<team-role>
For account federation, the administrator used the unique studiouserid attribute supplied by the external identity provider as the profile-tag value. For AWS Single Sign-On, the article assigned the appropriate team execution role to the resulting Studio profile.
The claim that profile tags could be added only through the CLI was true of the documented 2020 workflow, not of the current console. Current SageMaker documentation includes an optional user-profile tagging step in the console. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/dg/domain-user-profile-add.html?utm_source=openai))
What the denial tests established
The first test attempted to open a Studio profile while authenticated as a user whose identity did not match the profile’s studiouserid tag. The article reported an AccessDeniedException, demonstrating that the tested CreatePresignedDomainUrl request was denied under that configuration.
The second test created a SageMaker experiment tagged team=TeamA. A user operating through the Team B role then attempted DeleteExperiment. The article reported an AccessDeniedException, demonstrating that the tested cross-team deletion was denied.
These are useful negative tests, but their evidentiary scope is narrow: one profile-launch path and one artifact-deletion operation. They do not test every SageMaker API, supporting-service API, data path, credential source, role-chaining path, or tag-management operation.
Security review of the supplied policies
Cross-team discovery remained possible. The read policy allowed account-wide sagemaker:List* and sagemaker:Describe* requests, subject to any other applicable IAM controls. Consequently, “cannot access” should not be interpreted as “cannot discover or describe.” The demonstrated team condition applied to selected mutation operations, not to the broad read policy.
The ownership attribute was mutable. The developer policy allowed sagemaker:AddTags without a team condition. SageMaker’s AddTags API can add or overwrite tags on supported resources. Current AWS guidance explicitly warns that AddTags must be tightly controlled in an ABAC design because changing an ownership tag can change access to the resource. AWS now demonstrates restricting AddTags to tagging performed as part of resource creation by using the sagemaker:TaggingAction condition key. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AddTags.html?utm_source=openai))
Role passing was not scoped. The supplied policy granted iam:PassRole on *. IAM Access Analyzer classifies wildcard PassRole resources as a security warning and recommends naming permitted role ARNs and, where appropriate, using iam:PassedToService. ([docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html?utm_source=openai))
Supporting services were not isolated by the team tag. The broad ECR, CloudWatch, Logs, KMS, and parts of the S3 policy were independent of the SageMaker resource-tag comparison. A SageMaker control-plane denial therefore would not prove that another team’s model data, images, logs, metrics, keys, or other related assets were inaccessible.
Tag support is action-specific. IAM evaluates only the condition keys and resource types supported by the requested action. A sound ABAC implementation must check the current SageMaker service-authorization reference for every allowed API rather than assuming that one wildcard statement applies a tag boundary uniformly. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html?utm_source=openai))
Complete isolation requires more than successful denial examples. It requires control of tag creation and mutation, least-privilege access to every supporting service, constrained role passing, protected credentials, network and data-plane controls where needed, and positive and negative tests for all relevant paths.
Current service context as of September 4, 2026
The product described in 2020 became Amazon SageMaker Studio Classic. AWS documentation says the previous experience was given that name on November 30, 2023, is no longer available for onboarding, and should be migrated to the newer Studio experience. Existing architecture and migration requirements therefore need to be established before adapting this design. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/dg/studio.html?utm_source=openai))
AWS’s October 2022 revision of the source article added an owner dimension based on SourceIdentity. In Studio Classic, SourceIdentity can propagate the user-profile name into the execution-role session and CloudTrail records. More recent AWS guidance also discusses sagemaker:DomainId and sagemaker:UserProfileName context keys for supported Studio requests. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/dg/monitor-user-access-how-to.html?utm_source=openai))
IAM Identity Center also supports trusted identity propagation for suitably configured current Studio domains. This is a different identity architecture from merely renaming the 2020 AWS SSO instructions, and it requires an IAM Identity Center-authenticated domain and corresponding execution-role configuration. ([docs.aws.amazon.com](https://docs.aws.amazon.com/singlesignon/latest/userguide/setting-up-trusted-identity-propagation-sagemaker-studio.html?utm_source=openai))
How to carry the design forward safely
1. Treat the original JSON as historical material. Rebuild policies from the current SageMaker action, resource, dependent-action, and condition-key tables. Do not copy wildcard statements merely because they produced the expected 2020 denial.
2. Define the intended boundary precisely. Decide separately whether users may list, describe, read, invoke, update, tag, delete, share, or export another team’s resources. “Isolation” is too broad to serve as an authorization requirement.
3. Protect authorization tags. Require approved team and owner values at creation. Prevent ordinary users from adding, removing, or overwriting those keys later. Where supported and appropriate, distinguish tagging performed during resource creation from later tag mutation.
4. Scope role passing. Permit iam:PassRole only for approved execution-role ARNs and intended SageMaker service principals. Review role trust policies and any downstream role chaining.
5. Isolate supporting resources. Apply equivalent team or user boundaries to S3 prefixes and access points, ECR repositories, log groups, KMS keys, Secrets Manager secrets, data catalogs, file systems, endpoints, and network paths used by the workload.
6. Use identity propagation deliberately. For current deployments, evaluate SourceIdentity, SageMaker domain and user-profile context keys, IAM Identity Center trusted identity propagation, and separate execution roles. Select mechanisms according to their supported applications and role-chaining behavior.
7. Test the whole authorization graph. Test console, CLI, SDK, presigned URL, Studio application, job submission, endpoint invocation, tagging, sharing, export, and supporting-service paths. Include attempts with missing tags, altered tags, alternate roles, external credentials, shared spaces, and chained sessions.
8. Add independent guardrails. Where the risk warrants it, combine identity policies with permission boundaries, service control policies, resource policies, VPC endpoint policies, network isolation, CloudTrail monitoring, and automated policy analysis.
Conclusion
The 2020 article captured an important and still portable idea: principal, session, request, and resource attributes can make shared ML infrastructure easier to administer than one-off policies for every user. Its two tests showed that tag conditions could deny a mismatched profile launch and a cross-team experiment deletion.
The stronger lesson is that tag-based isolation is only as reliable as the controls over the tags and every alternate route to the protected resource. Broad read access, unrestricted AddTags, wildcard PassRole, and unscoped supporting-service permissions prevent the supplied policies from proving complete isolation. Use the design as a historical ABAC pattern, then build and validate a current least-privilege implementation for the exact Studio architecture in service.
For the maintained AWS version and its later SourceIdentity update, see the original AWS Machine Learning Blog article.
About the authors
Vikrant Kahlir was described at publication as a Senior Solutions Architect working with AWS strategic customers and engineering teams on managed databases, AI and ML, high-performance computing, autonomous computing, and IoT.
Rakesh Ramadas was described at publication as an ISV Solutions Architect at Amazon Web Services focused on AI, ML, and big data.
Rama Thamman was described at publication as a Software Development Manager in the AI Platforms team, leading the ML Migrations team.
Responses