Databricks just changed how permissions resolve in a session, and if you run governed or multi-tenant workloads, you need to understand the model before you flip the switch. Databricks RBAC, or role-based access control, entered Public Preview on July 22, 2026, and it introduces a concept the platform has never had: exclusive, role-scoped access on top of Unity Catalog. Users who assume a role get only that role's permissions for the duration of the session, not their own accumulated grants. That sounds simple, but it is a fundamental departure from the additive model Unity Catalog has used since launch.
The preview is account-level opt-in with workspace-by-workspace rollout, and it changes the permission resolution model your existing queries and pipelines already depend on.
It matters most for regulated environments where mixing data across projects, clients, or clinical trials is a compliance violation, not just a bad day at the keyboard. If you have ever answered an auditor's question with "well, technically the group grants let them see it, but nobody would actually query it," RBAC is the feature that retires that answer.
What does Databricks RBAC actually do?
The core idea is role assumption, not role assignment. In Unity Catalog today, your effective permissions are the union of every grant given to you directly plus every grant given to every group you belong to. If you are in five groups, you carry all five groups' permissions into every session, every query, every notebook. You cannot shed them. You cannot say "for this session, I only want the finance role's access."
RBAC changes that. When a user assumes a role, Databricks replaces their accumulated permissions with only that role's grants for the duration of the session. The user's own direct grants, their group memberships, their inherited access: all suspended. What remains is the role's scoped permission set, and nothing else.
Databricks calls this "exclusive access." The word does two things. It means the role's permissions are the only ones in play, and it means the user must actively choose to assume the role to reach sensitive data. They cannot stumble into it through their default identity. They cannot mix data from two roles in one session. Each role assumption is a deliberate, auditable act.
The release notes call out specific use cases: clinical trials, projects, clients. The pattern is the same in each. You have a person who needs access to multiple isolated datasets, but never simultaneously, and never in a way that lets data from one context bleed into another.
How is this different from Unity Catalog's existing permissions?
This is the question that determines whether RBAC is a net positive for your workspace or a source of headaches. Unity Catalog's existing model is additive and identity-based. You grant USE on a catalog to a group, add users to that group, and those users can query that catalog in any session, alongside every other catalog they can reach.
-- Standard Unity Catalog: grants are additive
GRANT USE ON CATALOG marketing TO analytics_team;
GRANT SELECT ON TABLE marketing.campaigns TO analytics_team;
-- User in analytics_team carries these grants in EVERY sessionThe model is simple, it scales for read-mostly analytics, and it has a known weakness: privilege accumulation. A user in three groups reaches everything any of those groups can touch, in every session, whether they need it or not.
Imagine a data engineer who belongs to three groups: analytics, finance, and platform admin. The chart below shows what happens to their catalog access under each model.
Without RBAC, the user reaches 6 catalogs through accumulated grants. With RBAC, assuming one role exposes only 2. The other 4 are invisible for that session. Not masked, not filtered behind a view. Genuinely inaccessible, because the session's permission set is the role's, not the user's.
Here is a three-way comparison of the access models now available on the platform:
| Dimension | Unity Catalog groups (existing) | RBAC role assumption (new) | Service principal tokens |
|---|---|---|---|
| Permission resolution | Additive: user grants plus all group grants combine | Exclusive: only the assumed role's grants apply | Additive: all grants to the SP combine |
| Session scope | Every session, every tool | Duration of the assumed-role session only | Token lifetime, typically automated |
| Who configures it | Workspace admins via GRANT and ALTER statements | Account admin enables preview, workspace admin enables per workspace | Account admin creates SP, workspace admin grants |
| Best fit | Shared team analytics, broad read access | Regulated isolation, clinical trials, multi-tenant separation | CI/CD, scheduled jobs, automation |
| Status | GA | Public Preview | GA |
The critical row is permission resolution. Every other Databricks access model is additive. RBAC is the first exclusive one. That is why it sits in a new category rather than being a refinement of existing group permissions.
How do you turn it on?
The enablement is two-step, and the order matters. An account admin turns on the preview at the account level first. Only after that can workspace admins enable RBAC in each individual workspace. There is no global on-switch that activates RBAC across every workspace in your account, which gives you a controlled rollout path: turn on the account-level preview, pick one workspace, enable it there, test, then expand.
The release notes do not specify a separate billing line item for RBAC. Based on the feature description, it appears to be a governance capability layered on top of Unity Catalog, not a separately metered service. What you pay for is the compute you run while interacting with governed data, same as today.
One thing to check before you enable anything: your existing group structure. RBAC roles are a new construct, not a rename of Unity Catalog groups. If your groups are a tangle of overlapping grants accumulated over years, you will need to clean that up before you can define meaningful roles. The role design is where the work is, not the toggle.
Also note that releases are staged. Databricks says your account might not be updated until a week or more after the July 22 release date. If you do not see the preview toggle yet, wait.
What breaks or changes when RBAC is active?
This is where you need to pay attention. When a user assumes a role, their own permissions are suspended for that session. That means:
- Scheduled jobs running as a user identity may fail if the user assumes a role that lacks the job's required grants. Any pipeline that depends on accumulated group permissions to reach multiple catalogs will break when the session is role-scoped.
- Notebooks that query across catalogs from different roles will fail. If your analysis joins marketing data with finance data, and those live in separate role scopes, no single role assumption gives you both. You would need two sessions and staged intermediate results.
- Service principals are unaffected unless you also configure role assumption for them. RBAC applies to user sessions. Your automation, if it runs as a service principal with its own grants, continues to use the additive model.
The pattern to watch for is the same one that caught teams off guard when Databricks shipped PAT auto-scoping: a permission change that sounds like a tightening turns out to break jobs that quietly depended on the old, looser behavior. The difference here is that RBAC is opt-in and session-scoped, so it will not break anything until someone actually assumes a role. But once they do, every assumption carries the same risk.
When should you skip RBAC, and when is it essential?
Skip it if your workspace is a single-team analytics environment where everyone who can see the data is allowed to see all of the data. RBAC's value comes from isolation, and if you have nothing to isolate, you are adding ceremony for no payoff. The enablement overhead, the role design, the session management: all cost time that buys you nothing.
Skip it too if your access control problem is "some people should not see some columns." That is a masking problem, and Unity Catalog already handles it with column-level masking and row-level filters. RBAC is about catalog- and table-level isolation between distinct contexts, not about hiding sensitive fields within a shared dataset.
Use it if you operate in any of these patterns:
- Clinical trials or life sciences, where an analyst working on Trial A must not have even accidental visibility into Trial B's data, and where an auditor needs proof that the separation was enforced at the session level.
- Multi-tenant SaaS or consulting, where each client's data lives in the same workspace but must never cross-contaminate, and where a single engineer rotates across clients.
- Financial services with conflict-of-interest walls, where an analyst covering one sector must not access data about companies in a conflicted sector, and where the penalty for accidental access is regulatory.
In each case, the value is the same: the user's default identity cannot reach the sensitive data. They must assume a role, which creates an auditable event, and the role's permissions are the only ones in play.
What should you plan for during the preview window?
Three things, in order.
First, map your current permission graph before you touch anything. Query your Unity Catalog grants, list every group membership for the users who would assume roles, and identify where accumulated permissions are load-bearing for existing pipelines. The information schema in Unity Catalog can give you this.
Second, design your roles around isolation boundaries, not job functions. A role called "marketing_analyst" is too broad. A role called "client_acme_readonly" or "trial_42_analyst" is specific enough that the exclusive access model gives you real isolation. The granularity of your roles determines the granularity of your compliance.
Third, test with one workspace, one team, and one non-production role before you expand. The preview is opt-in and per-workspace for a reason. Use that. Enable it in a sandbox workspace, create a role, have a user assume it, and verify that the permission resolution matches your expectations. Check that queries to out-of-scope catalogs fail with permission errors, not silent empty results.
Watch for changes to the configuration surface. Public Preview features can shift their API, their UI, and their behavioral semantics between now and GA. Databricks also notes that releases are staged, so your account may not see the feature until a week or more after the July 22 release date. Anything you automate around RBAC today may need adjustment before general availability.
The bottom line on exclusive access
RBAC is the first feature on Databricks that lets you say "this session can only see this data, and nothing else." For teams operating under regulatory constraints, that is a capability they have been working around with separate workspaces, separate accounts, and awkward process controls. Now it is a session-level property. The trade-off is that exclusive access breaks the pattern every other part of the platform follows, and it requires deliberate role design and testing to avoid breaking pipelines that depend on accumulated permissions. Enable it where isolation matters. Leave it off where it does not.
