SageMaker notebook TIP covers 2 of 5 engines, 3 flag names and a 23 July 2025 project cliff

Summary. On 19 August 2026 AWS announced that Amazon SageMaker notebooks support trusted identity propagation (TIP) with Amazon Athena, Amazon Redshift and Amazon EMR Serverless, and said identity propagates "with no extra login, token, or role management required". The documentation disagrees with that sentence in four ways. The SageMaker Unified Studio administrator guide dates domain support to 30 September 2025 and names five engines; the user guide page for using a TIP project names two. The blueprint parameter you must set appears as enableTrustedIdentityPropagationPermissions, enableTIPPermissions and enableTrustedIdentityPropagation across three pages of the same documentation set. Projects created before 23 July 2025 are excluded even inside a TIP-enabled domain. And turning TIP on for an Amazon EMR on EC2 cluster requires an administrator to attach an inline policy carrying sso-oauth:CreateTokenWithIAM to the instance profile role, which is role management by any reading.

None of that makes the feature bad. It makes the rollout plan longer than the announcement implies, and it means at least one engine in a typical notebook will quietly fall back to a shared execution role while the console tells the user that authorization is identity-based.

What actually shipped

The AWS What's New entry says notebook users get per-user access control because "each notebook user's IAM Identity Center identity flows through to AWS Lake Formation, ensuring they see only the tables, columns, and rows their permissions allow, without sharing a single broad execution role."

That is the value. Before this, every notebook in a project queried through one execution role, so Lake Formation could not tell two analysts apart and CloudTrail attributed both to the same principal. TIP replaces the shared role with the caller's IAM Identity Center identity, and CloudTrail records which user read what.

The gap is scope. The administrator guide TIP page states that from 30 September 2025 SageMaker Unified Studio supports TIP "for tasks that include Amazon Athena, Amazon Redshift, AWS Glue, Amazon EMR on EC2, and Amazon EMR Serverless". Five engines. The same page closes with a narrower statement: notebooks support TIP for SQL analytics on Athena and Redshift and interactive Spark on EMR Serverless, and "AWS Glue and Amazon EMR on EC2 do not support trusted identity propagation from notebooks. These services use compatibility permission mode for data access instead."

Compatibility permission mode is the old shared-role path. So on a domain where an administrator has enabled TIP, a notebook that switches its Spark runtime from EMR Serverless to Glue changes its data authorization model without changing a line of code.

Five, three, or two engines

The third count comes from the user guide. Using a project with trusted identity propagation enabled opens with "Currently in Amazon SageMaker Unified Studio, you can use trusted identity propagation in the following use cases" and then lists exactly two: Athena queries under SSO credentials, and connections to existing Redshift provisioned clusters or Redshift Serverless endpoints that are IAM Identity Center enabled. EMR Serverless does not appear on that page at all.

The Spark Connect page settles the Spark half of this. The notebooks Spark Connect documentation lists, under the Glue runtime limitations, "Trusted identity propagation (TIP) is not supported", and under EMR on EC2, "Fine-grained access control and trusted identity propagation are not supported. Only compatibility permission mode is supported for EMR on EC2 with Spark Connect." For EMR Serverless it lists prerequisites instead: an application on release label emr-7.13.0 or above, interactive sessions enabled, and "compatibility permission mode or trusted identity propagation mode".

The same page carries a troubleshooting instruction that reads oddly next to the announcement. If an EMR Serverless connection does not appear in an IAM domain, one of the things to verify is that "the domain does not have trusted identity propagation enabled".

Three names for one parameter

The administrator guide tells you to open the project profile, edit the default Tooling blueprint, and set enableTrustedIdentityPropagationPermissions to True, optionally clearing the Editable checkbox so project owners cannot override it.

The user guide, on the page describing how to create a TIP project, tells you to "select a project profile that has configured/set enableTIPPermissions to true".

A limitation bullet on that same user guide page refers to "setting enableTrustedIdentityPropagation to true on an existing project".

Three strings, one setting, two guides. Only one of them is the parameter the console shows. Treat the administrator guide spelling as authoritative, because it is the page that walks through the console form, and expect any infrastructure-as-code or runbook copied from the user guide to fail silently rather than error.

Two date cliffs, not one

Domain age is the cliff most teams will hit first. Domains created before 30 September 2025 do not get TIP automatically; an administrator has to open the domain details page, find the update notification banner and choose Update now. New domains created after that date need no action.

The second cliff is undocumented in the announcement and harder to work around. The user guide states that TIP "is only supported for projects that are created starting with 07/23/2025 and beyond. Trusted identity propagation is NOT supported for projects that were created prior to 07/23/2025 even if they live in a domain that has trusted identity propagation enabled."

There is no migration path on that page. An analytics team that stood up its projects in the first half of 2025 has to create new projects and move work into them, and the Athena limitation confirms it: there is only one Athena connection per project by design, and setting the flag on an existing project "does not create a new blueprint that can authorize on trusted identity propagation credentials".

What a TIP project gives up

Enabling TIP is not a pure addition. The user guide lists what stops working inside a TIP-enabled project:

• The default project database, which grants access by project role, no longer appears in the query editor's data explorer.

• Users cannot subscribe to or publish data products using SSO credentials through TIP. The documented workaround is to keep a separate non-TIP project for the catalog and subscription workflow.

• There is no default Redshift connection. Someone has to create one explicitly and pick IAM Identity Center under Authentication.

• In JupyterLab, Visual ETL and other tools where Athena is used but TIP is not supported, the data explorer shows the default project database and authorizes by project role.

That last bullet is the one to plan around. The same domain, the same user, two different authorization models depending on which surface the query is typed into.

The boundaries Identity Center will not cross

The Lake Formation IAM Identity Center limitations page adds three more that matter for a governance design. IdC users and groups cannot be assigned as data lake administrators or read-only administrators. They can only invoke API operations listed in the AWSIAMIdentityCenterAllowListForIdentityContext policy. And a cross-account grant attempt returns the error "Cross-account grants are not supported for the principal."

One more setting deserves attention because it changes behaviour permanently. Lake Formation sets the IdC application assignment configuration to false by default. If you change it through the Identity Center PutApplicationAssignmentConfiguration API, you then have to manage every application assignment manually, and Lake Formation will not synchronise assignments made outside its own workflows.

Where "no role management" breaks

The clearest contradiction of the announcement's phrasing is the EMR on EC2 TIP configuration page. To enable TIP for a cluster, an administrator who can edit IAM policies in the account that owns the project has to attach an inline policy to the cluster's instance profile role granting sso-oauth:CreateTokenWithIAM, sso-oauth:IntrospectTokenWithIAM and sso-oauth:RevokeTokenWithIAM on all resources, plus sts:AssumeRole on the instance profile role's own ARN. The page also notes TIP is supported only for EMR on EC2 clusters created through SageMaker Unified Studio.

Upstream of all of it, Lake Formation's prerequisites for Identity Center integration require IdC enabled, an identity source chosen (the built-in directory, Microsoft Entra ID or Okta), and an IAM role holding lakeformation:CreateLakeFormationIdentityCenterConfiguration, sso:CreateApplication, sso:PutApplicationAuthenticationMethod and sso:PutApplicationAccessScope. The end state removes per-user role sprawl. Getting there is a role-management project.

Sizing the rollout

SageMaker Unified Studio's quotas page puts hard ceilings on the "create new projects" migration path: 1,000 projects per account, 6,000 spaces, 4,000 JupyterLab instances, 1,000 environments and 200 micro environments. Membership caps are tighter and per project: 100 user-type members and 20 group-type members. The page states these are account-level, so exhausting them in one project affects every other project in the account.

If your migration plan is "clone every pre-23 July 2025 project", count the projects first. The group-member cap of 20 is the one that bites large domains, because the natural TIP design is to grant Lake Formation permissions to IdC groups rather than individuals.

India-specific considerations

For teams operating under the Digital Personal Data Protection Act 2023, the attribution half of this release is the useful part: CloudTrail records the individual IdC identity behind each query, which supports the access-log evidence a data fiduciary needs. The Region constraint is the complication. Because IAM Identity Center does not support TIP across Regions, an organisation running its analytics estate in Asia Pacific (Mumbai) needs its IdC instance in the same account and Region as the SageMaker domain, and a second Region means a second design rather than an extension of the first. Encrypted Data Catalog resources add a second constraint: AWS managed keys do not support TIP, so a customer managed key and an assumable AWS Glue role are prerequisites, not options.

What is still unknown

AWS has not published a migration path for projects created before 23 July 2025, and the documentation does not say whether the restriction is a data-plane limit or a metadata flag that a future release could set. There is no stated timeline for TIP from notebooks on AWS Glue or EMR on EC2. And the three parameter spellings are unresolved: only one can be right, and the docs do not say which page is stale.

FAQ

How eCorpIT can help

Turning this on across an existing analytics estate is an identity and cataloguing project before it is a notebook change: auditing which projects predate 23 July 2025, deciding which engines can carry per-user authorization, and rebuilding Lake Formation grants against IdC groups inside the 20-group-per-project cap. Our data platform engineering teams do that migration work, and it usually pairs with the wider AWS IAM policy limits and IAM role manager defaults review that most accounts need at the same time. If your Spark runtime choice also changed with AWS Glue 6.0, do both reviews together. To scope it, contact our AWS data engineering team.

References

1. Amazon SageMaker notebooks now support trusted identity propagation, AWS What's New, 19 August 2026

1. Trusted identity propagation, Amazon SageMaker Unified Studio Administrator Guide

1. Using a project with trusted identity propagation enabled, Amazon SageMaker Unified Studio User Guide

1. Configuring trusted identity propagation for EMR on EC2, Amazon SageMaker Unified Studio User Guide

1. Use Spark Connect in notebooks, Amazon SageMaker Unified Studio User Guide

1. Quotas and limits for Amazon SageMaker Unified Studio

1. IAM Identity Center integration limitations, AWS Lake Formation Developer Guide

1. Prerequisites for IAM Identity Center integration with Lake Formation

1. Integrating IAM Identity Center, AWS Lake Formation Developer Guide

1. Hybrid access mode, AWS Lake Formation Developer Guide

1. Machine learning in Identity Center-based domains, Amazon SageMaker Unified Studio Administrator Guide

Last updated: 22 August 2026.