Amazon SageMaker adds permissions boundaries for SCP compliance
Enterprises blocked by SCP guardrails can now adopt SageMaker Unified Studio without compromising IAM governance — boundaries apply automatically to every new project.
View original announcement →Visual Summary
graph TD
A{{Permissions Boundaries for SCP}}:::announced
B(SageMaker Unified Studio):::compute
C([Tooling Blueprint Config]):::feature
D([Project User Role]):::feature
E([Bedrock Service Role]):::feature
F([Bedrock Lambda Role]):::feature
G((Administrator)):::external
H(AWS Organizations SCPs):::compute
I((Project Creator)):::external
G ==>|"configures"| C
C ==>|"applies boundary"| A
I -->|"creates project"| B
B -->|"provisions"| D
B -->|"provisions"| E
B -->|"provisions"| F
A -->|"attaches to"| D
A -->|"attaches to"| E
A -->|"attaches to"| F
H -.->|"validates compliance"| A
classDef announced fill:#ff9900,stroke:#ec7211,color:#fff,font-weight:bold
classDef compute fill:#e3f2fd,stroke:#1565c0,color:#1565c0
classDef storage fill:#e8f5e9,stroke:#2e7d32,color:#2e7d32
classDef feature fill:#fff3e0,stroke:#e65100,color:#e65100
classDef external fill:#f5f5f5,stroke:#616161,color:#616161
What's New
Amazon SageMaker Unified Studio now supports custom IAM permissions boundaries, enabling organizations with strict Service Control Policies (SCPs) to adopt the platform without relaxing their existing security controls. Administrators can configure a permissions boundary once at the Tooling blueprint level, and it is automatically applied to all three IAM roles provisioned when a new project is created — the project user role, the Amazon Bedrock service role, and the Bedrock Lambda execution role. This eliminates the need for manual administrator intervention during project provisioning while ensuring continuous SCP compliance.
How It Works
- Blueprint-level configuration: Administrators specify a custom IAM permissions boundary as a parameter in the Tooling blueprint configuration via the SageMaker management console (accessed through the DataZone console endpoint).
- Automatic role attachment: When a user creates a new project, SageMaker Unified Studio automatically provisions three IAM roles — the project user role, Amazon Bedrock service role, and Bedrock Lambda execution role — each with the configured permissions boundary attached at creation time.
- SCP satisfaction at creation: Because the permissions boundary is attached during role creation (not after), the provisioning process satisfies SCP requirements that mandate all IAM roles carry a permissions boundary, preventing policy evaluation failures.
- Effective permission scoping: The permissions boundary acts as a guardrail, capping the maximum permissions any of the three provisioned roles can exercise, regardless of what identity-based policies are later attached to them.
- Universal project coverage: Since the boundary is set at the blueprint level, it propagates automatically to every subsequent project created under that blueprint — no per-project configuration is required.
- Console-driven management: The parameter is managed through the Project profiles → Tooling configuration → Blueprint parameters workflow in the SageMaker/DataZone console, with an option to mark it as editable or locked during project creation.
Why It's Important
- Unblocks enterprise adoption: Many large organizations enforce SCPs that reject IAM role creation without a permissions boundary; previously, this would cause SageMaker Unified Studio project provisioning to fail, making the platform unusable without policy exceptions.
- Zero security posture compromise: Organizations no longer need to create SCP exemptions or loosen guardrails to accommodate SageMaker Unified Studio, preserving their existing compliance and governance frameworks.
- Eliminates operational friction: Without this feature, each failed project provisioning would require administrator intervention to manually attach boundaries or grant exceptions — a significant operational burden at scale.
- Consistent least-privilege enforcement: The permissions boundary provides a hard ceiling on what provisioned roles can do, reinforcing least-privilege principles across all AI/ML projects automatically.
- Scalable governance: As teams self-service new projects, the boundary is enforced uniformly without relying on individual developers or project owners to configure security settings correctly.
- Audit and compliance simplification: Security and compliance teams gain confidence that every project-level IAM role is bounded, making audit evidence collection straightforward and predictable.
How It's Different
- Pre-existing gap: Prior to this launch, SageMaker Unified Studio had no mechanism to attach permissions boundaries to the roles it provisioned, making it incompatible with a common enterprise SCP pattern without policy workarounds.
- Blueprint-level vs. per-project configuration: The boundary is configured once at the blueprint level rather than requiring administrators to intervene on each individual project, which is a more scalable and less error-prone approach than manual or per-project remediation.
- Creation-time compliance: The boundary is attached at role creation time, not retroactively, which is the only approach that satisfies SCPs that evaluate role creation API calls (e.g.,
iam:CreateRole) for the presence of a boundary. - Covers all provisioned roles: The feature applies the same boundary to all three roles created per project (user, Bedrock service, Lambda execution), ensuring no role escapes the governance control — unlike partial solutions that might only cover one role type.
- No custom automation required: Previously, customers would need custom Lambda functions, AWS Config rules, or CloudFormation hooks to enforce boundaries post-creation; this native integration removes that operational overhead entirely.
When to Prefer It
- SCP-enforced environments: Use this feature whenever your AWS Organization has an SCP that includes a condition requiring
iam:PermissionsBoundaryon alliam:CreateRolecalls, which is a common pattern in regulated industries and large enterprises. - Regulated industry deployments: Organizations in financial services, healthcare, government, or other regulated sectors that mandate strict IAM governance should enable this to meet compliance requirements without creating policy exceptions.
- Multi-team or self-service ML platforms: When multiple teams are empowered to create their own SageMaker Unified Studio projects, the blueprint-level boundary ensures governance is applied consistently without central administrator involvement per project.
- Zero-trust or defense-in-depth architectures: Environments that layer multiple IAM controls (SCPs, permission boundaries, resource policies) benefit from this as an additional guardrail limiting the blast radius of any misconfigured project role.
- Accelerating SageMaker Unified Studio rollout: If your organization has been delaying adoption of SageMaker Unified Studio specifically due to SCP incompatibility, this feature directly removes that blocker and enables immediate onboarding.
- Audit-ready environments: When your security team requires documented proof that all IAM roles are bounded, configuring this at the blueprint level provides a single, auditable control point rather than scattered per-role evidence.
Availability
- GA Status: Generally Available (GA) as of June 1, 2026; no preview or beta designation indicated.
- Supported Regions: Available in all 15 regions where SageMaker Unified Studio is supported: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Europe (London), Europe (Paris), Europe (Stockholm), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Mumbai), South America (São Paulo), and Canada (Central).
- Pricing: No additional charge for this feature; standard SageMaker Unified Studio and IAM pricing applies.
- Configuration scope: The permissions boundary applies only to new projects created after the blueprint parameter is set; existing project roles are not retroactively updated.
- Prerequisite: The permissions boundary IAM policy must already exist in the account before it can be referenced in the Tooling blueprint configuration.
