Data governance at scale: ABAC for fine-grained access control

Summary

Databricks Attribute-Based Access Control (ABAC) allows data teams to define a single policy using governed tags and declarative semantics that automatically propagates across all tables in Unity Catalog, eliminating manual table-by-table protection.
Atlassian implemented ABAC to govern over 1,000 sensitive tables in their Socrates lakehouse—a 50-petabyte environment with 50,000 tables—reducing operational overhead and enabling Delta sharing and time travel for restricted data.
The ABAC framework's three-step approach—organize data with governed tags, detect sensitive attributes, and protect with masking or row-reduction policies—provides a scalable and auditable model for enterprise data governance.

Data governance at scale: ABAC for fine-grained access control

Protecting sensitive data across thousands of tables requires a governance model that scales beyond manual, table-by-table controls. Traditional approaches create fragmentation, inconsistency, and maintenance burdens that slow down data teams and leave sensitive information exposed.
This talk explores how Databricks Attribute-Based Access Control (ABAC) enables automated, policy-driven data protection across Unity Catalog. Learn how Atlassian used governed tags, declarative policies, and inheritance to protect over 1,000 sensitive tables consistently, reduce operational overhead, and unlock Delta sharing and time travel for restricted data. Discover the architecture, real-world implementation patterns, and roadmap for scaling governance at enterprise speed.
🤝

Chapters

FAQs

What is Attribute-Based Access Control (ABAC) in Databricks?

Databricks ABAC is a policy-driven data protection capability in Unity Catalog that uses governed tags to automatically apply masking and row-filtering policies to tables without manual, table-by-table configuration. It enables teams to define a rule once and have it propagate automatically to every table that carries the appropriate tag or metadata attribute.

How does ABAC differ from traditional grant-based access control in Unity Catalog?

Traditional Unity Catalog grants operate on an all-or-nothing basis, determining whether a user can see an entire table or nothing at all. ABAC adds fine-grained column masking and row filtering on top of grants, allowing different users to see different views of the same table based on their identity and role attributes.

How did Atlassian implement ABAC for their Socrates lakehouse?

Atlassian used ABAC along with a custom internal language called Fluid to define metadata classification configurations and policy descriptors covering masking and row reduction. They attached policies to databases, enabling automatic inheritance so that newly added tables are governed without manual intervention.

What outcomes did Atlassian achieve with ABAC in production?

Atlassian used ABAC to protect over 1,000 sensitive tables consistently across their 50-petabyte, 50,000-table Socrates lakehouse, significantly reducing operational overhead. The implementation also unlocked Delta sharing and time travel for restricted data, capabilities that were previously blocked by their coarse-grained access controls.

Full transcript

[00:07] Good morning everyone and thanks for being here. Assuming you all attended the keynote, I can imagine some of you are getting hungry, but I'll I'll promise you this one will be worth it. Um my name is Eric. I'm a product manager at Databricks and I'm here today with Gerald from Atlassian. So this is a
[00:23] joint customer Databricks talk. And we're going to talk about attribute-based access control, in short ABAC, um and how you can use it for automated data protection. I'll first introduce you to the capability, after which Gerald from Atlassian
[00:39] kindly offered to walk you through their implementation and show you how this is done in practice. I actually hope you can see it. The screen is a bit smaller than I counted on, but uh um Okay, maybe before we dive into that, a show a quick show of hands, like um
[00:56] who here in the room manages more than 100 tables with sensitive data or any type of data that you want fine-grained access controls on? Okay, that's good. It's always great if this works out. And then more than 1,000?
[01:19] A few. Okay. Wow. It's going to be relevant for all of you. And is there a part of the group here that doesn't actually know how many tables they have roughly? You can be honest. Um but um actually we've got something for that as well, too, but I'll get to that in a bit. But independent but for any of
[01:36] these numbers, um this is going to be relevant for you. Imagine your your CISO walks in tomorrow and they ask you to protect customer PII in a certain way or in a different way. Like who could have that done by the end of the day? Second show of hands.
[02:01] Yeah, that that's what we thought and that's actually very common for many large companies. So uh so in Doma and I shame we see that all the time. Um the larger your data estate and the more teams touching it, the more difficult this data protection becomes. But it doesn't have to be that way. Um a new rule shouldn't take weeks. You
[02:19] should define a rule once and it should apply everywhere. And that's the target of today and that's actually why we built a back and what I will tell you about. I'll tell you how you can use it to protect um to apply filters and masks at scale. But before doing that, I'll quickly go into
[02:34] what masking and filtering actually is for the ones new to the topic very briefly. So in UC Let me actually do this. In UC a ground decides whether you can see a table um or not. But it's all or nothing. So either you see the whole thing or you
[02:50] see nothing. Um but very often different people should be able to see different parts of the same table and classically you could do that through views. And that's fine, but when this scales and when you have a lot of different groups, you end up with a sprawl of views which can be difficult to maintain, especially if there's table
[03:06] changes, schema changes, etc. And a more direct way to do that is to apply filters and masks on the original table itself. And you see two examples here what this looks like. In this case, we mask social security numbers for all users not in the HR group and
[03:22] may be difficult for you to see in the back, but basically this column here has has access masking part of the column. And on the right-hand side you see filtering where it's actually was the same table, but you see that now only rows with the region equal to EMEA are showing up for another subgroup of
[03:38] people. And for many customers, this is a very powerful capability, but it can be challenging to apply this at scale and I'll show you why. Cuz this is all before a back. So you apply these filters and these mask table per table, and this is typically done by
[03:55] the table owner or somebody with manage permissions at least on the table. And each of them had to write their own UDF that does the masking or filtering and and apply it on an individual table table by table. And there's three main problems. The first one is that this can
[04:11] be inconsistent and very often is inconsistent. So, different teams use different type of masking logic. That is somewhat acceptable, you could say, but the second is more problematic. Which means that it basically puts the responsibility of doing this all together with the data producer. So,
[04:27] they are typically not governance experts in many organizations, so they may end up not masking the data all together, which means the data is left unprotected. And to make the problem even worse, central governance teams often don't really have visibility into these unmasked tables
[04:43] because of how this mechanism works. Thirdly, it's just very difficult to keep up with large numbers of tables, new tables coming in or table changes over time. So, suppose your organization faces hundreds of new tables every month, this typically tends to break
[04:58] down at some point. Well, and that's what we set out to solve with ABAC, attribute-based access control. We now offer three connected capabilities that together enable you to protect data in an automated way. And a simple way to think about them is
[05:14] organize, detect, and protect. Let's start with organize, and that's where govern tags come in. They give you a standardized taxonomy of tags across your whole account, and you can decide what tags can be used and who can apply those tags.
[05:30] And we offer the the second capability, data classification, to help you do that. So, data classification can go and tag the data for you. So, it automatically recognizes all kinds of PII, and it gets tagged if you want to. And you can they can coexist. And
[05:47] thirdly, there's the ABAC policies themselves. Those are the access rules that basically determine what protection logic should be applied. So, in our example here, we're discussing filtering and masking, but I'll show you some of the things we're working on towards the future.
[06:02] As of several weeks ago, all these three capabilities are generally available, so please use them, try them. Maybe some of you have Well, let me talk you through how ABAC works based on on the people involved. So, on the left-hand side, we have your
[06:18] data, the same one you saw just now, catalog, schemas, tables, if you can't read it. So, it starts with the data steward. They basically have permissions to tag the data, to apply tags from this standardized tag taxonomy. So, as you see here, they tag catalog, schemas, or
[06:33] tables. These PII tags are applied at column level. And these people know best in the organization what the data is that should be protected, what what falls in certain um uh restrictions. And then the the governance admin
[06:49] creates the policy. So, they know what the protection needs to be. So, they do that based on the tags, not on the names of the columns or the tables. I mean, here is a small example, but I'll show you a real-life policy in a bit, which will be more more insightful.
[07:06] And then the data consumer just queries the data like they've always have, and they only see the parts of the table that they're allowed to see. In this example, we're using it for sensitive data protection, but note that this logic works for any type of
[07:21] fine-grained access control, independent of whether it's sensitive data or not. Now, let's zoom into the policy, and I want you to show two different ones. First one on the left, a masking policy that you can start writing today. It masks every column that has been
[07:39] tagged PII for anybody not in the HR department when the table is tagged HR. I'm afraid some of you might not be able to read the actual policy. That that's a pity, but basically let me point out. So, a few things worth highlighting.
[07:55] We're using the tags here rather than the names of the columns or the or the tables. That's very important here. And second, because of that, it's evaluated dynamically in within a certain scope. So, here the policy itself is attached to a catalog, which
[08:10] means that everything that it applies to everything in that catalog whenever the tag conditions are met. And third, one of the things that makes it most powerful is um that this is all enforced automatically the the moment that data is tagged.
[08:25] And the beautiful thing about these tags is that they can be applied to higher-level objects like schemas or catalogs and they inherit down to the tables, which means that if you tag a schema or a catalog and a new table appears in there, it's automatically tagged, which means it's never unprotected, which is
[08:42] very different from the old approach that you just saw. And this is what you can do today, but now I want to show you some of the things we're working on and where this is going. So, you can't do that today, but very soon. Um basically here you see that you can
[08:58] grant access to objects as well based on tags. So, it's not only fine-grained control on the left, but also uh general grants. And you see here something else which is different, which is identity attributes are used. So, currently we only offer tags on data, but we'll be expanding that soon
[09:15] amongst others with these identity attributes, which are basically attributes on the users and they enable very powerful patterns. Because what we do here at this function says for tables when the identity attribute matches the tag value. Which basically means that if a user,
[09:32] for example, has an attribute key-value pair department equal to HR and your table has the tag HR as well, they automatically are granted access, which means that you can use a single policy to with very high leverage to basically
[09:48] use uh dynamic granting of access to many departments and many tables through a single policy. And then of course, I mean, the theme of this year as you've seen it is largely AI. Users are not the only actors anymore. We'll nowadays also have agents. So,
[10:05] what we're also adding is what we call context attributes and they're basically capable of capturing whether it's the user themselves that make the query or an agent acting on their behalf through their credentials. And if that's happening, this last line it says has context attributes on behalf
[10:22] of the user should be equal to false, otherwise they're not granted access, which means that if the agent acts, they can't access the table. So, this is two different policies but one consistent model and that's also where the power is. So, you tag your data, you write the policy and the
[10:39] protection follows automatically whether it's grants or whether it's fine-grained access control and this brings us back to where we started. A rule shouldn't take weeks, you define it once, it applies everywhere. And many customers have already experienced how powerful this model can be.
[10:55] And one of these customers is Atlassian. Um they use it at very large scale and they've been a frontrunner in rolling this out and we've Gerald here today who is one of the people key people driving this. Um and he will talk us through how they did that and what they learned along the
[11:10] way. So, please give me an applause for Gerald. Thank you, Eric. Uh morning, everyone. I'm Gerald and I'm an engineer at the data lakehouse team at Atlassian and I'm going to talk about
[11:26] how we integrate ABAC to achieve data governance at scale balancing agility, speed and compliance. Uh if you're not familiar with Atlassian, we're the company behind these products: Trello, Jira, Bitbucket, Loom, Confluence. Anyone use these
[11:42] products? Raise your hands. Lovely. Lovely. Um here's what I have in store for you guys today. We're going to start with the introduction. I'm going to give you idea on Atlassian's data scale, challenges in setting the context for our governance needs, then on the evolution of access control that we've
[11:58] offered in our data lakehouse. Then a deep dive into our architecture and implementation. Then some real-world examples and outcomes, and then finally some key takeaways and future plans.
[12:14] Before we start, does anyone know who this is? Hint, he's a philosopher. Yes, if you answered Socrates, you're right. I'm wondering what does Socrates have to do with access control data lakehouses? Well, it's also the name of Atlassian's internal data lakehouse,
[12:29] which is the backbone of data data-driven decisions at scale. Socrates powers analytics, product insights, and um business decisions across the company. Some useful stats to know about our lakehouse. We have over 50,000 tables,
[12:46] 1,000 more than 1,000 schemas, more than 50 petabytes of data, and almost 10,000 internal users of our platform. Um and taking Alex's example earlier, if we just assume 5% of the 50,000 tables are sensitive, that is over 2, 500 uh
[13:04] tables to be protected. Uh that's quite a lot. Um And the platform has to serve a diverse set of data consumers, from data scientists who want to see product data, to uh product teams who want to analyze feature usage and analyze user behavior.
[13:21] Um finance teams who look at billing data, executives who want to look at KPIs, um HR teams who want to look at employee data, all with different access needs and sensitivity requirements. Um along with this, we have hundreds of
[13:38] data sets, not thousands, um spanning financial records, um PII data, uh hundreds of teams with overlapping but distinct access requirements, um rapidly changing policies we have to comply with from GDPR to SEC to some
[13:54] internal policies we might have. Um data is consumed from different tools, um a BI tool like Tableau. It also be Delta shared different lakes. Um and this is complexity at enterprise scale. As data becomes more available,
[14:09] um managing access at the scale becomes exponentially hard. Um So, this presents the core tension. How do we enable broad data access um while still enforcing strict controls to protect sensitive information?
[14:25] And some real-world examples on how we solved using ABAC. So, streamlining data access. So, we might have some internal policy that you want to comply with with your data. This is encapsulating your special policy logic once and then applying it consistently to all relevant
[14:41] tables. Um governing domains. You might want to mask all PII data within the finance domain. Um complying with data use policies. The way you capture data, you have to comply with certain ways. Um Um so, you would redact certain rows if
[14:56] a user um opted out from these data processing activities. Does this sound familiar to anyone in the room that you have to comply with in your organization? No. So, before we get into how we solve that,
[15:12] just deep dive into the evolution of access control on a lakehouse. Uh first, we started with coarse-grained access control, um typically applied at your database or table level. Um, and this gives you if you have read access, then you get access to all data.
[15:28] Um, and this while it is simple to implement initially, um, it doesn't usually meet the needs, the security and agility of modern data platform. Um, some limitations, all or nothing permissions. If you see the data, you get access to all fields including
[15:45] sensitive fields like PI data. And at that point you are violating the principle of least privilege. Um, role explosion. In an effort to mimic fine grain controls, you end up creating new data sets, ETL jobs, um, roles that access the data. Um, which is a huge maintenance burden
[16:02] for the platform team or whoever is implementing it. Um, it's also not context aware. What you see doesn't dynamically change based on the data attributes or the user attributes. Um, and we don't get precision at the row and column level. And then we just remove the head and now we can offer fine grain access control,
[16:19] which Eric described earlier, which is being able to restrict access to specific rows and columns. And once we were there, you could apply specifically at the table level. Um, Databricks had the offering, we had native row level filters and column masking, but this was at the table level.
[16:35] And now we have ABAC. Um, and so we go go went ahead and implemented table level fine grain access, and it was better. You got precise control, you can do control access at a more granular level
[16:50] from the row and column level. Um, and you get target visibility where you get a secure view of the data. But we ran into issues. Um, there was management overhead. You had to create a UDF per table and columns. Um, if your table had native row level
[17:07] filters or column masks, you cannot Delta share or time travel or time travel. Um, and this was a blocker for a lot of tables in our largest sensitive sensitive tables are being adopting this access control. You also need to require DDL to apply
[17:22] the rules per table. So, you have to write an alter table command. Um so, then we enter the complexity trap. We had many different tables where we were applying the same rules, but we're fragmented. What happens if you change the change the policy of rule? You have to go in each table manually and change
[17:39] it there. And then we we got ABAC. And then this is where we are now, where we've integrated ABAC and now it's context aware based on your user attributes, what groups you're part of, uh based on data attributes, what tags are on the data, um you get different views of of the
[17:56] data. It's also more scalable. If the policy ever changes, uh we change it one place and it will trickle down to all relevant tables. It's also more cost-efficient because if we don't need all those extra ETL jobs and extra views
[18:12] um and maintenance burden of maintaining those um attempts at mimicking fine-grained controls. Um and also now, if you have if you've been fine-grained controls via you via ABAC, you those tables can now be time traveling Delta Sharing. So, all those really important sensitive tables, which
[18:28] could not adopt FGAC because of those blockers, um now can. Now, let's dive into our architecture and how we've actually implemented this. Um There's three pillars that um how we adopted this. So, first is tags.
[18:45] Then you you get your policies. And then a policy attachment. So, tags are your metadata foundation. So, persona here is like the data producer is responsible for tagging the data. And data governance, in this case, would be
[19:01] um responsible for creating the tag taxonomy. So, what does each tag represent and what type of data is suited for that. And then we we then create a policy. This is your governance logic. So, some personas here are data producers if you have like you
[19:17] very use case specific to that table type of um controls. Like you some Usually in HR teams we we we we saw this. You'd be responsible for creating the policy. And for wider ones like governing domains where you mask all PII data within a table domain, um
[19:32] data governance will be creating that. Then policy attachment. So, you have your policy and then you attach it to relevant objects. So, databases or tables. And this is the scoping bridge. So, data producers here would attach the policy to to the data sets if you have those use case specific policies.
[19:48] Data governance we require for attaching those policies to domains. Um and data platform team, us, we responsible for creating the system integration. So, that is creating the relevant tags and policies within the relevant third-party systems. So, this is like govern tags in Databricks.
[20:04] And the enforcement mechanism. So, just providing the mechanism for attaching tags to your data and also applying policies to your data. Um to give you idea of when a user wants to attach a policy, what happens? We have three
[20:21] components here. So, we have fluid which is our user specified config. So, this is a a a YAML file which describes and I'll talk more deeply about this in the next few slides on what the policy actually is, what your table is, what your tags are.
[20:36] And then we have our control plane. Uh we've built our lake. Uh we had our um use cases for building a lake that is declarative and opinionated. And a key part of that is having our data control plane. Um this is not required. I'll talk about
[20:52] other ways that you can implement them. But if you do want to know about our data control plane, I have a talk last year which you can look at and my colleagues 2 years ago who talked deeply about this. And then finally we have our a resource. So, our data control plane ends up provisioning those resources in
[21:08] relevant third-party systems based on the user-specified config. Um I do want to stress that a control plane is not required. There are many different ways to apply policies in ABAC. So, you can use the Databricks UI, which gives you the point-and-click uh
[21:24] tag tag application and creating policies. Um you can use Databricks SQL um to create your policies and also REST API to uh attach those policies or create them or attach tags.
[21:42] So, this is what our user-specified config looks like. This is our language called Fluid. You have your metadata fields. So, this is a table descriptor. So, you have an ID, which allows you to um uh distinctively identify each table, um some fields like name and summaries.
[21:57] And also to tables, you have columns and each column has an ID as well. It's a metadata fields. But for the tagging um aspect here, is we see we have a classifications field. So, this is the set of tags that data governance creates based on some tag taxonomy.
[22:13] So, here we're saying this column, positive test column, has data that is UGC, and it's raw UGC. We also have a tags field. This is for gives you more flexibility and metadata context um if you have a tag that
[22:29] doesn't fit within those tag taxonomy that data governance has provided your organization with. Um it's also used for row reduction. So, when the user specifies this and they submit it to our control plane, what ends up being provisioned is So, you have your table, your columns, and
[22:46] the tags. The govern tags end up The tags end up as a govern tag in Databricks on that column. in Unity Catalog. So, now we have our data tagged. So, now let's create our policy. This is what our policy descriptor looks like. Same deal here. It's YAML, has ID,
[23:01] metadata fields and it operates under two main concepts. You have a conditions and actions. If these conditions are met, perform this action. So here, this is what a masking policy looks like. So you can see we have a type field that
[23:17] declares whether it's a masking policy or a redaction policy. Um we have a conditions which is So this is saying we want to mask all all columns that have the classification UDC raw. It's and people who are allowed to view
[23:34] the unmasked data are people within this group. Um and the actions here is like if this conditions are met, if a column has this tag, what I do with it? We null mask it.
[23:50] And this is what a maps like what these our user specified config maps to in actual ABAC. So this is the sequel for getting a policy. This is about sequel. So we can see that the labels um map to the match columns field. Um the exemption groups field maps to accept clause.
[24:07] And the action is null masking declares determines which UDF is used in the ABAC policy. Uh worth noting that we actually create the policies via REST API. I showed the sequel here just for illustrative purposes.
[24:24] Um and this is what a row reduction just for completeness policy looks like. So we're saying um type column values for um columns that have this tag, if they are the values CEO or CTO, redact them. So the actions. And people who are allowed to see the unmasked data are in that group,
[24:40] something like executive leadership group. Now we end up how do we attach actually attach the policy to data sets? So we also have database fluid descriptors. This just notes what your database wants to look
[24:56] like and we've added a policy field. Um what this does is like it's explicit attachment, so you have to explicitly say we want to attach this policy to this database. We also get automated automated inheritance. So, with ABAC, if you attach an ABAC policy to the database,
[25:11] it will trickle down to all uh tables within that database. Um also logic for the policy is decoupled. It doesn't exist in the database itself. It's in the descriptor that we defined here. And if it ever changes, we just need to change the field in the policy
[25:27] descriptor, and it trickles down automatically um with governance out of the box. If you know your YAML, this is how you declare a list, so we can attach multiple policies here. And ABAC does support multiple policies
[25:43] um as long as the UDF that ends up being resolved is the same. Uh we also allow for more granular scope if you want to attach a policy directly to a table. Uh maybe your data governance team hasn't had um
[25:59] chance to come up with a policy yet for your type of data, you can go ahead of the curve and attach it directly to your table. And what ends up being provisioned by the control plane once a user submits um a descriptor that looks like this is it's an ABAC policy based on the
[26:15] descriptor. So, in this case, we attach to a database on ABAC policy on the database. If it was a table, an ABAC policy attached to the table. Okay, so now finally some real-world examples and outcomes. So, the early use cases
[26:31] uh we now have um so, how we achieve streamlining data access. So, something like you want to comply with inside of financial information. So, you would encapsulate that logic in a UDF, and then data producers So, with the
[26:46] UDF, it needs some inputs from your columns, and those columns need to be tagged with a specific tag. And then are an ABAC row filter policy will redact the rows except for everyone who's in the except clause. And if the sensitive policy logic ever changes, we simply amend the UDF and it
[27:02] will trickle down to all tables that are relevant for that policy. Governing domains, um, we now can have domain policies and I'll walk through on how we actually do this. Um, so now we have we can data governance can go in and be like for all
[27:19] all PII tagged data in the finance domain has to be null masked. What is what we do here is um, all all our databases map up to a domain and if a domain has a policy, all schemas will have an ABAC policy attached to it
[27:35] and the data policy will apply to all current and future tables um, of that domain. And complying with data use policies, um, we have a dedicated dedicated column to determine if this row with a user has
[27:51] like opted out or for data use compliance and then a govern tag govern tag is attached to that special column and then an ABAC row filter policy redacts those opt out rows for unauthorized users. So this is what it looks like if someone
[28:07] wants to attach a domain policy. We have a domain descriptor. Um, so first we have to create a policy. So this is the similar to the policy descriptor we saw earlier and then we have a domain descriptor which has the policies field we saw earlier and then all databases can map up to a
[28:23] domain and then when we our control plane um, resolves and maps the database to control to provision resources, um, it will check the domain if it has any policies and apply apply ABAC policies if they are applicable. Um, some key outcomes that we got from
[28:40] this uh, policy management used to be per table but now it's more automated and centralized. Um, new table protection. So we used to have to apply the policy after the table was created, but now with ABAC, it automatically, um, protects the table via the inheritance model.
[28:56] Um, delta sharing. Now, we can delta share with fine-grained control tables. You also now time travel. And governance used to be fragmented, but now it's unified within Unity Catalog. Here are some production numbers. More than 1,000 tables that are protected by
[29:12] ABAC. Uh, we have 80 plus fluid policies and more than 30 teams adopting, um, ABAC. Some key takeaways and future plans. Scale demands a new governance model. Um, coarse-grained access is, um, losing
[29:29] pace with modern data states and, the inheritance model and attribute-based is the pathway to, um, data governance and access policies at scale. Um, tags are are the foundation. So, taking time and thinking about how you
[29:44] want to construct your tag taxonomy is worth the time and should invest in early on. And abstraction unlocks productivity and data democratization. So, as I said earlier, we define the all the you define the policy once, um, and it trickles down everywhere and
[29:59] every change is you only have to change it only in one place. And we now have a single pane of governance. We used to look at different the tools for which tables are sensitive, what what rules are applied. We just now can it's now unified within Unity Catalog.
[30:14] Some future plans. Um, broader ABAC adoption. So, some tables are using FGAC that are at the table level. This is an artifact of when we used to have native row filters and column masks. So, we want to move those to databases so we have fewer ABAC policies. Um, we should use ABAC for
[30:30] coarse-grained access. Uh, we try to use identity attributes. And, uh, there's a special word, AI, with the data I said AI summit, so I have to mention it at some point. And, um, so non-technical users can create policies using natural language. Um and a sneak peek, but Eric will now
[30:46] come back on and talk about the future road map for ABAC. Thanks, uh Gerald. It's uh Oh, applause. Impressive to see and also how early on Atlassian actually already started doing
[31:03] all of this. They were one of the first customers to do all this at this scale. Um what's coming? I've told you a bit about some of these things before, but just to recap. Like we're expanding this with ground policies. So, not only fine-grained control, but also granting access to tables and other objects
[31:19] directly. Actually, it's already, I think, I'm not sure, private preview, I think, but for models, then you can also use it for the model securable type in UC. Um identity attributes, it's the same as user attributes, some people recognize that word more.
[31:35] But you could basically use the team of a user or the the role of a user, the region of a user, which is a very commonly requested one, and you can actually start syncing that with your IDP as well. So, you just connect your IDP, you probably have it connected already either through SCIM or
[31:52] a new AIM protocol, and attributes flow in automatically, and you can start references referencing them in policies. It's also very powerful for row filters cuz you can basically parameterize the filter based on the value of the user, the attribute value. And then context attributes I showed
[32:08] you, we'll give you the toolbox to basically restrict access when agents are acting on behalf of the user, which is a very commonly requested uh feature these days. And custom classifiers, which basically allows you to tailor this automated
[32:24] agentic data classification that I showed to your specific domain. And I think the I'm sure the the last one is in beta, the other three are having a private preview very soon. So, if you're interested in joining any of these private previews, please let us know.
[32:40] Then the account your account team can reach out or will reach out directly. Um this single QR code works for the interest for all of them. Um thanks. Cool. Thank you, Eric, and thank you, everyone. You must be all very hungry. It's lunchtime. Um
[32:56] Eric and I will hang around if you have any questions. Um we're more than happy to answer any questions that you guys have. Uh thank you very much.

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.