How Databricks data security works with Unity Catalog, where its metastore-scoped model hits limits at scale, and how to enforce consistent policy across workspaces and platforms.
Databricks data security rests on Unity Catalog, which governs access to tables, files, models, and other assets through a three-level namespace and SQL-based grants. Unity Catalog handles governance well within a single metastore, but enterprises running Databricks across multiple workspaces, regions, or clouds need a layer above it to keep policy consistent and to extend governance into AI and ML workloads.
Unity Catalog organizes every governed asset under a metastore, the top-level container for a given cloud region. Beneath the metastore sits a three-level namespace of catalog, schema, and table, and every object in that hierarchy accepts grants:
GRANT SELECT ON TABLE finance.reporting.transactions TO `finance_analysts`;
Beyond table grants, Unity Catalog supports row filters (SQL functions that decide which rows a principal can see) and column masks (functions that return a redacted value based on the querying user’s identity). Both can be assigned per table, or centrally through ABAC policies that attach at the catalog or schema level and apply automatically to any table carrying a matching governed tag:
CREATE POLICY mask_pii ON CATALOG customer_data
COLUMN MASK governance.redact_email
FOR TABLES
MATCH COLUMNS has_tag_value('classification', 'pii') AS col
ON COLUMN col;
That single policy applies to every table in the catalog marked as PII without a steward reviewing or marking each individual table. ABAC is the more scalable path once an organization has more than a handful of tables to protect, since it separates policy authoring from per-table configuration, and it lets new tables inherit the right protection automatically as soon as they carry the matching tag.
Within a single metastore, Unity Catalog replaced the patchwork of workspace-level Hive metastores and third-party tools like Apache Ranger with one account-level grant model. Before Unity Catalog, most Databricks environments relied on workspace-scoped permissions that had to be recreated for every new workspace, with no shared view of who could access what across the organization.
Unity Catalog supports fine-grained access control down to the row and column level, automated audit logging of every query and grant change, and end-to-end lineage that tracks how a table’s data flows into downstream views, models, and dashboards. Its grant model is intuitive to anyone already familiar with SQL permissions, since a typical grant reads no differently than a standard ANSI SQL statement. For organizations building governance from scratch, or migrating off a legacy Hive metastore, Unity Catalog is a substantial improvement and the correct foundation to build on rather than work around.
Unity Catalog’s governance boundary is the metastore, and a metastore is scoped to a single cloud region. That has real consequences at scale:
None of this makes Unity Catalog weak within its boundary. It means the boundary, one metastore, one region, one platform, is narrower than most enterprise Databricks deployments actually are.
Unity Catalog gives Databricks strong native primitives scoped to a metastore. It does not give an enterprise a single place to author policy once and enforce it across every metastore, every cloud, and every other platform running alongside Databricks, including Snowflake and Power BI.
TrustAccess federates policy across Unity Catalog metastores, clouds, and platforms, enforcing runtime authorization natively rather than adding a proxy layer in front of the existing access path. It reads the structure of each Unity Catalog metastore an organization runs and enforces centrally authored policy as native grants, row filters, and ABAC policies inside each one, so a rule defined once applies consistently everywhere it needs to, across regions, clouds, and platforms.
TrustAI extends that same model into AI agent and MCP tool access, so a policy defined for a human analyst and one defined for an AI agent draw from the same source of truth rather than being governed by separate rules entirely. Posture without enforcement is just a better report. Detecting that a Databricks catalog has overprivileged roles or unmasked PII only matters if that finding becomes an enforced policy in Databricks’ own access control layer, not a remediation ticket waiting on a manual cycle. That is the gap TrustLogix closes, and it’s covered in more depth in TrustLogix’s AI data security guide.
Workspaces attached to the same metastore, typically in the same region, share one governance model automatically: a grant made once applies everywhere. Workspaces in different regions sit on different metastores entirely, and Unity Catalog has no built-in way to keep policy consistent between them. Workspace-catalog bindings can restrict which workspaces see a given catalog, but that’s a visibility boundary, not a policy engine, it determines what a workspace can see, not what a user can do once they’re in it.
In practice, cross-region consistency means either an admin team manually replicating every grant, row filter, and ABAC policy across each metastore and watching for drift every time a rule changes in one region and not the others, or introducing a layer that authors policy once and pushes it down natively into each one, which is the approach TrustAccess takes above.
Unity Catalog is Databricks’ account-level governance for data and AI assets. It organizes tables, views, volumes, models, and functions under a metastore using a catalog.schema.object namespace, enforced through ANSI SQL grants, row filters, and column masks.
Unity Catalog centralizes governance for every Databricks workspace attached to a given metastore. It defines access through ANSI SQL grants on catalogs, schemas, and tables, filters the rows a principal sees through row filter functions, and redacts column values through column mask functions, either assigned individually or applied at scale through tag-based ABAC policies. Alongside access control, it maintains automated audit logging of every grant and query, and end-to-end lineage showing how data flows from a source table into downstream views, models, and dashboards.
Unity Catalog does not extend past its own metastore boundary. A metastore is scoped to a single cloud region, so multi-region deployments require a separate metastore per region, each maintaining its own catalogs and grants independently. It also does not govern data outside Databricks, or data once it has been copied into a training set, a feature store, or a vector store built for a RAG pipeline. Row filters and column masks assigned per table also require manual configuration unless ABAC and consistent tagging discipline are already in place.
Workspaces on the same metastore share one governance model automatically, since a grant applies to every workspace attached to it. Workspaces on different metastores, which is the case whenever they sit in different regions, don’t share anything by default. Keeping policy consistent between them means either manually replicating every grant and policy or introducing a layer above Unity Catalog that authors policy once and pushes it into each metastore natively.
Unity Catalog has no visibility into other platforms, which means most enterprises running Databricks alongside Snowflake or BigQuery, the common case rather than the exception, are managing disconnected governance models with different grant syntaxes, different masking mechanisms, and no shared audit trail between them. TrustAccess federates policy across Unity Catalog and these other platforms rather than replacing Unity Catalog’s native enforcement, pushing a single policy down as a native grant in Databricks and a native RBAC role or masking policy in Snowflake at the same time.
Sensitive data reaches a Databricks ML pipeline through three paths: the raw tables feeding a feature store, the training datasets assembled from those features, and the documents or embeddings pulled into a RAG pipeline’s vector store. Table-level protections don’t travel with the data once it’s copied into any of these.
It’s common for a feature engineering job to pull in more columns than a model actually needs, simply because they were available in the source table. National ID numbers, account numbers, health information, and free-text fields containing names or addresses all end up in feature tables far more often than data teams realize, especially in fast-moving ML environments where a notebook can grant broad SELECT access for convenience during experimentation, and that access is never revisited once the model ships to production.
The safest pattern masks or tokenizes sensitive fields before they enter a training pipeline, rather than relying on downstream controls to catch them later. A column mask applied to the source table, or a transformation step in the feature engineering pipeline itself, should strip or redact fields like names, national ID numbers, or account identifiers before a training job ever reads them:
raw table (row filter + column mask applied)
-> feature store (masked fields only)
-> training job -> model registry
Mask as close to the source as possible. Every step downstream of an unmasked read is a place the original value can leak into a feature table, a training set, or a log file, and remediating after the fact means finding and fixing every copy rather than preventing the exposure in the first place.
A model trained on masked data can still leak information at inference if the serving endpoint has broader access than the training job did, or if prompts and responses aren’t access-controlled like a query against a governed table. This matters more than it first appears, since a model endpoint is effectively a new access path into whatever data informed its outputs, and that path rarely gets the same grant review as a table does. Inference access needs the same rigor as training data: who can call the endpoint, what data informed the response it returned, and a durable audit trail tying each call back to the model and the underlying data.
A vector store built from a governed table does not inherit that table’s row filters or column masks, since embedding reads the table once at build time with no ongoing tie back to the source policy. If the source documents contain PII, that content persists in the embeddings unless it was masked first, and a broadly scoped RAG pipeline can return sensitive content to a user or an AI agent that never had table-level access to it.
TrustAI extends governance into the AI layer itself, applying masking and access policy from the source table through the feature store, the model, and inference, including RAG and vector store access, so the same policy governing a table in Unity Catalog governs what an AI agent can retrieve from it downstream.
Both platforms have mature native security models, and most enterprises with a serious Databricks footprint run Snowflake too, which makes this less about choosing one and more about governing both consistently.
CapabilityDatabricks (Unity Catalog)SnowflakeAccess modelSQL grants on catalog.schema.tableRBAC with SQL grantsRow-level securityRow filter functions or ABACRow access policiesColumn maskingColumn mask functions or ABACDynamic data maskingGovernance scopeSingle metastore, per regionSingle account, spans regionsAuditNative lineage and audit logsQuery and access historyCross-platform viewNone nativelyNone natively
Snowflake’s access control is built around role-based access control from the ground up: roles are granted privileges, roles are granted to other roles in a hierarchy, and users are granted roles. Unity Catalog’s model applies ANSI SQL grants more directly to groups on securable objects, without a dedicated role hierarchy, though groups can be structured to approximate the same effect. A team moving between the two platforms needs to translate Snowflake’s role hierarchy into Databricks’ group-and-grant structure, since the two aren’t a direct one-to-one mapping.
Databricks implements row-level security through row filter functions, SQL user-defined functions attached to a table that evaluate each row and return a boolean, or through ABAC policies that apply the same logic across every table carrying a matching tag. Snowflake’s equivalent is row access policies, which similarly evaluate a SQL expression per row and can be applied at the table level or managed centrally. Functionally, the two approaches solve the same problem: neither platform requires exposing unfiltered data and relying on the application layer to filter it after the fact.
Databricks uses column mask functions, SQL UDFs that return a redacted or transformed value based on the querying user’s identity or group membership, either assigned per column or applied at scale through ABAC. Snowflake’s dynamic data masking policies work on the same principle: a masking policy is defined once and attached to a column, and the platform evaluates it at query time based on the current role. Both platforms support conditional masking, for example showing the last four digits of a national ID number to one role and the full value to another, so this is closer to a difference in syntax and tooling than a difference in capability.
Unity Catalog provides native lineage tracking and audit logging of grants, queries, and access changes within its metastore. Snowflake provides query history and access history natively within an account. Both are strong within their own platform boundary, and both stop at that boundary. Neither gives a compliance team a single combined view of who accessed what across both platforms, which is a real gap for regulated industries where an auditor’s question rarely respects a vendor boundary.
The genuine differences between the two platforms are in tag systems, SQL syntax, multi-cloud posture (a Snowflake account can span multiple cloud regions more flexibly than a single Databricks account, which is tied to one cloud provider), and the maturity of each platform’s native tooling for managing policy at scale. Neither platform’s security model is meaningfully weaker than the other’s.
Most enterprises run both because the platforms serve different workloads well, Databricks for ML, AI, and unstructured data, Snowflake for structured analytics and BI, not because one security model beat the other. Neither one governs the other, and neither governs a downstream AI agent or MCP tool querying data pulled from both.
That shared limitation is the case for a unifying control plane. TrustAccess authors policy once and enforces it natively inside each platform’s own access control layer, translating a single rule into a Unity Catalog grant on one side and a Snowflake RBAC role or masking policy on the other, keeping runtime authorization consistent without requiring either team to change how they already work day to day.
Enterprises running Databricks alongside Snowflake, across multiple clouds, or with AI workloads reading from governed tables face the same problem: strong native controls that stop at each platform’s boundary. Architect a unified Databricks + Snowflake governance model with TrustLogix.