Databricks identity governance fails when access spans workspaces

At a glance

What this is: This is an analysis of why Databricks access is difficult to govern across accounts, workspaces, Unity Catalog, compute, and tokens, with the key finding that identity provider-centric IGA misses material access paths.

Why it matters: It matters because IAM and IGA teams need visibility into effective access, not just directory assignments, if they want to control non-human and human access to data and AI workloads.

By the numbers:

• 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to the Ultimate Guide to NHIs.

Context

Databricks identity governance becomes difficult when access is distributed across accounts, workspaces, Unity Catalog, compute and tokens rather than concentrated in a single identity provider. The primary governance problem is that effective access can be granted in more than one layer, so directory-level reviews do not show the full permission path.

In practice, that creates a visibility gap for both human and non-human access. Security teams need to understand who can reach data, how those grants were made, and whether the resulting access still matches business need across the lakehouse and AI model environment.

Key questions

Q: What breaks when Databricks governance stops at the identity provider?

A: Effective access breaks down because the identity provider cannot fully describe permissions that are created inside workspaces and Unity Catalog. Teams may certify group membership while missing direct grants, nested inheritance and object-level access that still allow data, compute or model reach. The result is a false sense of control over who can actually use the platform.

Q: Why do Databricks personal access tokens create governance risk?

A: Personal access tokens create risk because they can keep authenticating workloads outside normal SSO and MFA enforcement. If tokens do not expire or rotate, they become standing credentials that survive long after the original business need changes. That makes lifecycle oversight just as important as the initial grant.

Q: How should security teams govern Databricks service principals and tokens?

A: Treat them as governed non-human identities with named ownership, expiry, rotation, and offboarding requirements. The key is to separate platform access from human convenience and to review whether each identity still matches a live workload. If a token or service principal cannot be tied to a current business process, it should be removed or reissued under tighter scope.

Q: How do teams know Databricks access is actually under control?

A: Access is under control when effective permissions match intended business use across account, workspace and data layers. Teams should be able to show that dormant users, stale tokens and over-provisioned principals are removed on an ongoing basis, not just flagged in a report. If review findings do not translate into direct revocation, the governance model is not complete.

Technical breakdown

Why identity provider reviews miss Databricks effective access

Databricks does not resolve access solely through the identity provider. Permissions can arrive directly at the workspace, through nested groups, or through object-level grants inside Unity Catalog, which means the effective access path is assembled across multiple control planes. In that model, a clean directory review can still leave a user or service principal with substantial downstream reach. The issue is not that identity governance is absent, but that its visibility boundary is too narrow for the way Databricks actually authorises data, compute and workspace actions. Read the Ultimate Guide to NHIs: Key Challenges and Risks.

Practical implication: Practitioners should validate effective access at the Databricks layer, not only in the directory, before trusting any certification result.

How long-lived tokens bypass normal authentication controls

Personal access tokens and service principal secrets are operational credentials, not SSO sessions. They can continue to authenticate pipelines, notebooks and automation even when human authentication flows are hardened with MFA or conditional policies. That makes them a parallel access plane with its own lifecycle, one that is often invisible to standard identity review cadences. When these tokens do not expire or rotate, governance drifts from who should have access to who can still authenticate. See the Secrets Management Guide.

Practical implication: Practitioners should treat token inventory and expiration as part of access governance, not as a separate secrets-management concern.

Why workspace-level administration fragments control

Workspace administration in Databricks creates a second governance surface that can diverge from account-level policy. If teams manage workspace rights, cluster access and catalog grants separately, standing privilege can accumulate in places that central reviews do not routinely inspect. That fragmentation is especially risky when service principals support ETL jobs, BI integrations or model workflows, because the access often looks operational while still being broad enough to overreach. Governance fails when local convenience outruns central oversight. See the IGA Buyer's Guide.

Practical implication: Practitioners should align workspace administration, catalog entitlements and token inventory into one reviewable access model.

Threat narrative

Attacker objective: The objective is to reach and manipulate Databricks data and AI workloads through access that outlives its intended business purpose.

1. Entry occurs through account, workspace or token-based access that is already valid inside Databricks rather than through classic external compromise.
2. Credential access persists when personal access tokens, OAuth secrets or service principal secrets remain active beyond their intended lifecycle.
3. Escalation happens when over-provisioned workspace roles, nested group membership or Unity Catalog grants extend the actor's reach across data and compute.
4. Impact is realised when stale or excessive access exposes sensitive tables, pipelines, notebooks, models or other lakehouse assets.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Databricks governance fails at the effective-access layer, not the directory layer. Identity provider centric IGA can show who belongs to a group, but it does not automatically resolve the permissions that arrive through workspace roles, nested groups, object ownership or Unity Catalog grants. That means the control failure is structural: the system being reviewed is not the system actually enforcing access. Practitioners should govern the permission path, not the directory label.

Long-lived Databricks credentials create standing access outside the review cycle. Personal access tokens and service principal secrets function as an authentication plane that often escapes SSO enforcement and periodic recertification. In static versus dynamic secrets terms, the problem is not just exposure, but persistence. Access that never expires cannot be meaningfully certified as current. The practitioner implication is to treat token lifecycle as part of identity governance, not as a side control.

Workspace fragmentation creates an identity blast radius across analytics and AI workloads. When access is split between account-level administration, workspace administration and catalog permissions, the blast radius becomes hard to measure and even harder to shrink. That fragmentation matters because the same identity can touch data, notebooks, jobs and models through different grants. The practitioner conclusion is that governance must follow the workload boundary that Databricks actually uses.

Continuous access certification is more defensible than periodic review for fast-changing lakehouse estates. Databricks permissions change through direct grants, group inheritance and token creation, so static review cycles age quickly. A continuous model is not about more activity, it is about keeping pace with a permission graph that changes outside the cadence of traditional IGA. Practitioners should expect access certification to move closer to runtime state than to calendar-based attestation.

Named concept: identity security graph for lakehouse governance. The article points to a model in which account users, workspaces, Unity Catalog grants, compute access and token inventory are assessed as one connected identity surface. That is materially different from isolated admin screens because it shows effective access, not just assigned access. The practitioner takeaway is to evaluate whether your governance model can express connected entitlements across the lakehouse instead of treating each plane separately.

From our research library:

• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: Ultimate Guide to NHIs — Static vs Dynamic Secrets

What this signals

Identity security graphs are becoming the practical answer to lakehouse sprawl: Databricks-style environments now require practitioners to connect account users, workspace roles, Unity Catalog grants and token inventory into one governable picture. The operational lesson is that calendar-based access review is too slow for estates where permissions change through groups, direct grants and service principals.

A continuous model matters most where automation depends on long-lived non-human credentials. When pipelines and notebooks authenticate with tokens that outlast the business need, the control boundary shifts from authentication at login to issuance, expiry and revocation at runtime.

The governance signal is clear: teams that can see only the identity provider will miss the permissions that actually matter inside the lakehouse, so review evidence must include effective access and token state, not just directory membership.

For practitioners

• Map effective Databricks access across all planes Trace permissions from the identity provider into workspace roles, nested groups, Unity Catalog grants and compute usage so reviews reflect actual reach.
• Inventory and age all Databricks tokens Track personal access tokens, OAuth secrets and secret scopes with creation date, expiration date and owner so stale credentials stand out.
• Review service principal permissions against real usage Compare service principal entitlements with audit logs for jobs, pipelines and notebooks, then remove catalog or workspace rights that are never exercised. See the IGA Buyer's Guide.
• Unify account and workspace remediation Use one governance process for disabling users, adjusting group membership and revoking Unity Catalog privileges so remediation does not stall inside each workspace.

Key takeaways

• Databricks governance fails when teams trust directory views that do not reflect workspace, catalog and compute access.
• Long-lived tokens and service principal secrets create standing access that survives outside normal SSO controls.
• The strongest control response is to govern effective access continuously, not to assume periodic identity reviews will catch drift.

Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Key Challenges and Risks · API Key Management Guide · Secrets Management Guide

Key terms

• Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
• Personal Access Token (PAT): A personal access token is a reusable credential that authenticates a user or service to an API without a password. In practice, it inherits the permissions of the owning identity, which makes it a high-value non-human identity when it is exposed, copied, or left valid after the original task is complete.
• Unity Catalog: Unity Catalog is a governance layer for data assets in Databricks. It centralizes access control, auditability, and lineage so teams can register datasets, manage permissions, and query them from shared analytics and AI environments. For observability data, it provides the control plane that makes production traces reusable and governable.
• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.