Unified Lakehouse Policy: Write Once, Govern Everywhere

Apache Iceberg enables you to write once and query anywhere. It doesn't give you one set of rules to govern it. TrustAccess does.

The Governance Gap Nobody Sees Until It's Too Late

The AI-ready lakehouse runs on a simple premise: one copy of data, many engines querying it. Apache Iceberg made that possible: Snowflake, Databricks, Dremio, and many others can all read the same table from the same lakehouse.

Most enterprises today rarely rely on a single ecosystem. They run multiple data platforms and storage engines across cloud and on-prem environments to serve different business units. 

While Iceberg successfully acts as a universal translator allowing various platforms to query the same underlying data, the governance layer wasn't part of that bargain. Each engine registers the Iceberg table in its own catalog and enforces access through its own policy model. The data is unified but. the governance is not.

Consider a global financial services firm - Snowflake for finance dashboards, Databricks for risk modelling, Dremio for operations - all reading the same Iceberg tables on the same lakehouse. Their governance story starts reasonably: policies defined in each engine, teams trained on each system. Then the cracks appear.

• Access controls don't cross engine boundaries. The HR team builds a manager-hierarchy rule in Snowflake - only a manager sees their direct reports' compensation. It works. Then the risk modelling team runs a workforce analysis from Databricks against the same table. Unity Catalog has no record of that rule. Every compensation record is fully visible. No one flagged it. No one knew.
• Sensitivity classifications don't travel with the data. Legal tags the yield dataset as Export Controlled in Snowflake's catalog, driving column-level masking for unauthorized roles. The operations team pulls the same dataset from Dremio to build a supplier report. Dremio's catalog has no record of that tag. The restricted columns come back unmasked. The classification existed. It didn't follow the data.
• Business rules must be rebuilt everywhere - and they drift. A new regulatory requirement lands. The compliance team updates the row filter in Snowflake. They filed a ticket for Databricks. Dremio is on a different team's backlog. Three weeks later, the Snowflake policy reflects the new rule. The others don't. No one knows which engine to trust.
• Audit trails fracture across systems. The regulator asks: who accessed sensitive employee and financial data in the last 90 days, from which engine, under which policy? The answer requires pulling Snowflake Access History, Unity Catalog logs, and Dremio audit feeds - three schemas, three identity models, no common key. The compliance team spends weeks on reconciliation and still can't confirm whether a Databricks user and a Snowflake user with different usernames are the same person.

The result: one dataset, many policy silos, and zero consistency, creating a governance posture that looks sound until it is tested.

Three Bad Workarounds - And Why None of Them Work

Security teams facing this gap tend to land on one of three options. None of them hold.

• Duplicate policies per engine. Recreate every rule in Snowflake, Databricks, and Dremio separately. In practice, a single policy change requires coordinated updates across teams - often in different time zones - averaging 3 to 4 hours per change cycle. Every cycle is a window for drift. Every drift is a compliance exposure.
• Maintain filtered data copies. Create a pre-masked version of each sensitive dataset per engine. ETL overhead, storage waste, and silent staleness. When the source changes, the copies lag. When the copies lag, teams make decisions on stale data - or worse, on unmasked data that was never refreshed.
• Grant open access. Broaden permissions to prevent pipeline failures. Fastest path to keeping the business running. Also the fastest path to your next breach or audit finding.

All three trade one risk for another. And yet, under deadline pressure, teams keep reaching for them - because until now there hasn't been a structural alternative.

The Fix: Unified Iceberg Governance, Zero Copy

Every engine - regardless of its catalog - reads the same Iceberg table at the same location on the lakehouse. That shared physical identity is the right anchor for enforcement, not any engine-specific abstraction layered on top of it.

TrustAccess turns that insight into a control plane. It reads each engine's catalog registrations and groups them by their shared physical identity on the lakehouse - the same underlying table path that all engines point to. From that, TrustAccess maintains a Unified Inventory of every Iceberg table across all catalog registrations: one logical entity, regardless of how many engines have registered it.

Authors then define a Unified Policy once against that logical entity - row filters, column masks, attribute-based conditions, hierarchical scopes, classification tags. TrustAccess automatically translates and pushes those rules into each engine's native enforcement format. No data is moved or copied. Policies execute natively inside each engine at query time.

• Snowflake → Row Access Policies + Dynamic Data Masking
• Databricks → Unity Catalog row filters + column masks
• Microsoft Fabric → Power BI + OneLake security
• Dremio → native row filters + column masks
• Any new engine → connection, not a rewrite

What This Looks Like in Practice

That same financial services firm - the one spending 3 to 4 hours per policy change, the one that couldn't answer the regulator's question - runs TrustAccess across the same lakehouse.

The manager-hierarchy rule for compensation data is defined once as a Unified Policy. It reaches Databricks the moment it's authored. The Export Controlled tag on the yield dataset propagates to Dremio's catalog automatically. When the regulatory requirement changes, one update goes everywhere in under 5 minutes. And when the regulator asks their question again, there is one audit trail - canonical identities, every engine, every query, every policy outcome - ready in minutes.

The entire access matrix - jurisdictional restrictions, role-based controls, column masks, audit flags - is defined once against the Unified Inventory and enforced natively across all engines simultaneously.

See how TrustAccess maps to your stack → trustaccess.  

The Bottom Line

‍

Governance needs to match - unified, automatic, and engine-agnostic. TrustDSPM and TrustAI extend the same fabric to data security posture and AI workloads.

Data leaders shouldn't have to choose between openness and security. As Snowflake recently emphasized regarding the evolution of the open lakehouse, true flexibility requires a framework where security and governance are never compromised for interoperability. With TrustLogix, data teams can confidently embrace open architectures without compromising security.

See it live at Snowflake Summit Booth #: 2406 - watch your governance gap close across every engine in your stack in 15 minutes. Then let's talk about your architecture. Schedule an in person demo.