How to enforce IAM permissions boundaries for SageMaker Unified Studio Tooling blueprints

# Why this matters Organizations using SCPs to require a permissions boundary on every IAM role saw SageMaker Unified Studio project creation fail because the Tooling blueprint previously created roles without a boundary. The failure surfaced as a Tooling environment provisioning error and traced back to an iam:CreateRole explicit deny in the SCP. Without a fix, organizations that require boundaries couldn't adopt SageMaker Unified Studio without changing their governance.

# What changed SageMaker Unified Studio now supports supplying a customer-managed permissions boundary ARN (PermissionsBoundaryArn) on the Tooling blueprint. When configured, SageMaker attaches that boundary to every IAM role the Tooling blueprint provisions for a project. That lets accounts keep SCP-driven guardrails while allowing Unified Studio projects to deploy successfully.

# When you should use this Use a permissions boundary on the Tooling blueprint when your governance mandates boundaries on all IAM roles, or when you want to limit capabilities of Tooling-created roles. Example constraints include disabling conversational AI, agent code generation, or notebook cell execution provided by integrated agent features, while still permitting data access and SQL queries through other paths.

# Designing the permissions boundary The post provides an illustrative permissions boundary that:

• Allows the core AWS services SageMaker Unified Studio uses (SageMaker, S3, Glue, Lake Formation, Redshift variants, Athena, Bedrock, Lambda, KMS, Secrets Manager, CloudWatch, Logs, STS AssumeRole, iam:PassRole, and required EC2 network interface actions).
• Explicitly denies DataZone actions that enable agent-driven notebooks and conversations to block agent capabilities.

That example is for illustration only. Tailor your boundary to the principle of least privilege for your workloads and organization.

# Configure the Tooling blueprint (high level)

1. 1Create a customer-managed IAM policy to use as your permissions boundary and publish it in the account.
2. 2Note the policy ARN (the permissions boundary ARN) you created.
3. 3Configure the Tooling blueprint to use that PermissionsBoundaryArn. The blog demonstrates doing this through the AWS Command Line Interface (AWS CLI).

# Validate enforcement after provisioning After creating a project with the Tooling blueprint configured with PermissionsBoundaryArn:

• Inspect the IAM roles the blueprint provisioned (for example, the project IAM role and service roles created by the blueprint).
• Confirm each role's permissions boundary is the ARN you configured.
• If your SCPs previously caused iam:CreateRole denials, confirm that project creation proceeds without the prior 403/CREATE_FAILED CloudFormation error.

# Practical checklist

• Create and test the boundary policy in a development account before applying it broadly.
• Ensure the boundary allows iam:PassRole and sts:AssumeRole for the principals the blueprint needs to operate.
• Explicitly deny any DataZone or agent actions you want to block in the boundary.
• Use the AWS CLI to set the Tooling blueprint PermissionsBoundaryArn so the change applies at project creation.
• Verify each provisioned role has the boundary attached and that CloudFormation stacks for Tooling do not show iam:CreateRole denies.

# Result With PermissionsBoundaryArn configured on the Tooling blueprint, organizations that require boundaries can adopt SageMaker Unified Studio without changing SCPs. Administrators gain a single control point to scope what Tooling-created roles are allowed to do while preventing agent features or other actions that the boundary explicitly denies.