Effective access

Effective access is the question the Databricks console can't answer directly: who can actually reach this data, through every path, and how.

Why it's hard by hand

A grant on a table is easy to see. But real reach is transitive:

  • A user is a member of finance-analysts, which is nested inside platform-admins, which holds ALL_PRIVILEGES on a catalog.
  • A service principal has a direct grant on one schema and inherits three more through a group.
  • A B2B guest shows up under a raw Entra UPN that doesn't match their email.

To answer "who can read main.finance.salaries," you have to resolve every group, every nesting level, every inherited grant, and normalize identities. Mortar does that resolution and shows you the answer with its paths.

Two lenses

  • Principal → what they can reach. Type a person or service principal and see every catalog, schema, table, and object they can reach, the path to each, the privilege level, and (when usage is tracked) whether they've actually used it.
  • Object → who can reach it. Type a catalog or table and see every group and principal that can reach it, ranked by risk.

What Mortar resolves

  • Group nesting - membership through nested groups, to any depth.
  • Account-level identity - groups are account-level, so the same group is one entry, not one-per-workspace. See the access model.
  • Guest identities - Entra B2B guest UPNs are decoded so a guest resolves by their real email.
  • Admin reach - metastore, account, and workspace admins are surfaced as what they really are: standing power over the data at that level.
  • Non-UC securables - jobs, clusters, warehouses, pipelines, secret scopes, and storage credentials, alongside UC grants.

The access model

Mortar models Databricks access truthfully:

  • Groups are account-level. The (workspace, group) pairing is a scan artifact, not the truth.
  • Scope belongs to the grant - account, metastore, or workspace. Power does not flow between levels: a metastore admin governs all UC data in that metastore; a workspace admin governs workspace objects, not UC data.
  • UC grants are metastore-scoped, not workspace-scoped. A single over-granted catalog on a shared metastore is one exposure, not N.

"Reaches workspace W" is always derived, with its path - never assumed.

Comparing and cloning

  • Compare two principals to see joiners, movers, and leavers - what access differs between them.
  • Clone access ("make the new hire look like Alice") previews the group membership delta and routes it through the change queue - no new write path.