Immuta + Databricks Unity Catalog: A Better Way to Scale Data Access
Every organization wants more people using data to make better decisions. AI tools and agents are making that possible by helping business users get answers from data faster.
But easier data consumption creates a new access challenge, and most organizations are still solving it the old way.
Consider a finance analyst who wants to ask Claude for trends about top customers. The data is in Databricks, but the analyst does not yet have access. In many organizations, that kicks off a familiar process:
- IT creates a Databricks account for the user.
- The user submits a data access request through ServiceNow or Jira.
- Once approved, engineering adds the user to an Azure AD group.
- If the analyst needs access to another dataset, filtered row, or masked column, the process starts again.
- At recertification or audit time, governance teams piece together who had access, why they had it, who approved it, and whether access is still appropriate.
That process also does not account for how the agent itself was set up: whether it uses a service account or has its own identity, what permissions it has, and how its activity is audited.
This model may work for a small group of technical users. It does not scale when hundreds or thousands of business users and AI agents all need access to Databricks data.
The result is predictable: slower access, more manual work, more groups, more standing permissions, more platform accounts, and more audit complexity.
Immuta gives Databricks Unity Catalog customers a better way.
1. Replace ticket queues with self-service access
In most organizations, users request access to data through ServiceNow or Jira. A steward reviews the request and decides whether to approve it. If approved, engineering adds the user to an AD group. If the group is broader than needed, access is over-provisioned. If the right group does not exist, a new one is created for each access permutation.
That process is slow for users, repetitive for stewards, and operationally heavy for platform teams. Over time, it creates request backlogs, group sprawl, and confusion about which groups grant access to what, who approved them, and whether members still need access.
The Immuta difference
Immuta replaces that process with self-service access workflows and dynamic policy enforcement using Databricks-native controls.
Instead of asking engineers to create a new AD group or manually update permissions, users and agents can request access to the exact data they need from the tools they already use, including Databricks Unity Catalog, Claude, Atlan, or Slack.
That request could be for a full data product, a specific schema or table, certain rows, or a temporary exception to view masked data. Immuta applies the right policy and workflow automatically:
- Low-risk requests can be approved automatically.
- Sensitive requests, like access to masked columns, route to the right reviewer with the right context.
- Temporary access is revoked when it expires.
- Every request and decision creates an audit record.
This means faster access for users and agents, fewer repetitive approvals for stewards, fewer groups for platform teams to manage, and more confidence for governance teams that every approval is recorded and temporary access will be removed when it expires.
2. Give Databricks accounts to your agents, not every human
Consider the finance analyst asking Claude, “Who are our top customers, and what trends should I know about?” They do not need to log in to Databricks for that answer. They need a governed way for Claude to retrieve the right answer from Databricks data.
Most organizations try to solve this in one of two risky ways:
- Impersonation: The agent authenticates as the user and inherits that user’s standing Databricks permissions.
- Shared service account access: The agent queries Databricks through a generic service account with broad permissions.
Both approaches create governance problems. Impersonation can give the agent too much access and muddy the audit trail. Shared service accounts hide the user and business context behind generic credentials. In both cases, access becomes too broad, too permanent, and too hard to explain later.
The Immuta difference
Immuta separates data access from platform access, so a user does not need a Databricks account just to get an answer from Databricks data. Instead, Immuta uses an on-behalf-of model that evaluates the full context: the user, the agent, the Databricks data, and the policies that govern all of it.
If the user already has the right access, Immuta vends the agent a short-lived, scoped role to retrieve the approved data on the user’s behalf — only for as long as needed to answer the question. If more access is needed, such as access to a masked field, restricted customer segment, or data outside the user’s region, Immuta can trigger a request workflow to provision that access quickly and safely.
Because both the agent and user are governed by Immuta, the agent can only operate where those permissions overlap. That means two users asking the same question may get different data back based on what they are allowed to see. And even if a user has broad access, the agent still cannot exceed its own governed boundaries.
For compliance and audit, that distinction matters because teams can see who asked the question, which agent acted on their behalf, what data was accessed, and what policy applied.
3. Stay audit-ready continuously, not just at audit time
When access is managed through tickets, email threads, sprawling groups, and platform accounts, compliance becomes a reconstruction exercise.
A simple question like “Who has access to PII?” can turn into days of work. One team pulls ServiceNow tickets. Another checks Azure AD groups. Someone else reviews Databricks permissions and query logs. Then governance has to connect it all back to who requested access, who approved it, what policy applied, and whether access is still needed.
That should not take six days and a team of analysts.
The Immuta difference
Immuta Comply gives teams one place to understand access, activity, and risk.
Teams can ask plain-language questions of their audit data and get answers in seconds:
- Who has access to PII?
- What data is overprovisioned?
- Which users or agents accessed sensitive data?
- What sensitive data should be masked but is not?
Because Immuta connects requests, determinations, policies, and activity, compliance becomes continuous instead of something teams scramble to prove at audit time.
Time-bound access makes this even stronger. If someone gets temporary access or a masking exception, Immuta automatically revokes it when it expires. That means fewer stale permissions, fewer cleanup projects, and fewer risky exceptions sitting around for the next audit.
Have data on other platforms?
Most organizations do not keep data in one place.
Immuta integrates with Snowflake, Databricks, Amazon S3, Azure Synapse, Google BigQuery, Starburst, and more. Teams can define policy once and enforce it consistently across supported platforms with the same masking and guardrail rules, access workflows, and audit trail wherever data lives.
