Unity Catalog Access Control: From Grants to ABAC

I directed an enterprise data catalog implementation a few years back that included configuring cloud permissions and access controls across Azure, Databricks, and SQL environments. GRANT-based permissioning worked, until it didn't, and the moment it stopped working was completely predictable in hindsight. Databricks has been pushing attribute-based access control (ABAC) in Unity Catalog hard enough that most teams running a lakehouse of any size are going to face this migration in the next year or two. Here's what actually changes, and what doesn't change just because you flip a policy engine on.

Why Grant Sprawl Happens

GRANT-based access control is easy to reason about for the first fifty grants. It's a straight line: this role gets SELECT on this schema. The problem is that the number of grants you need doesn't grow linearly with your data estate — it grows as a product of three things that are each independently growing.

Every team wants its own schema, because shared schemas turn into cross-team disputes about who broke what. Every schema needs its own set of role grants, because "read access to marketing" and "read access to marketing's PII-adjacent customer table" are not the same grant even though they live one schema apart. Then contractors and vendor accounts show up, each needing a scoped subset of access for a fixed engagement window, each one a manual grant someone has to remember to revoke on the right date.

Multiply those three factors across a real organization and you get a permissions matrix that nobody — not the platform team, not security, not the auditor — can fully enumerate. Not because anyone was careless, but because GRANT statements don't compose into a queryable policy. They're a pile of individually correct decisions that, in aggregate, nobody can answer "who can see this column" about without running a query against the metastore and hoping the results are complete. I've sat in exactly that meeting: an audit request comes in, and the honest answer takes two days of digging because the access model was never designed to answer the question being asked of it.

What ABAC Changes

The core shift is that policy attaches to a classification, not to an object path. In a GRANT world, access is a statement about this table. In an ABAC world, access is a statement about anything tagged this way. Tag a column as containing PII once, and every policy written against the PII tag now governs that column — automatically, retroactively, and for every table created afterward that inherits the same tag.

That single change collapses the multiplication problem from the section above. You're no longer writing a grant per team per role per object. You're writing a policy per classification, and classification assignment — not grant assignment — becomes the operational bottleneck. That's a much smaller, much more auditable surface. An auditor asking "who can see PII" gets an answer by reading the policy attached to the tag, not by reconstructing intent from hundreds of individual grants.

The Migration Reality

Here's the part that gets glossed over in the announcements: you cannot flip a switch from grants to ABAC and get a better outcome automatically. ABAC is only as good as the classification underneath it. If your tables and columns aren't accurately tagged — if half your PII columns were never flagged as PII, if "restricted" and "internal" get applied inconsistently across teams because nobody agreed on the taxonomy before tagging started — then ABAC doesn't fix your access problem. It automates your existing mess at a larger scale and with more confidence than it deserves, because now there's a policy engine asserting "this is correctly governed" over data that was never correctly classified in the first place.

This is the same lesson from dictionary and taxonomy work showing up again in a different layer of the stack: classification hygiene is prerequisite infrastructure, not a nice-to-have you can retrofit after the policy engine goes live. The actual migration sequence that holds up is boring and sequential — audit and correct classifications first, write policy against tags second, decommission legacy grants only once tag coverage is verified as complete. Anyone who tries to run those steps in parallel, or skip the audit because the classification exercise feels like it's blocking a shiny new feature, ends up automating inconsistency instead of removing it.

Row and Column-Level Nuances

Table-level classification is the easy case. Row and column-level access control is where ABAC earns its complexity. A single table can need a column masked for one attribute-defined group and visible for another — customer PII columns visible to a support team handling account authentication, masked for an analytics team running aggregate reporting on the same table. Row-level policies compound this further: a sales rep should see rows for their own region, not the whole table, and that scoping needs to follow the rep's attributes (region, role) rather than a static grant tied to a specific view someone built for that purpose.

The failure mode I've seen here is building dynamic views as a workaround before ABAC row/column policies existed, and then never migrating off them once the native policy engine caught up. Those views become their own shadow access-control layer — undocumented, unaudited, and invisible to whoever is trying to answer "what governs access to this data" using the catalog's own policy surface. Part of any grants-to-ABAC migration has to include finding and retiring that generation of workaround views, not just writing new policy on top of them.

Where This Connects to Agent Access

None of this stays contained to human users much longer. Once agents are querying Unity Catalog on someone's behalf — summarizing a table, joining across schemas, acting on retrieved rows rather than just displaying them — the access question stops being "what can this person see" and becomes "what can this agent see, on whose authority, and does that authority follow the agent across every table it touches in a single session." I go into that shift in more depth in the piece on governing AI agent data access, but the short version is that ABAC's attribute-following-classification model is a much better fit for agent access than grants ever were, because an agent's permitted scope needs to be expressible as a policy, not as a list of tables someone remembered to grant it.

It also depends on the same classification hygiene problem covered above. Whatever governs human access to a customer table needs to have started from clean intake, which is the subject of the post on customer MDM intake and data quality — an agent inheriting a policy built on top of dirty classification inherits the mess just as fully as a human analyst would, just faster and with less friction to catch it.

Where It's Heading

Databricks announced contextual policy capabilities for Unity Catalog this month at Data+AI Summit — access decisions that factor in query context, not just static attribute tags, still in beta as of this writing. That's the next layer past where most organizations are today. Most teams haven't finished the grants-to-ABAC migration yet, let alone gotten to context-aware policy. But it's worth naming the direction now: the trend is toward access control that reasons about attributes and context together, and every step of that evolution depends on the same unglamorous foundation — accurate, current classification of what the data actually is before any policy engine gets to decide who sees it.

The tooling keeps getting more capable. The prerequisite hasn't changed at all.