Restoration note — September 4, 2026. This article preserves an Amazon SageMaker Studio authorization pattern first published on November 10, 2020. It should be read as a historical implementation study, not as copy-and-paste deployment guidance. The official AWS post was updated in October 2022 to add a SourceIdentity use case. AWS Single Sign-On was renamed AWS IAM Identity Center on July 26, 2022, and the Studio experience discussed in the 2020 article was renamed Studio Classic on November 30, 2023. ([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))
Current SageMaker documentation still describes domains using IAM or IAM Identity Center authentication. For IAM-authenticated domains, CreatePresignedDomainUrl creates a URL for a specified user profile and supports conditions based on that profile's resource tags. Every action, condition key, tagging path, console workflow, and supporting-service permission should nevertheless be revalidated against current documentation before deployment. ([docs.aws.amazon.com](https://docs.aws.amazon.com/en_en/sagemaker/latest/dg/onboard-custom.html?utm_source=openai))
What the 2020 pattern set out to do
Attribute-based access control, or ABAC, defines permissions using attributes such as principal, request, and resource tags. The 2020 design used one tag to bind a Studio profile to an individual identity and another tag to associate SageMaker resources with a team. AWS IAM continues to document the general pattern of matching principal tags with resource tags, including attributes supplied through federated sessions. ([docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html?utm_source=openai))
Use case 1: User A1 should be able to launch only the Studio profile assigned to User A1; User A2 should not be able to launch that profile, and vice versa.
Use case 2: Members of Team B should be denied selected operations on tagged SageMaker resources owned by Team A.
The original article called this complete resource isolation. This restoration narrows that conclusion: the supplied configuration demonstrates a per-profile launch check and reports a denied cross-team experiment deletion. It does not test every read, list, tagging, application, inference, role-passing, storage, registry, logging, or encryption path.
Authentication and user personas
The 2020 article considered IAM users, users federated into an AWS account through an external identity provider, and users managed through what was then called AWS SSO. In current terminology, AWS SSO is IAM Identity Center. The original IAM and federation paths created or updated Studio user profiles through the SageMaker API or AWS CLI, while the centrally managed identity path assigned users and team execution roles through the identity-integrated workflow. ([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))
Administrator persona. The administrator creates Studio user profiles, assigns execution roles, applies the per-user profile tag, and has the IAM and SageMaker administration permissions required for those tasks.
Data scientist or developer persona. The user launches an assigned Studio environment, creates SageMaker resources with the required ownership tags, and performs permitted operations on resources belonging to the user's team. Read and list access must be treated separately because not every SageMaker listing operation supports resource-level or tag conditions.
The authorization mechanism
The design has two distinct boundaries. The first controls who can request a launch URL for a user profile. The second controls selected operations on team-owned SageMaker resources. Keeping those boundaries separate is important: permission to enter the correct Studio profile does not, by itself, isolate every AWS resource that the profile's execution role can reach.
Profile tag. Each Studio user profile receives a unique studiouserid tag.
Identity attribute. An IAM user supplies aws:username. A federated session supplies a studiouserid principal tag. The 2020 SAML example also declared that tag as transitive so it could survive role chaining.
Team principal tag. Each team's execution role receives a team tag, such as TeamA or TeamB.
Creation check. For taggable create operations, the requested team tag is compared with the team tag on the calling principal.
Resource-operation check. For selected update, start, stop, association, metric, and deletion operations, the resource's team tag is compared with the principal's team tag.
Per-user Studio profile launch control
For an IAM user, the historical launch condition was:
sagemaker:ResourceTag/studiouserid equals ${aws:username}
For a federated role session, it was:
sagemaker:ResourceTag/studiouserid equals ${aws:PrincipalTag/studiouserid}
This condition was attached to an allow for sagemaker:CreatePresignedDomainUrl. The current service authorization reference identifies a user profile as the action's resource type and lists resource-tag condition keys for it. The API remains limited to domains whose authentication mode is IAM. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html))
The supplied article also gave the following historical command shape for profile creation:
aws sagemaker create-user-profile --domain-id <domain id> --user-profile-name <unique profile name> --tags Key=studiouserid,Value=<identity value> --user-settings ExecutionRole=arn:aws:iam::<account id>:role/<team role>
The original administrator policy allowed CreateUserProfile only when studiouserid appeared among the requested tag keys. That statement did not create a global requirement. IAM evaluates applicable permission grants together; another policy that independently allows the same operation can authorize it unless an applicable explicit deny or another limiting policy type blocks the request. ([docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html?utm_source=openai))
A production boundary should therefore protect profile creation through the complete effective-permissions model, not merely through one conditioned allow. Current SageMaker authorization documentation lists request-tag and tag-key conditions for CreateUserProfile, but administrators must test the final combination of identity policies, resource policies, permission boundaries, session policies, and organization policies. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html))
Team-scoped SageMaker resources
The 2020 creation condition expressed this rule:
aws:RequestTag/team equals ${aws:PrincipalTag/team}, and the request includes the team tag key.
The mutation condition expressed this rule:
sagemaker:ResourceTag/team equals ${aws:PrincipalTag/team}.
This is the central ABAC idea preserved from the article: a Team A execution role can create a resource labeled Team A and can perform selected later operations only when the resource still carries that ownership value. Current SageMaker authorization tables continue to list request-tag and resource-tag condition keys for many resource operations. In particular, DeleteExperiment supports experiment resources and resource-tag conditions. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html?utm_source=openai))
The historical experiment test created an experiment named USERA1TEAMAEXPERIMENT1 with the tag team=TeamA. The supplied article reports that a Team B Studio role then received an AccessDeniedException when it attempted DeleteExperiment. That result supports the stated deletion boundary for the tested policy context; it does not establish isolation for unrelated actions or services.
Why the original policy examples need rebuilding
Ownership tags were mutable. The developer policy allowed sagemaker:AddTags without a condition. SageMaker's AddTags operation can add or overwrite tags, and current AWS guidance explicitly warns that changing a user-defined ownership tag can assign permissions improperly. AWS recommends tightly scoping tagging permissions and documents sagemaker:TaggingAction as a way to limit AddTags to designated creation operations. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/APIReference/API_AddTags.html?utm_source=openai))
CreateApp was outside the team condition. The original policy allowed CreateApp independently of the conditioned Create* statement. The current authorization reference lists request-tag, resource-tag, owner-profile, space-sharing, image, instance-type, and lifecycle-configuration conditions for CreateApp. A rebuilt policy should evaluate these controls explicitly rather than relying on a wildcard create statement. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html))
PassRole was unrestricted. The supplied policy allowed iam:PassRole on every resource. IAM Access Analyzer classifies a wildcard resource for PassRole as a security warning and recommends naming approved role ARNs or constraining the destination with iam:PassedToService. IAM also cautions against attempting to control PassRole through role resource tags. ([docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html?utm_source=openai))
Endpoint invocation was unrestricted. The original policy allowed sagemaker:InvokeEndpoint on every resource without a team condition. The current authorization reference supports endpoint resources and resource-tag conditions for this action, so endpoint invocation should be scoped to the intended endpoint ARNs and ownership model. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html))
List visibility crossed team boundaries. The read policy granted sagemaker:List* broadly. Current authorization data shows that operations such as ListExperiments, ListEndpoints, and several other list calls have no resource type or tag condition keys in their authorization rows. The design must therefore distinguish metadata visibility from permission to read, invoke, update, or delete a particular resource. ([docs.aws.amazon.com](https://docs.aws.amazon.com/service-authorization/latest/reference/list_sagemaker.html))
Supporting services had separate exposure. The example granted broad permissions in Amazon ECR, CloudWatch, and CloudWatch Logs, plus KMS discovery permissions, without a demonstrated team boundary. Its S3 statement contained a placeholder rather than separate deployable bucket and object ARNs. S3 bucket operations require bucket ARNs, while object operations such as GetObject, PutObject, and DeleteObject require object ARNs, commonly restricted to a team or user prefix. ([docs.aws.amazon.com](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security_iam_service-with-iam.html?utm_source=openai))
A safer reconstruction of the policy design
Inventory actions individually. Replace broad families such as Create*, Update*, Delete*, Describe*, and List* with the actions required by tested workflows. For each action, consult the current SageMaker authorization reference to determine its supported resource types and condition keys.
Protect authorization tags. Permit the ownership tags required at creation, but prevent ordinary users from changing or removing those tags later. Where Studio requires tagging during resource creation, scope AddTags to the necessary creation operations with sagemaker:TaggingAction and control the permitted keys and values with request-tag and tag-key conditions. Current documentation notes that Studio automatically applies AWS-generated provenance tags, including domain, user-profile, and space identifiers, and that these AWS-generated tags cannot be changed by users. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/dg/security_iam_id-based-policy-examples.html?utm_source=openai))
Constrain passed roles. Limit iam:PassRole to approved SageMaker execution-role ARNs and, where appropriate, require the SageMaker service principal through iam:PassedToService. Do not use a resource wildcard merely for convenience. ([docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-reference-policy-checks.html?utm_source=openai))
Scope runtime and application access. Apply appropriate profile, space, app, endpoint, model, pipeline, experiment, training, and processing controls instead of assuming that one team tag condition covers every operation. Include associated resources when an operation authorizes more than one resource type.
Design supporting-service isolation separately. Restrict S3 to team or user prefixes, ECR to approved repositories, logging access to required log groups and streams, and KMS use to approved keys and operations. A SageMaker tag does not automatically isolate resources in another AWS service.
Account for list and search behavior. If cross-team names or metadata are unacceptable, validate whether the relevant APIs support visibility controls. Do not describe a system as completely isolated when account-wide list operations remain available.
Evaluate every applicable policy. A conditioned allow is not a security boundary if another applicable statement grants the same request. Test the effective policy set, including identity and resource policies, permission boundaries, session policies, service control policies, and resource control policies where used. Explicit denies override allows, but they should be designed carefully because they apply across otherwise valid grants. ([docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html?utm_source=openai))
Add attribution without confusing it with authorization. AWS later added documentation for propagating a Studio Classic user-profile name as SourceIdentity so activity performed through a shared execution role can be attributed in CloudTrail. SourceIdentity improves traceability under the documented conditions; it does not replace least-privilege authorization or resource isolation. ([docs.aws.amazon.com](https://docs.aws.amazon.com/sagemaker/latest/dg/monitor-user-access.html?utm_source=openai))
Validation
The original profile test attempted to launch a Studio profile whose studiouserid tag did not match the caller and reported an AccessDeniedException. The team-resource test attempted to delete a Team A experiment from a Team B Studio session and also reported an access denial.
A complete validation plan should test allowed and denied cases for profile launch, app and space creation, resource creation without tags, creation with false tags, tag replacement and removal, list and describe calls, endpoint invocation, role passing, S3 object and bucket access, ECR image access, logging, KMS operations, and every supported resource lifecycle action. Tests should also be repeated when managed policies, service features, identity workflows, or authorization tables change.
Conclusion
The 2020 article captured a useful and portable ABAC pattern: bind a Studio profile to an individual identity, carry team identity through a tagged execution role, require the team tag at resource creation, and compare principal and resource tags during later operations.
The stronger lesson is that tag-based isolation works only when ownership tags cannot be rewritten, every relevant action supports the intended conditions, associated services have their own least-privilege boundaries, and no broader policy bypasses the check. The reported denied experiment deletion demonstrates one successful authorization path—not complete isolation of the shared environment.
About the authors in the supplied 2020 copy
Vikrant Kahlir was described as a Senior Solutions Architect working with strategic customers and product and engineering teams across managed databases, AI and ML, high-performance computing, autonomous computing, and IoT.
Rakesh Ramadas was described as an ISV Solution Architect at Amazon Web Services whose focus areas included AI and ML and big data.
Rama Thamman was described as a Software Development Manager with the AI Platforms team, leading the ML Migrations team.
Responses