What is fine-grained access control for data, and how does it work?

Summary

• Fine-grained access control means governing data below the level of a whole table, down to specific rows and columns, and deciding which identities can read or change what, enforced wherever the data is queried.
• A complete model pairs role-based access control (RBAC) for the baseline of who can touch which objects with attribute-based access control (ABAC), row filters, and column masks for what rows and values each user actually sees.
• The most durable enforcement happens at the query engine, so a notebook, BI tool, Genie, or agent all get the same rules and no application can route around them.
• Databricks Unity Catalog uses ANSI SQL GRANT and REVOKE across a catalog, schema, table, and column hierarchy with inheritance, plus ABAC policies driven by governed tags that apply one rule across many tables.
• Row filters and column masks are defined once as SQL functions and layered on top of grants; ABAC scales them across the estate by tag, and every access is captured in audit logs and lineage.

What is fine-grained access control for data?

Fine-grained access control is the ability to govern data below the level of a whole table, down to specific rows and individual columns, and to decide which identities (users, groups, service principals, and the agents acting for them) can read or modify each. Coarse controls answer whether a person can open a table. Fine-grained controls answer which rows, and which column values, that person can see. The strongest implementations enforce these rules at the query engine rather than inside each application, so the policy holds no matter how the data is queried. On Databricks, Unity Catalog provides this model for every governed table.

The building blocks of fine-grained access control

Four mechanisms work together:

• Role-based access control (RBAC) sets the baseline: privileges granted to users, groups, or service principals on objects like catalogs, schemas, and tables. It answers who can touch which objects.
• Attribute-based access control (ABAC) governs by classification: policies evaluate tags on objects, so one rule can cover many tables and automatically reach new data as it is tagged.
• Row filters restrict which rows a query returns, so a user sees only the records they are entitled to.
• Column masks redact or transform values in sensitive columns, so a user sees a masked value while an authorized user sees the original.

Dynamic views add a view-based option that filters or redacts data using SQL expressions and the caller's group membership.

When to use each control

Control	What it does	When to use it
RBAC (GRANT / REVOKE)	Grants privileges on catalogs, schemas, tables, and columns	The structural baseline for who can access which objects
ABAC (governed tags)	Applies row filters, column masks, or grants by tag across many objects	Scaling policy across the estate and covering new data automatically
Row filter	Hides rows a user is not entitled to	Row-level security, such as limiting a user to one region or account
Column mask	Redacts or transforms sensitive column values	Protecting fields like identifiers or financial data within a shared table
Dynamic view	Filters or redacts through a SQL view	View-based patterns or when consumers read a curated view

How Databricks approaches fine-grained access control

Unity Catalog combines these controls into one access-control model that enforces every layer a query passes through: privileges and ownership, attribute-based policies, table-level filters and masks, and workspace restrictions.

• Privileges and hierarchy. ANSI SQL-standard GRANT and REVOKE assign privileges (SELECT, MODIFY, EXECUTE, and more) across a securable hierarchy of metastore, catalog, schema, table, and column. Grants cascade: a privilege on a catalog applies to its schemas and tables, including ones created later.
• ABAC with governed tags. Attribute-based policies attach at the catalog, schema, or table level and use tag conditions such as has_tag('PII') to target objects. A single policy can mask every PII-tagged column across a catalog, and Databricks recommends attaching policies high in the tree to widen coverage. ABAC row filter and column mask policies are generally available.
• Row filters and column masks. Defined once as SQL functions and attached with ALTER TABLE ... SET ROW FILTER or ... SET MASK, or applied at scale through ABAC. They reference the caller's identity through functions like is_account_group_member() and session_user(), and they add restrictions on top of grants rather than replacing them.
• DENY policies (Beta). An explicit deny always takes precedence over any grant, direct or inherited.
• Engine-level enforcement. Controls fire at the SQL engine, so the same grants, filters, and masks apply whether the query comes from a notebook, Databricks SQL, a BI tool, Genie, or an agent. Applications cannot bypass Unity Catalog.
• Audit and lineage. Every access is recorded in audit system tables, and column-level lineage traces where sensitive data flows.

For guidance, see the row and column security GA announcement and the guide to scaling governance with ABAC.

FAQs

What is the difference between RBAC and ABAC?

RBAC grants privileges directly on objects to identities, a clear baseline for team access. ABAC evaluates policies against governed tags, so one rule can protect many objects and automatically cover new data as it is tagged. They work together: RBAC sets who the identity is, and ABAC evaluates its policies against that identity.

Can fine-grained access control restrict specific rows and columns?

Yes. Row filters limit which rows an identity sees, and column masks redact or transform sensitive values. Both are defined once as SQL functions and applied per table or at scale through ABAC policies on governed tags.

Does fine-grained access control apply to AI agents and BI tools?

Yes. Unity Catalog enforces policy at the query engine, so notebooks, BI tools, Genie, and agents all get the same grants, row filters, and column masks. An agent inherits the permissions of the user who invoked it.

Do row filters and column masks replace GRANT permissions?

No. They add restrictions on top of object-level privileges. You still grant base table access with GRANT, and the filter or mask further narrows which rows and column values each user can see.