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.
| Engine | Domain-level TIP (admin guide) | TIP from a notebook | Fallback if not |
|---|---|---|---|
| Amazon Athena | Supported | Supported | n/a |
| Amazon Redshift | Supported | Supported | n/a |
| Amazon EMR Serverless | Supported | Supported, Spark Connect only | Compatibility permission mode |
| AWS Glue | Supported | Not supported | Compatibility permission mode |
| Amazon EMR on EC2 | Supported | Not supported | Compatibility permission mode |
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
| Constraint | Where it is stated | What it blocks |
|---|---|---|
| Project and Redshift cluster must be in the same AWS account | SageMaker user guide, TIP page | Cross-account Redshift under SSO identity |
| IAM Identity Center instance and the SageMaker domain must be in the same account | SageMaker user guide, TIP page | Delegated-admin IdC topologies |
| IdC does not support TIP across Regions | SageMaker user guide, TIP page | Multi-Region analytics on one identity |
| Cross-account Lake Formation grants to IdC principals fail | Lake Formation limitations page | Central catalog, spoke consumers |
| AWS managed keys do not support TIP | Lake Formation limitations page | Encrypted catalogs on default KMS keys |
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
What did AWS announce for SageMaker notebooks on 19 August 2026?
AWS announced trusted identity propagation for Amazon SageMaker notebooks with Amazon Athena, Amazon Redshift and Amazon EMR Serverless. Each notebook user's IAM Identity Center identity reaches AWS Lake Formation, so table, column and row permissions apply per user instead of through one shared project execution role.
Which engines actually support TIP from a notebook?
The administrator guide names Athena and Redshift for SQL analytics and EMR Serverless for interactive Spark. AWS Glue and Amazon EMR on EC2 do not support trusted identity propagation from notebooks and fall back to compatibility permission mode, which is the shared execution role behaviour TIP was meant to replace.
Why does the user guide list only two engines?
The user guide page for using a TIP-enabled project documents two use cases, Athena and Redshift, and does not mention EMR Serverless. The administrator guide lists five engines at domain level and three from a notebook. The pages have not been reconciled, so treat the administrator guide as the current scope.
Can I enable TIP on an existing SageMaker project?
No. The user guide states trusted identity propagation is supported only for projects created on or after 23 July 2025, and is not supported for older projects even inside a TIP-enabled domain. Setting the flag on an existing project does not create a blueprint that can authorize on propagated credentials.
What is the blueprint parameter called?
Three names appear across the documentation: enableTrustedIdentityPropagationPermissions in the administrator guide, enableTIPPermissions in the user guide project page, and enableTrustedIdentityPropagation in a limitation bullet. The administrator guide spelling matches the console form, so use that one and expect copied runbooks to fail quietly.
Does turning on TIP really need no role management?
Not for every engine. Enabling TIP on an Amazon EMR on EC2 cluster requires an administrator to attach an inline policy to the cluster instance profile role granting three sso-oauth actions plus sts:AssumeRole on that role's own ARN. Lake Formation integration also needs its own IAM role and permissions.
What stops working inside a TIP-enabled project?
The default project database disappears from the query editor's data explorer, and users cannot subscribe to or publish data products using SSO credentials through TIP. The documented workaround is a separate non-TIP project for catalog and subscription work. Redshift also has no default connection in a TIP project.
Does TIP work across accounts or Regions?
No. The SageMaker project and the Redshift cluster must be in the same AWS account, the IAM Identity Center instance must be in the same account as the domain, and Identity Center does not support trusted identity propagation across Regions. Lake Formation also rejects cross-account grants to Identity Center principals.
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
- Amazon SageMaker notebooks now support trusted identity propagation, AWS What's New, 19 August 2026
- Trusted identity propagation, Amazon SageMaker Unified Studio Administrator Guide
- Using a project with trusted identity propagation enabled, Amazon SageMaker Unified Studio User Guide
- Configuring trusted identity propagation for EMR on EC2, Amazon SageMaker Unified Studio User Guide
- Use Spark Connect in notebooks, Amazon SageMaker Unified Studio User Guide
- Quotas and limits for Amazon SageMaker Unified Studio
- IAM Identity Center integration limitations, AWS Lake Formation Developer Guide
- Prerequisites for IAM Identity Center integration with Lake Formation
- Integrating IAM Identity Center, AWS Lake Formation Developer Guide
- Hybrid access mode, AWS Lake Formation Developer Guide
- Machine learning in Identity Center-based domains, Amazon SageMaker Unified Studio Administrator Guide
Last updated: 22 August 2026.
Top comments (0)