Unified Governance at Scale: InMobi's Attribute-Based Access Control

Summary

InMobi, a global ad tech company reaching over 2 billion users and serving 250 billion ad requests daily, eliminated audit risk and policy drift from eight separate governance touch points by centralizing policy enforcement in Databricks Unity Catalog as the single authoritative control plane.
A configuration-driven attribute-based access control architecture based on the NIST ABAC standard enforces row-level and column-level security across dashboards, notebooks, ad-hoc SQL, and AI agents like Genie, with user identity propagated end-to-end from front-end to catalog through OAuth.
Automated reconciliation jobs maintain desired governance state, user onboarding was reduced from weeks to a single SQL insert, and agentic use cases inherit governance automatically because policies are enforced at the Unity Catalog table level regardless of which tool queries the data.

Unified Governance at Scale: InMobi's Attribute-Based Access Control

Managing governance across eight separate touch points for over 2 billion users and 250 billion ad requests daily created audit risk, policy drift, and operational bottlenecks. InMobi solved this by implementing a unified governance architecture using Databricks Unity Catalog as the authoritative control plane, with configuration-driven attribute-based access control (ABAC) enforcing row-level and column-level security.
Learn how to standardize governance across dashboards, notebooks, ad hoc SQL, and AI agents like Genie without rebuilding policies at each layer. Explore the NIST ABAC standard, identity propagation from front-end to catalog, policy storage as queryable data tables, and automated reconciliation jobs that maintain desired state. See how InMobi reduced onboarding from weeks to a single SQL insert and discovered that agentic use cases inherit governance automatically when policies are attached at the table level.
🤝

Chapters

FAQs

What is attribute-based access control (ABAC) and how does InMobi implement it on Databricks?

Attribute-based access control is a governance model defined by the NIST standard where access decisions are based on attributes of the user, the data, and the context of the request rather than static role assignments alone. InMobi implements ABAC using Databricks Unity Catalog with policies stored as queryable data tables, where mapping tables resolve user attributes to the appropriate row and column visibility at query execution time.

How does InMobi enforce row-level and column-level security in Unity Catalog?

Row-level security is enforced through mapping tables and row filter functions applied at query time based on the authenticated user's group membership and attributes propagated through OAuth from the front-end system. Column-level security uses dynamic masking policies that return either the real column value or a masked substitute at read time, protecting sensitive data without modifying the underlying stored values.

Why did InMobi consolidate governance into Databricks Unity Catalog?

Before consolidation, InMobi maintained governance across eight separate touch points including dashboards, warehouses, notebooks, SQL interfaces, and Excel sheets, making it impossible to answer audit questions quickly or ensure consistent policy enforcement when users changed teams. Unity Catalog as a single authoritative control plane means any governance change propagates everywhere simultaneously, eliminating the policy drift that previously stalled dashboard releases for weeks.

How does InMobi's Unity Catalog governance architecture handle AI agents like Genie?

Because InMobi's access policies are enforced at the Unity Catalog table level using row filters and column masking functions, any AI agent or Genie space querying those tables automatically inherits the governance rules without requiring separate policy configuration for each new consumer. This means agentic use cases cannot surface data the querying user is not permitted to see, regardless of which interface or tool they use to access it.

Full transcript

[00:08] Hi everyone. I'm Anand. I'm a staff engineer at InMobi. And we are a part of central data platform team. We build AI and data solutions for us of the InMobi. So, a quick context about what scale
[00:23] InMobi operates on. InMobi is a global ad tech company. We reach to over 2 billion people serving 250 billion ad requests every day. And we ingest close to 240 terabytes of
[00:38] data every day. Glance, which is a AI commerce subsidiary, it is currently live in 140 plus countries. So, the scale is important to know because at this scale we are solving the problem of
[00:54] governance. Let me deep dive into the problems which we faced. This was our reality. There were eight places at which we had to maintain governance for different user groups.
[01:11] With the advent of AI, the old question, who sees what, became a priority. We had to solve this so that we could enable our agentic use cases on top of the data which is exposed across multiple touch points.
[01:28] Be it any AI dashboard, be it any warehouse, or be it uh a ad hoc SQL interface, notebooks, Excel sheets, we had to maintain the governance across all of these places. And imagine, now if someone changes one
[01:44] team to another, how to replicate the access across all of these touch points? Multiple touch points means multiple stakeholders. We couldn't bring all that data or all that governance at a central place. So, our goal was to have a unified
[02:00] state. But, because of the distribution of policies across different places, we were unable to get there. We were paying three cost. One was the audit risk.
[02:16] Do When anybody ask us question that who access what data, it took us days for us to answer because it has to be scattered across multiple places. Our policies were drifted. And
[02:32] because of that, our velocity also increased. Our business was getting stalled as we couldn't release a dashboard within a given time. It took us weeks for us to see release a dashboard to ensure that in that dashboard, who
[02:50] have access to what type of data. And with the AI exposure, if we plug on any genie or any AI agent on top of that, we will never know that what data it surfaces up.
[03:10] So, these were the three bets which we did. My talk is all about all these three bets. First, views. We exposed all our data via views. We ensured nobody have access to the tables.
[03:25] Why? Why views? Because view served as a contract between what we exposed to our consumers. Any table which has to be which data has to be exposed via view, we we we were able to control
[03:42] which columns get exposed. Uh if there are any columns which are relevant for data pipeline, then those can remain hidden. Another thing which is also helped is it abstracted any joins which has to be done
[03:58] and that doesn't need us to consumers to know about it. Policies has data. Our policies are not any config or any vendor provided solution. Our policies reside in a table
[04:14] which could be queried by any person which stays at one single place which doesn't need any front-end information and it remains a source of truth for any audit related queries as well.
[04:32] Third bit, identity propagates. From any front-end to back-end we ensure the user who is consuming the data his or her identity gets propagated till the very end.
[04:48] How we did that? Is something we'll deep dive on. So, what we solved is a standard. It's a NIST standard and it's called attribute-based access model.
[05:04] When we initiated to solve this problem we only focused on how to solve it for our use case. But when we arrived we later realized it actually converges to a real standard.
[05:19] This standard has four components. One is policy administration. Basically, where we define what what is the policy definition. Second, policy information, where we store the policy. Third, policy decision, where the policy
[05:36] gets computed. And fourth is policy enforcement, how the policy gets enforced on the data assets. This is how it actually reflects in our implementation. So, on the left you see the writer path.
[05:53] On the right you see the reader path. On the left it is the admin UI for the domain teams who can now control and define what policies has to be defined for a given data set.
[06:10] And it writes to the mapping tables. So, these mapping tables are the ones where which are actually our policy information tables. So, these tables will be the source of truth during the reader flow. On the reader flow
[06:26] you have Unity Catalog which is our policy enforcement where the policy get computed. And Unity Catalog invokes the row-level security and column-level security functions
[06:41] which during run time refers to the same mapping tables which are returned during the write flow. I'll come to the reconciliation job in the next slide.
[06:57] So, now imagine our end-to-end flow where user is interacting with a dashboard or maybe it is asking a query from Genie. Be it any interface the flow remains the same. Step one, where user logs in or fires any query
[07:13] in that case the user's identity is fetched. That user identity is then mapped with the Databricks OAuth token. That token reflects user identity. It is not any service principle. It is
[07:29] the user's identity which is getting tracked. That user identity flows to the catalog. Catalog does the role of getting the right view to which user have access. As I clearly previously mentioned that
[07:44] we don't have provide access to tables, it is only that views to which we provide access. So, catalog does that part. RLS module RLS functions figure out for that particular user for the given view which rows are accessible.
[08:00] And only those rows are filtered and sent back. CLS module takes care of which columns are accessible by the user.
[08:16] So, now if it is a dashboard, if it is a notebook, or if it is any ad hoc SQL interface, or even if it is a Genie, the front end doesn't take any control of what the Unity Catalog RLS CLS modules are doing because those are reading information from the policy
[08:32] store and not from front end as against to previous problems. This is how we have implemented role-level security. It has three components to it. First is the mapping table.
[08:48] The mapping table has a row discriminator. So, the first column user email ID was our row discriminator in one of the use case. It can be any row discriminator which you can think in which your rows has to be accessed by the end user.
[09:04] The division and cost owner, the call these columns are attributes. Attributes on which the rows has to be discriminated against. So, this mapping table is used So, this this mapping table is written during the writer flow and it it it gets used in
[09:22] the reader flow, which is a row filter function. So, in row filter function, it is referring to the mapping table. It is checking the user email ID with the current user. And it is then filtering the data
[09:39] according to the attribute which is mentioned. So, I have listed their white list and black list in both ways how that can be implemented. None means no restriction here at all. So, you are free to configure the row
[09:55] level access in whichever way you want. Whether it should be a white list, it should be a black list, or it shouldn't be it shouldn't have any filtration or at all. The third part, the binding part is where you attach that row level
[10:12] filter to the underlying table. And here I want to highlight that this gets attached at a table level. So, now your user is exposed with the view, but your policies are attached at a table. So, that also abstracts the implementation detail. Your users need
[10:28] not know what are your implementation details. Similarly, on the column security front. So, for column security so, these are the roles and for the corresponding tables, which columns need to be masked.
[10:44] So, this mapping table is then referred by the mask field, which is the run time function. So, that run time function takes care of user belonging to which role and which column to be masked. So, as we can rightly see for any
[11:00] example, analyst uh any PA prod admin that role if any user is part of PA prod admins then that column has to be returned as null. Again, the binding part binding part is something
[11:18] which gets again attached to the table. Now, you have to talk about the reconciliation job. So, all the alter statements which we saw on the bottom those are part of our reconciliation job. Your mapping tables
[11:34] are the source of truth for enforcing these policies. Any binding which has to be done on the table are fetched from the mapping table and there is a hourly job which fetches all this policy and mentions the desired state
[11:50] which has to be applicable across all the tables. There were two options. Either it could be event-driven system or it could be a reconciliation job. Event-driven system has its own disadvantages where you could also need
[12:06] to do a retry if the event is not handled correctly. So, we stick to the reconciliation job. This is actually a Kubernetes model where you just define the end state and even if in between somebody alters or
[12:23] changes any permission then it doesn't impact the end state. When we implemented this we also wanted to enable Superset as our
[12:38] stack. But, Superset didn't have the capability where it could pass through the user information using Databricks OAuth. Power BI did. And so, we fixed Superset.
[12:54] We implemented user credential pass through in Superset and we contributed it back and this is the PR link for that. If anybody wants to use Superset for their use case using Databricks OAuth they can use this
[13:10] PR which is available on Superset's Git repo. These are our impact. These are the numbers from our production. Across different use cases, sales, finance, people analytics which is HR analytics
[13:26] we have multiple dashboards which are live. The numbers have gone beyond this. We have many folks, hundreds of folks who are leveraging this and we have across multiple teams, this is currently live.
[13:44] One thing which mattered most to onboard any analyst or any analyst team, it earlier used to take weeks to give them these touch points across different data sets. But now it is just a matter of one single insert.
[14:01] When we onboarded our Genie or any agentic use case, we were surprised to see that we didn't had to implement anything on the governance front. It was already taken care of. Genie, only we had to configure on the Genie spaces, provide the metrics view,
[14:17] but on the governance front, because it was attached to the corresponding tables, the policies were getting added to that. This was the takeaway message which I wanted to give. Put your policies into a table
[14:32] and let your user credentials flow from any interface to the catalog. That's about it. Thank you guys. Thank you for attending.

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.