Immuta v2026.1 Release Notes

Immuta v2026.1.3

Immuta v2026.1.3 was released on March 23, 2026.

Bug fixes

• Trino connection fixes:

  • Object sync failed for an entire schema when Trino could list an object name, but could not return complete column metadata for that object.

  • Object sync failed with a PostgreSQL syntax error when the crawl encountered table names that contained single quotes.

• Data platform tiles were not appearing in the Immuta UI, preventing users from creating new data sources.

• Several UI elements for data sources were not loading in the Immuta UI, and running the high cardinality column health check for a data source caused errors.

Immuta v2026.1.2

Immuta v2026.1.2 was released on March 11, 2026.

Bug fixes

• Trino connection fix: When setting up a Trino connection for the first time, the connection creation showed a Could not get actions error on the Next Steps page. Although the connection was created in Immuta, the Trino configuration template (properties file, API key placeholders) was not generated, so users could not enable the Immuta access control plugin on their Trino cluster to complete the configuration.

• Deployment bug fix.

Immuta v2026.1.1

Installation issues

This patch release should not be installed because of a deployment bug. Instead, upgrade to 2026.1.2.

Immuta v2026.1.1 was released on March 6, 2026.

Bug fix

Trino connection fix: When setting up a Trino connection for the first time, the connection creation showed a Could not get actions error on the Next Steps page. Although the connection was created in Immuta, the Trino configuration template (properties file, API key placeholders) was not generated, so users could not enable the Immuta access control plugin on their Trino cluster to complete the configuration.

Immuta v2026.1.0

Immuta v2026.1.0 was released on February 13, 2026.

New features and enhancements

Data platform integrations

• Starburst (Trino) connections: Connections is Immuta’s enhanced way of efficient data object management that offers the following benefits:

  • Reduced complexity by having just one connection in Immuta for both metadata onboarding and policy application with your data platform.

  • Increased scalability by onboarding all your objects at once instead of repetitive patterns.

  • Improved performance to manage and track metadata changes.

  Connections can now be used with Starburst (Trino) integrations. Reach out to your Immuta representative to enable it. Once enabled, a banner will direct you to the upgrade manager where you can initiate the process to upgrade your existing integration.

• Performance improvement for Starburst (Trino) integration: Immuta has optimized policy calculations for our Starburst (Trino) integration. This is a back-end update that is released to all customers. These optimizations have led to performance improvements for Starburst (Trino) users who are not using Immuta projects. After releasing this enhancement, query times improved an average of 70% for users without an Immuta project set.

• OAuth support for Azure Synapse Analytics integration: Immuta now supports OAuth as an additional authentication method in the Azure Synapse Analytics integration. Users can configure an Azure Synapse Analytics integration in Immuta using OAuth with a client secret.

• Databricks Runtime 14.3 support: This update is only relevant to Databricks Spark customers, not customers using Unity Catalog. Immuta's Databricks Spark integration now supports Databricks Runtime 14.3. With this update, you can upgrade your Databricks environment while preserving Immuta’s core data governance capabilities.

• Databricks Unity Catalog integration validation improvements: Immuta has made backend improvements to the validations run that verify the health of Databricks Unity Catalog integrations. These improvements can result in significant cost savings. Your specific cost savings depends on how you've configured your Immuta and Databricks environments, such as your Databricks warehouse size and Immuta audit ingest interval.

• Configuring the permissions that Immuta revokes for Databricks Unity Catalog users: You can now configure whether or not Immuta revokes Immuta users’ USE_CATALOG and USE_SCHEMA permissions when users do not have access to any of the securables within that catalog or schema.

  • Previously, Immuta revoked USE_CATALOG and USE_SCHEMA from users that did not have access to any securable within a particular catalog or schema. Now, you can disable this default behavior.

  • When this setting is disabled, Immuta users who do not have access to any securables within a catalog or schema will keep their existing USE_CATALOG and USE_SCHEMA permissions. Updating this setting will not retroactively update existing user permissions; this change will be applied on a go-forward basis only.

  • See the App settings guide for instructions on configuring this setting.

Catalog integrations

• Manually link external catalogs on Amazon S3 data sources: Users can now manually link Amazon S3 data sources to an asset in an external catalog. Using this link, Immuta polls the external catalog to ingest and apply tags to each Amazon S3 data source. Immuta checks every 24 hours for any relevant metadata changes in the connected external catalog.

  The linked external catalog can be seen on the data source's detail page. The external catalog tags can be seen on the data source dictionary page. These tags can then be used to drive policies or classification frameworks.

• Integration with Atlan for seamless tag ingestion in Private Preview: Reach out to your Immuta representative to enable this feature. Immuta now offers a new, out-of-the-box standard connector designed to seamlessly integrate Immuta with the Atlan enterprise data catalog. This connector enables automated tag enrichment within Immuta, leveraging the rich metadata and tagging information managed within Atlan. By establishing a direct link between these two platforms, organizations can significantly streamline the process of applying consistent and comprehensive tags to their data assets within Immuta.

• Compatibility with Collibra’s data classification module: Immuta’s integration with Collibra enterprise data catalog now also supports ingestion of Collibra data classifications as column tags into Immuta. This allows customers that use the Collibra data classification module to leverage the resulting classifications for subscription or data policy authoring in Immuta. For example, you could use an Immuta masking policy to mask all columns by default if they were classified as sensitive by the Collibra data classification module.

• Collibra integration now supports the OAuth 2.0 authentication method: Immuta’s Collibra integration has added support for the OAuth 2.0 authentication method in addition to the supported username/password authentication method.

Governance

• Multi-tag dynamic domain assignment: You can now use multiple table tags to assign data sources to domains dynamically. Before, you could only pick one tag and every data source with that tag was assigned to a certain domain. This enhancement removes that limitation for table tags and connection tags.

  • Table tags example: If you have a data source tagged Finance and another data source tagged HR but you want both to belong to the Operations domain, you can configure the Operations domain with dynamic tag assignment and select both the Finance and the HR tags.

  • Connection tags example: If you have a catalog in Databricks and a database in Snowflake that both belong to the Customer 360 domain, you can leverage connection tags and select both the Databricks and Snowflake connection tags to assign data sources to the same domain.

  You can combine up to 100 tags through this mechanism.

• Advanced masking exceptions: Advanced masking exceptions allow data governors to consolidate complex masking matrices containing hundreds of rules into a single policy. The new advanced masking policy options in the global data policy builder allow you to create dynamic exception rules that let users see just a subset of sensitive columns in the clear instead of an all-or-nothing approach for granting access to restricted data, which would often be too broad and create a security risk. The two policies below illustrate how advanced masking exceptions transform a policy.

  • Basic masking exception (static): "Mask columns tagged sensitive except when a user is a member of group Finance or group HR."

    • Users that are either part of the Finance or HR department will always see all sensitive columns unmasked everywhere.

  • Advanced masking exception (dynamic): "Mask columns tagged sensitive for everyone except when columns are tagged with the department the user currently belongs to.”

    • Users that are part of the Finance or HR department will only see a subset of sensitive columns unmasked, depending on what has been cleared for use for their department.

    This dynamic approach helps you maintain a high security baseline without sacrificing business agility: global masking rules protect your organization from broad data leaks and advanced masking exceptions ensure that security doesn't become a bottleneck.

Behavior changes

• Improved query audit for Databricks Unity Catalog: Immuta’s Unity Catalog audit ingestion query now uses the system.query.history table from Databricks. This foundational change significantly improves the match rate between Unity Catalog query audit records and Immuta-managed data sources, delivering more accurate and valuable insights. There's now a better linkage between queries run in Unity Catalog and their associated data sources in the Immuta audit dashboards and reports, providing a clearer, more reliable picture of data access usage within Unity Catalog.

  • The following parameter is now populated: rowsProduced.

  • These parameters are no longer populated, as they are not available in the system.query.history table: userAgent, requestId, clientIp.

Update your Databricks Unity Catalog privileges prior to upgrading

If you are currently using Immuta's Databricks Unity Catalog audit feature without the required privileges for this change, you need to do one of the following actions:

• Grant your service principal the required privileges

• Disable audit ingest

If you do not complete either of these actions before the upgrade, the integration will have validation failures and updates will no longer be pushed from Immuta to Databricks. To fix the validation failures, complete either of the actions listed above.

• Support for Amazon Redshift datashares: Immuta can now govern Amazon Redshift datashares. Users can onboard and apply Immuta controls to Redshift datashares with the same workflows they are using for standard Redshift data sources today.

• Support for Databricks Delta Sharing as a recipient: Immuta’s support for subscription policies on shares from Databricks Delta Sharing is now enabled for all customers. This allows you to manage granting and revoking access to these securables safely and efficiently.

• Fine-grained access controls for Databricks Unity Catalog materialized views and streaming tables: Immuta supports row filtering and column masking on Unity Catalog materialized views and streaming tables. Since these securables now support Immuta subscription and data policies, you gain enhanced security and flexibility with consistent policy enforcement across your Unity Catalog ecosystem. Contact your Immuta representative to enable this feature.

• Updates to governance reports for subscription status: Improved performance by 10x for rendering the following governance reports:

  • What data sources are users subscribed to

  • What users and groups are subscribed to a data source

  Additionally, these reports include a new “Access Grant” column that denotes if a user has READ or WRITE access to a data source.

• API response change: A portion of the response for the GET /policy/global/{policyId} endpoint (which retrieves all global policies) has been changed. The syncStatuses field used to be a rollup of all relevant job statuses and their counts; now the field is a boolean:

  • Before

    {
      "syncStatuses": {
        "active": 2
      }
    }

  • After

    {
      "syncStatuses": true
    }

• Custom WHERE clause policies behavior change: Data policies that use custom WHERE functions that include a column name argument must now use @columnReference('Column_Name') to specify the data source column to use in the policy. The following data policy types are affected by this change:

  • Masking using a custom function (Mask columns tagged Discovered.PII using the custom function <custom where clause function>)

  • Masking policy conditions that use a custom function (Mask using hashing columns tagged Discovered.PII where <custom WHERE clause function>)

  • Row-level policies that use a custom function (Only show rows where <custom WHERE clause function>)

  This change makes it easier to author custom WHERE clause policies and ensures greater accuracy and reliability in policy application.

  Existing custom WHERE clause policies that reference column names and are applied to Snowflake and Databricks data sources have been automatically migrated to use the new @columnReference() format:

  • Before migration: Only show rows where 'Location'='US'

  • After migration: Only show rows where @columnReference('Location')='US'

• Improved logic for data source health status: Data source health status reporting has been improved for clarity and accuracy.

  • Previously, an Unhealthy data source could briefly appear as Healthy while a failed job was actively resyncing.

  • Now, data sources will remain Unhealthy until all resync jobs are complete. The data source health status is updated only after the resync finishes, which prevents false positive health statuses from being displayed during failed policy resyncs and eliminates confusion for users.

• Eliminated possibility of wrong Collibra assets being autolinked to Immuta data sources: Previously, if a data source was created in Immuta before it was present as an asset in Collibra, a fallback method could link the wrong Collibra asset to the data source in Immuta. This only happened in the rare case where Collibra assets with the same schema and table name already existed in Collibra at the time of the auto-linking attempt, but the correct target asset wasn’t present yet.

  Now, the Immuta catalog auto-linking method for Collibra will only attempt to auto-link Collibra assets using the fully qualified asset name following the Edge naming convention - eliminating the need for any fallback linking method. This guarantees an accurate match rate every time.

• The cleanup script for deleting a Snowflake integration or connection now removes Immuta policies and Immuta-managed roles from your Snowflake environment. This enhancement provides the following benefits:

  • Deletion of Immuta roles and policies happens in one place, which simplifies the cleanup process.

  • You have full control over cleanup actions when running the script.

  • You can better identify points of failure if any issues occur.

  • You can easily re-run the script as needed.

  This change applies to any Immuta Snowflake user running this script, regardless of whether or not you have migrated to using connections to register data or you still use the legacy integration method.

  For guidance on how to delete a Snowflake integration or connection, see the Edit or remove your Snowflake integration or Deregister a connection guide. Before running the script, ensure you are using the latest version downloaded from Immuta and not a legacy version you may have saved previously.

• Snowflake data policy impersonation: Reach out to your Immuta representative to enable this feature. Impersonation is now compatible with the most updated version of Immuta's Snowflake integration, which leverages low-row access policy mode for improved overall performance.

  With this update, impersonation is now available for data policy access only. Administrators can impersonate others to see the row- and column-level restrictions their users are subject to. When impersonating another user, the impersonator’s subscription policy access will remain unchanged.

• Security improvement to Immuta's webhook signature scheme: Reach out to your Immuta representative to enable this feature. Immuta is updating the webhook signature scheme to use HMAC-SHA256 instead of HMAC-SHA1. This change aligns Immuta with current cryptographic best practices and NIST guidance. The webhook payload format and shared secret remain unchanged; only the hashing algorithm used to generate the signature has been updated.

  • What is changing: Currently, Immuta sends a webhook signature signed with HMAC-SHA1 via the x-immuta-webhook-signature HTTP header. Immuta has begun sending an additional webhook signature signed with HMAC-SHA256 via a new HTTP header, x-immuta-webhook-signature-sha256. As of today, you are able to opt-in to stop receiving webhook signatures using HMAC-SHA1.

  • Impact to you: Customers that validate webhook signatures must ensure their verification logic supports HMAC-SHA256. No action is required for customers who do not perform signature validation.

  • Why this change: While HMAC-SHA1 has not been shown to be practically exploitable in this context, SHA-1 is deprecated and no longer recommended for new designs. This update is a proactive security-hardening measure.

Deprecations and removed features

Deprecated features

The following features are deprecated. They are still in the product but will be removed at their tentative EOL date.

Feature	Use this alternative feature	Deprecation notice	End of life (EOL)
Legacy onboarding for Starburst (Trino) integrations	Trino connections	2026.1	2026.2
Snowflake without low row access policy mode enabled	None	2026.1	2026.2
Snowflake without table grants	None	2026.1	2026.2
Snowflake project workspaces	None	2026.1	2026.2

Removed features

The following features have been fully removed from the product.

Feature	Use this alternative feature	Deprecation notice	End of Life (EOL)
CREATE_FILTER permission	None	2024.3	2026.1
Amazon Athena database support (through proxy connector)	AWS Lake Formation integration	2025.1	2026.1

v2026.1 migration note

You must be on Immuta version 2025.1 or newer to migrate directly to 2026.1.