Your guide to fine-grained access control: Permissions, ABAC, and RBAC in Unity Catalog

Summary

Unity Catalog's fine-grained access control framework combines granular permissions, RBAC for isolation boundaries, and ABAC with governed tags to apply row filters, column masks, and policy logic automatically across entire catalogs.
New granular permissions split table ownership from modification rights, preventing the over-provisioning that occurs when data engineers automatically receive broad privileges upon creating a table.
Tag propagation cascades column masking and row filter policies to derived tables automatically, and fine-grained governance is extending to AI agents via client ID masking and to model endpoints as securable objects.

Your guide to fine-grained access control: Permissions, ABAC, and RBAC in Unity Catalog

Fine-grained access control in Unity Catalog isn’t a set of disconnected features; it’s a unified framework. Understanding how permissions, RBAC and ABAC work together is key to governing data and AI at scale. In this video, we’ll break down each approach and when to use it. Learn how granular permissions enforce least privilege, how RBAC creates clear isolation boundaries and how ABAC uses governed tags to apply row filters, column masks and policy logic across entire catalogs automatically. We’ll walk through this as a progression — from dynamic views and table-level controls to scalable, tag-driven policies — so you know how to evolve your approach as your data estate grows. We’ll also cover performance considerations, how to avoid conflicts when combining methods and real-world patterns for production environments. Finally, we’ll preview what’s next, including extending fine-grained governance to AI assets and unstructured data, along with new visibility and impact analysis capabilities in Unity Catalog. Walk away with practical guidance to design, scale and future-proof access control.
Talk By: Adriana Ispas, Sr. Staff Product Manager, Databricks ; Arush Mehrotra, Product Manager, Databricks ; Sebastian Hillig, Staff Software Engineer, Databricks ;

Chapters

FAQs

What is ABAC in Unity Catalog and how does it differ from RBAC?

Attribute-Based Access Control (ABAC) uses governed tags on data assets to apply row filters, column masks, and policy logic automatically, while RBAC uses role assignments to create isolation boundaries between teams or domains. ABAC scales better for large, heterogeneous data estates because policies are tied to data attributes rather than individual objects, reducing the volume of explicit grants needed.

How do column masking and row filter policies work in Unity Catalog?

Column masking policies hide or transform sensitive column values for users who lack the required tag attribute, while row filter policies restrict which rows a user can see based on identity or data tag attributes. Both policy types cascade through tag propagation to derived tables, ensuring consistent enforcement without requiring manual configuration on each downstream asset.

What are the new granular permissions in Unity Catalog?

New granular permissions split table ownership from the ability to modify and grant access, preventing the over-provisioning that occurs when a data engineer automatically receives broad privileges simply by creating a table. This supports least-privilege enforcement at the table level and prevents engineers from inadvertently granting access to others without governance approval.

How is Unity Catalog extending governance to AI agents?

Fine-grained governance is extending to AI agents through client ID masking, which applies column masks based on the calling agent's identity rather than a human user's. Grant and deny policies can also be applied to AI model endpoints as securable objects, enabling organizations to govern which agents or users can invoke specific models within Unity Catalog.

Full transcript

[00:08] Thanks a lot for joining us today. I think you've heard it a lot these days, your data in AI estates are growing. But I guess you're thinking maybe our governance efforts should not. And that would be a justified thought. More data,
[00:20] more AI assets, more teams that are being enabled, more systems connected. That's the goal. But governance should not grow the same way because if we have
[00:32] every table, every new asset, every new app, every new model requiring yet another thing that somebody needs to configure by hand, then the governance teams will never catch up. I'm Adrian.
[00:47] I'm one of the product managers on the Unity catalog team and I'm joined by my colleague Arouch who's also product manager and Sebastian who's a tag lead on the team. And today we will walk you through how to think about fine grain
[01:00] access control in unity catalog. We will tell you about permissions aback rback and um when to reach out for each and also how to combine them as your data and AI states are growing. To make this
[01:14] picture a bit more concrete we wanted to start with a simple example. Let's imagine we have a governance admin and the governance admin in this case starts set up setting up a structure that follows the organization. They take care
[01:26] in this case by marketing, sales and finance and they create a catalog and schema for each of these teams and they also grant permissions like you see here on the side so that each team can have access to the right data.
[01:40] Now the reality is that none of the organizations stay this clean. This model is still understandable, but very soon we realize that well marketing and finance need access to sales data. Data
[01:53] science needs access across all of these domains. And what happens is that over time if we keep on relying on this sort of object by object controls like we have here on the side. Well, that becomes very hard to keep consistent.
[02:06] And there are several challenges. One of them is permission fit for the task. And again with a very simple example, let's think about data engineers who typically create um assets
[02:18] for our teams or governance admin gives them access to create tables to create assets in the right schemas. But the problem is that as soon as a data engineer creates a table, they are the
[02:30] tables owner and ownership comes bundled with additional permissions. So in this case our data engineer as the creator can also grant permissions to others and they can also do that without even asking the governance admin. So the
[02:43] challenge here is that the permission that they were given was broader than the task. Another challenge is consistency at scale and in this case we have sensitive
[02:55] data controls. Very often they need to be common across several different assets. We need to mask typically customer emails wherever they appear. We need to filter revenue by region. We need to mask SSN. We need to mask PII
[03:08] information. And we know that teams typically used to do that table by table. Set a filter, set the mask individually for each tables or use a dynamic view. Now the reality is that
[03:21] proceeding that way often time leads to fragmentation. And here there is an example. We have a table owner who decided to mask as a sense by stars. Another one who decided to return null and the third one never even got to
[03:34] doing any masking. So what happens is that over time we just have inconsistent coverage. A third challenge is permission accumulation.
[03:46] Very often we have people that work across different tasks. And here again two simple examples. We have an HR analyst that occasionally needs to manage personal details. So they are granted access to see unmasked
[03:58] information. They can also manage compensation and that can be done for a different task. The challenge is that if they hold permissions for these two tasks at the same time, they can perform actions that originally were not
[04:10] intended. In this case, they can connect a name person with their salary with a single join. A second example here is side reliability engineers. We hear a
[04:22] lot about this from some of our customers. Then the typical task here is debug access issues and the only permission that we had for that was manage. But this is a powerful permission because it also allows one to delete object. And if you hold that
[04:35] permission the whole time there is a lot of risk that by mistake you're deleting access maybe the logs here. So what we see here is that the permissions were right for each of these tasks but when they are held at the same time they can
[04:48] enable actions that are not intended. And now if we add AI into the picture, we have more assets. We have models, model services, skills, MCPS, and these are some of the assets that probably you
[05:00] heard about and you will hear about uh over these days that are being added to Unity catalog. We also have more consumers. We have AI agents acting on behalf of users, Genie Spaces, apps. The
[05:12] reality is that with so many assets and so many consumers, it just becomes very hard to keep track of governance efforts. So to sum up uh governance of skills comes down to three main challenges.
[05:25] We've walked through them. Privilege fit for the task. We've seen that if you have too broad privileges that can create unnecessary risk. And we saw that with the table creators who could also manage permissions. Then the second one
[05:37] is consistency at scale. We saw that if you do controls object by object that just doesn't keep up as your estate grows. And the third is isolation. We've seen that permissions accumulate across
[05:49] task and that can again create unnecessary risk. So, Unity catalog addresses this with three layers of control. For permission fit uh task uh fit for the task, we are introducing
[06:03] granular permissions so that one can actually grant only the privileges that are needed for the task. For consistency at scale, we are introducing aback policies. They are already available and you will hear much more about it. And
[06:15] here the idea is that one can classify data but also users with attributes and then use those attributes as part of rules that apply automatically to everything that matches. And the third
[06:28] for isolation we are introducing role-based access control. It's in private preview as you will hear. And this is all about assuming a role and only the permissions granted to the role when there is a need to have control
[06:41] over the active access that the user has at the particular point in time. Now these layers of control can combine and you will hear in just a bit how you can do that. But before doing the looking at
[06:54] how to combine them, let's look at them in in turn. Let's start with permissions because everywhere everybody starts with permissions and we've seen how you can grant permissions to catalog schemas and tables and what we want to highlight
[07:07] today is how they're getting more granular and we will take the example of manage from before. We've heard that manage just provides very elevated controls for our site reliability engineer from before though they don't
[07:19] need to delete objects for example they only need to view grants. So what we are doing to enable this kind of tasks is splitting manage into several more fine grain privileges. Two
[07:31] of them are here on the screen and we are considering several others. The first one is read metadata and this is all about inspection. You can view grants, you can view object properties but not change any of this. A second one
[07:46] is manage access control and this is about granting and revoking permissions but not holding any other of the privileges that manage grants you. So if now governance admin only grants our
[07:58] sRes read metadata that basically allows us to achieve permission fit for the task. Now this is in private preview and another such case of splitting privileges that is in private preview is
[08:11] the modify privilege or modify permission. Again we have an example of a permission which is quite broad. It allows a lot of actions inserting records modifying schemas and so on. But
[08:23] you don't always need all of these for every task. And here we have some examples. We have service principles that can only or should only ingest records. Well, let's just grant them insert in that case, which is one of the
[08:35] sub privileges we have for modify. Then data engineers need to do merging to CDC. Well, let's grant them all of the insert, update, and delete, but not the full modify. The full modify should
[08:47] maybe only be held by data architects, which is what we have in this example. So what you see is an approach where we are splitting course privileges into more fine grain privileges so that you
[08:59] can actually prevent over pre uh permissioning so that you can grant less by default and overall enable more clean separation of duties. Now permissions are all about granting
[09:12] the right thing the right permissions for the task. But sometimes this type this kind of permissions are the same across many different objects and if we do if we have a user grant privileges
[09:25] object by object we've seen it doesn't scale. This is where aback policies come into play and Arouch will tell you all about it. >> Awesome. So,
[09:37] attribute-based access control or Aback for short is a dynamic access control model that allows you to define access decisions using policies. In those policies, you can define an access rule and attributes will determine where that
[09:50] rule applies. In this specific example, the attributes are governed tags. Tables can be either tagged as marketing or public and columns within those tables can be tagged as PII. Now policies are
[10:03] also attached to a scope. Here the policy is attached to the marketing catalog which means that it will apply to all tables within the marketing catalog that fulfill the attribute conditions. So what this policy is
[10:15] saying is for all marketing tables that are not public, we want to mask all of the PII for all account users except those in the marketing group. Now what's powerful is what happens next. The
[10:27] moment a new table comes in and is created and tagged in the same way, the policy will automatically take effect, there is no need to manually apply a masking policy on every single table.
[10:40] Now within ABACK today, we support two main families of policies. The first are content protection policies which include row filters and column masks. These policies affect what data a user
[10:52] can see and securables and objects they already have been granted access to. On the previous slide, we saw an example of a column masking policy. Now, this idea of content protection policies is also
[11:04] being expanded to content that's exposed through AI services like MCPs and model services. For example, you can mask PII if the service call is by an agent. The
[11:16] second group of policies are access permission policies. Here we have both grant and deny. These policies control whether a user gets a permission based on attributes. In both cases, the same
[11:28] model applies. Use attributes to decide where a rule applies. And now let's look at two examples.
[11:42] So models are everywhere, right? They're being released all the time. And customers want a simple way to control which ones their teams can actually use. For example, you may only want data scientists to be able to execute models but not contractors. Here's where grant
[11:54] policies come into play. The governance admin can create a policy that grants execute for models where the provider tag is enthropic. Now, the next time anthropic releases a new opus or sonnet
[12:06] model and it is registered and tagged within UC, your data scientist will automatically have the ability to start using those models and you do not need to maintain permodel grants.
[12:18] Now let's look at an example of a deny policy. Let's go back to the data engineer from the beginning. They needed to create tables, but because they became the owner of those tables, they also had the ability to grant permissions to others. To close this
[12:32] gap, the governance admin can define a deny policy. Here we are denying manage access control for tables to the data engineers. So the data engineers can still create the gold tables but the moment they try to grant permissions to
[12:44] others it will be blocked by the deny policy. This allows us to separate table creation from access control. Now within Aback there are three categories of attributes. First are
[12:57] attributes on the data. These are govern tags which can represent things like PII or domain. These can be set manually, automatically through data classification, inherited or propagated
[13:09] as data is derived. The second type of attributes are attributes on the principle. These are identity attributes which can be set and synced by your IDP and can represent things like department or cost center. Finally, we have
[13:23] attributes on the request. This captures how access is happening. for example, through an on behalf of user flow, a workspace, or any other request level signal. The important part is that a policy can combine all three types of
[13:37] attributes. This is how you get richer conditions with fewer policies. Now, we're going to walk through a demo to see how these layers compose with one another.
[13:54] Now, in this demo, we have four different cataloges. finance, HR, marketing, and sales. For the purpose of this demo, we'll focus on the HR catalog.
[14:07] As an HR analyst, here's an example table. Within the table, we have columns such as email address, SSN, and phone number, all of which contain personally identifiable information. As the governance admin, I want to ensure this sensitive data is protected.
[14:20] I'll create a column masking policy that applies to all account users except members of a dedicated PII access group. The policy will automatically apply to any columns containing specific govern tags.
[14:33] The policy has now been created. For this portion of the demo, I'll manually apply the govern tags to the PII columns. We're doing this manually for demonstration purposes, but later I'll show how data bricks can automatically classify sensitive data and apply these
[14:47] tags at scale using automated data classification. Now once we've applied these tags, let's switch back to the HR analyst. We can
[15:01] see that the email address, SSN, and phone number columns are all masked as expected. Next, as the governance admin, I want to create a row filter policy. This policy will only return rows that match a
[15:13] user's approved country. We're leveraging identity attributes and checking a user's country assignment, then filtering results so users only see rows corresponding to their approved country. The policy is applied to users
[15:25] whose department identity attribute is set to HR and it targets data that's tagged with the class.loation govern tag.
[15:37] Switching back to the HR analyst, we can see that the policy is working. Only employee records from the US are visible because our HR analyst country attribute is the US. As the governance admin, I also want to ensure that data engineers cannot
[15:50] independently grant permissions on newly created tables. To enforce this, I'm creating a deny policy that blocks the manage access control permission. Now let's switch to the data engineer
[16:02] persona. Here we have two tables. employees which contains employee information as well as salary changes which contains salary related data that's linked
[16:14] through the employee ID. Let's try to grant select permissions on the employees table and see what happens. The operation fails with a permission denied error. This happens because I do
[16:27] not have access to the manage access control privilege confirming the deny policy is working as intended. Earlier the governance admin manually applied govern tags. Now let's look at how data classification automates that process.
[16:39] Data classification automatically scans data, detects sensitive information, and applies the tags. Here we can see data bricks automatically identifying four different categories of PII. If we navigate to the catalog explorer
[16:52] and inspect the employees table, we can see that all four tags were applied automatically. Next, let's look at tag propagation. Tag propagation allows govern tags to
[17:05] automatically follow data as it is transformed and derived. For example, through a catass operation or view creation. Here I've created a custom govern tag called dice demo department.
[17:17] From the govern tag UI, I can enable tag propagation and specify a default value. Once we've configured tag propagation, let's go back to the catalog explorer.
[17:34] For this example, I'll apply this department tag to the department column in the employees table. Now, let's switch to the data engineer. I'll create a new table called employees department using a cat statement that
[17:46] selects a subset of columns from the employees table. Once the table is created, we can inspect it in the catalog explorer. Notice that the govern tag was automatically propagated to the derived
[17:59] table without any manual actions. Now governance isn't limited to data. As the governance admin, I also want to control which models users can access. Within system.ai, we can see all
[18:11] available models. And each model has a govern tag indicating its providers such as OpenAI, Anthropic, Google. Now, as the governance admin, I'm creating a grant policy that allows data engineers to execute models only when
[18:24] they are tagged as enthropic, data bricks, or open AAI. Now, let's switch to the data engineer. First, I'll invoke an anthropic model through AI query.
[18:42] The request succeeds. Next, I'll attempt to invoke a model from Alibaba. This time the request fails with an error that we are missing the privilege execute. That confirms our grant policy is working. Let's return to the HR analyst view. As
[18:55] a reminder, if we navigate to the employees table, we can see that the email, SSN, and phone number columns are all masked.
[19:07] Now, we want to extend governance to AI agents. As the governance admin, I'll create a masking policy that returns the value agent redacted whenever sensitive data is accessed through an AI agent.
[19:19] For PII columns, I'm using a context attribute based on client ID. This client ID corresponds to the OOTH application used by the data brick SQL MCP authentication.
[19:33] Now let's switch to cloud code acting as the HR analyst. I'll query the employees table through the data brick SQL MCP. And because the request is being made through the ooth application associated with that client ID, we should see the masking policy be triggered. Notice that
[19:46] all sensitive fields now display agent redacted. This confirms the policy is working for agent access. Finally, there are cases where authorized users need access to unmasked
[19:59] PII. As the HR analyst, I have the ability to assume a special PII access role using the RO switcher. I'll switch into that role. If we navigate to the employees table,
[20:12] we see the PII values become visible. However, this role is intentionally constrained. While it grants access to unmasked PII data, it does not provide access to other tables. So, I cannot join this data with other data sets to
[20:24] infer additional sensitive details. Now at the end of the demo you saw how we can leverage the role switcher to assume roles. Both permissions and Aback
[20:38] together handle who can access what. But we can leverage role-based access control or arbback to address context isolation. Arbback lets a user work in one access
[20:50] context at a time by assuming a role. Now when they assume that role their personal grants are suspended and only the role's permissions are active. This is how arbback breaks the permission union. The user does not carry every
[21:03] permission into every task and they can step into the access context they need when they need it. For isolation, the best practice is to keep assumable groups empty. Users should not inherit the group's permissions by default and
[21:16] should assume the role only when the task requires it. Now let's look at an example. we saw before. Remember these users who were over permission over permissioned for the task they needed to complete.
[21:29] Let's see how arbback can help solve for these cross context risks. In the demo, we saw the example of the HR analyst. So let's focus on the S sur can assume a debugger role that holds
[21:41] only read metadata. They can inspect grants and metadata while debugging, but they do not hold that access all the time. In each case, the pattern is the same. You assume the role for the task,
[21:53] work in that access context, and leave your other permissions inactive. Arbback with the option to assume any group will be available in public preview very soon. So far, we've covered the access
[22:05] controls layers, permissions, Aback, and arbback. These layers compose, and the last section, which my colleague Sebastian will walk through, is about how to compose these layers deliberately and best practices that we recommend.
[22:18] >> Thank you, Arush. All right. Um, so yeah, in this last section, we uh really want to go into a couple of selected patterns that we've seen uh customers apply or that we recommend customers apply while
[22:30] operating uh at scale. And this is not exhaustive. We have a couple minutes here. Um so we will I recommend looking at the recently revamped Aback docs. They are they actually got like a big overhaul and like they and go in a lot
[22:44] more detail than we will be able to do here. If there's one key takeaway that I can give like that you should leave with today is that you should be keeping things simple and composed permissions aback and arbback deliberately.
[22:56] So when you start out start with direct grants right like you can you can use those for static and one-off access once patterns as you find patterns and those emerge you you move on to aback grant
[23:09] policies. So you so the access basically follows your tagging strategy. You can start with table level filters and masks um as a way to you know like govern the a specific case for one table. But you
[23:21] can then as patterns emerge go to aback row filters and mask policies and have again your content protection follow your tagging strategy whenever the conditions match. Use those granular
[23:35] permissions right give the right permission instead of a broad one. Don't give manage if you can get something more specific. And arbback cross-co composes with all of this as it narrows the active access context and basically leverages all the primitives that I just
[23:48] talked about direct so direct access when static attribute based when rules repeat and role based when the context matters and we don't want to cross-pollinate we want to break the union of our permissions.
[24:02] A core component of um policies is user are is user identity groups and attributes. So our suggestion is to reach first for platform managed groups and identity attributes.
[24:15] Why why those first? Because those tend to be computed only once per session and they're cheaper during query runtime. So groups you can use those for access by membership. Um identity attributes work
[24:29] work better if you think about stable properties. Think about something like uh clearance level or maybe an employment type and you can sync those through your IDP. So all of that basically in in the ideal world is automated. Now there that is not to say
[24:44] that you know there aren't use cases that go beyond this like for more complex use cases you can always reach to mapping tables and you can use for example changing that that you can use in cases of changing state imagine an
[24:57] improv approval workflow that ends up creating a row in a table and you need that as the way to decide whether or not to give access. This comes at a query time cost though and we'll talk about this in a short moment again but so
[25:10] again go platform manage first and mapping tables if you need additional flexibilities. Groups and identity attributes decide who policies apply to and you can use mapping tables as well
[25:23] to decide that but tags decide which tables and columns will be affected by the content protections that you put in place in fil in row filters and masks. So tags and attributes become new
[25:37] security boundaries in your system. And this is something that you now have to design for, right? You have to be very deliberate in who defines, manages and attaches these attributes.
[25:49] There are separate permissions in the system to allow for separation of duties. So you can distribute these responsibilities in your organization. for example to a governance uh council that decides on what the taxonomy of
[26:02] should be data stewards that apply tags and for and just to like cut it short for a moment here data producers that have to follow the tagging standards that you are setting up as a company tags and attributes become part of your
[26:15] access control regimen. So that also means that bad text and attributes mean bad access. So just like groups, you need to have a controlled texonomy here, a trusted assignment and a regular
[26:28] review. If you keep keeping your uh tagging and attribute tonomy in check will also allow you to keep your policy simple. One thing that Abeck does is it allows
[26:41] you to cut cut away on like the numerous object level grants. We saw that earlier. But what it does not stop you from is having a lot of policies if you're not deliberate. If every team in in your company invents
[26:55] its own tag tagging regimen, its own mechanism, it will be really hard to scale across the whole company. So we're we suggest that you standardize early. Start with a small set of text policies
[27:08] and UDFs. Document those centrally and make sure that you know like you keep it simple. Don't don't don't use super technical names. Make it something that's understandable so that you are able to review, consolidate and evolve
[27:21] as as your estate grows. Now to make this a little bit easier, there are a few features coming um in the near near-term future. Um one of them is
[27:33] metas store level policy. So you can apply policies at the metas store level across all your cataloges. There will be policy composition. So that allows you to um combine row filters um or have ma
[27:46] have masks basically take precedence over each other. Also we will be providing more predefined masking functions so you don't have to reinvent the wheel every single time you're trying to reach for
[27:59] something that should be simple. The takeaway here should be that a few reusable policies beat many many special use cases. It's not always possible to uh avoid complexity and you know when you have
[28:14] when you when you have to because of requirements the the important portion is to introduce um this complexity in a controlled way. There are a lot of use cases that you can imagine that go
[28:26] beyond s simple tag assignment. Um, think about time based access, think about approval state, think about maybe ownership transfers in your organization that you want that you don't want to update the whole all tables for.
[28:39] Our suggestion is to really check built-in paths first, right? Like get find the well- paved um path before you reach for building your own. But if there's no if there's no such path, go for a controlled mechanism. use jobs to
[28:54] automate creation of maybe tags uh or um uh tags or group assignments for example. But you can also use mapping tables or SQL policy functions to um to have to
[29:08] have more power at at your hand and at your fingertips. But important part again validate before not again but like validate before prof right test the representative queries. Think about that
[29:20] different users in your in your estate have different views of the system and different policies apply to them. So looking at the various personas is important to understand what you know like how like the complexity of your
[29:32] that you're introducing actually plays out in reality. Now takeaway here should be leverage built-in functionality before you reach for complexity and you should be and be deliberate about it and follow best practice as you roll out.
[29:45] Simplicity com is also important because it uh is also there's a cost and time aspect to it. Right? If you think about filters and masks, those apply to every single table scan where they when they
[29:58] are active. So that is time and cost spent on every single query. So that's why we really want you to make sure that you design simply keep things reusable. Prefer simple over complex. A full
[30:11] reduction is cheaper than like a partial reduction, right? If I if I just put a static value over like maybe uh like half the value, I can I can skip the whole read on that column. Measuring is also super duper important
[30:25] like especially as there are different users that have have different views. You really want to make sure that you that you that you capture that in in your um deployment strategy. And last but not least, avoid expensive logic. If
[30:37] you if you do if you have network calls in your masking functions or uh non-deterministic uh non-determinism large joins maybe or like a he heavy regular expression that will you know blow up your cost and uh make your make
[30:52] your um content protection setup possibly even you know very flaky which is not something that you want out of a security uh barrier that you have in your system. So remember filters and masks run on every query and time and
[31:05] cost can just explode if if you're doing two not simple things but even simple setups have will have some complexity and whether that is in the number of policies or managed assets in the end
[31:17] you know like you need to keep an overview of like your whole estate. So one of the things that we're providing you with is a one place the governance hub in the admin console that will give you governance insights. Today you will
[31:32] find data data and cost insights there. And what we're adding are access insights which will tell you what a user can do how like what a user can do what what
[31:44] they can access and how it was granted. Now you can also use it to find gaps. Where are where is the missing data missing metadata? Where are the classification gaps? Where do I have where do I have policy coverage gaps?
[31:56] And you can then clean up unused access and figure out like maybe there maybe there's even some risky access. Governance hub is the place to understand your usage and access.
[32:09] Now um now last but not least I'd like to just close with a couple of sort of core thoughts here. Um for one really
[32:23] consider like basic let's let's keep it simple access should m match the task right use granular permissions to grant only what the task need don't don't over don't over don't don't over don't over permission I'm sorry um repeated rules
[32:37] should be policy driven so when aback use aback when the same rules apply across many objects find those patterns and give them policies active permissions do not have to carry into every task Use arbback to uh segregate
[32:52] what permissions you are working with at any point in time. Attributes can change exist decisions. So you have to be deliberate and control who can set update and manage these these um these
[33:04] attributes. And lastly, you want to operate deliberately. You want to be simple by default, tested when complex and reviewed over time.
[33:16] Thank you for your attention. Um, and at this point we'd uh love to hear if you have any questions.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.