What tool can show where user access no longer matches what a role actually needs?

Summary

• The tool has to compare two things: what a user is granted and what that user actually touches. Where the grants are far wider than the usage, access has drifted past what the role needs.
• On Databricks, Unity Catalog keeps every grant in one authorization engine, and two system tables do the work: system.information_schema is the grant inventory and system.access.audit is the record of what was actually used.
• Automatic data lineage shows whether a table with granted access has any downstream use, separating real dependencies from dead grants.
• The Databricks Security Analysis Tool ships an over-privileged principals report and a "who can access this?" reverse lookup, so you can flag and rank excess access, then revoke it.

What tool can show where user access no longer matches what a role actually needs?

The tool has to compare two things: what a user is granted, and what that user actually touches. Where the grants are far wider than the usage, access has drifted past what the role needs. So the answer isn't a single dashboard, it's a system that keeps a live inventory of every privilege, logs every real access, and diffs the two so you can revoke the excess. On Databricks, that comes from Unity Catalog together with system tables (the grant inventory and the audit log) and automatic lineage, plus the Databricks Security Analysis Tool for a ready-made over-privileged report.

What access drift is

Roles get defined once, and then reality moves. People change teams, cover for absences, run one-off projects, and inherit access through group membership, and the grants rarely get cleaned up afterward. The result is privilege creep: a user, a service principal, or an AI agent holds permissions well beyond the job in front of them. Every unused grant is standing risk, an account that can read data it never needs to see. Finding drift means answering three questions for each principal: what can they access, what have they actually accessed, and what should the role require.

What to look for in an access-review tool

Capability	Why it matters
Complete grant inventory	You can't right-size what you can't see. The tool has to enumerate every privilege, including access inherited through groups and hierarchy.
Actual-usage logs	Granted-but-never-used is the signal for drift, so you need an audit trail of who read what and when.
Grant-to-usage comparison	Overlaying entitlements on real activity is what surfaces excess. Neither view alone tells you.
Drift over time	Snapshotting grants and diffing successive snapshots shows what was added or removed, so new over-provisioning gets caught early.
Reverse "who can access this?" lookup	Starting from a sensitive table and listing every principal that can reach it exposes unnecessary paths.
Lineage	Seeing how data actually flows downstream separates legitimate dependencies from dead grants.
Direct remediation	Findings should lead to a revoke or a regroup, ideally by managing access at the group level.

How Databricks approaches finding excess access

Unity Catalog is the single authorization engine for data and AI on Databricks, so every grant lives in one place instead of scattered across tools. Two system tables do the heavy lifting. system.information_schema exposes the current privileges on every catalog, schema, table, and volume, which is your grant inventory: snapshot it on a schedule and diff the snapshots to detect drift, meaning privileges added or removed. The audit log, system.access.audit, records the real actions, so you can query which users actually ran reads against a given table over a window. Where a principal holds a privilege that the audit log shows they never exercise, that's the excess to review.
Data lineage is captured automatically across SQL, Python, Scala, and R, so you can see whether a table with granted access has any downstream use at all. For a packaged view, the Databricks Security Analysis Tool (SAT) turns permissions into a queryable graph and ships an over-privileged principals report that flags accounts with broad grants (for example, ALL PRIVILEGES across many catalogs) and ranks them by risk, plus a "who can access?" reverse lookup. To remediate, revoke the unused privileges and manage access through groups rather than one user at a time, and use attribute-based access control (ABAC) with governed tags so policies follow data by classification instead of being reapplied object by object.

Use cases

• Access certification: give each data owner the grant-to-usage view for their objects so reviews are evidence-based, not rubber stamps.
• Joiner-mover-leaver cleanup: catch permissions that lingered after someone changed roles.
• Audit and compliance prep: produce a defensible record of who could reach sensitive data and who actually did.
• AI agent right-sizing: apply the same grant-to-usage test to service principals and agents so an automated identity can't read beyond its task.

FAQs

How do you tell needed access from excess access?

Compare entitlements to activity. system.information_schema shows what a principal is granted; system.access.audit shows what they actually used. Privileges granted but never exercised over a meaningful window are the candidates to revoke.

What is privilege creep?

It's the gradual buildup of permissions beyond what a role needs, usually from team changes, temporary projects, and access inherited through groups that never gets cleaned up. Each stale grant widens the attack surface.

Does this work for service principals and AI agents, not just people?

Yes. Unity Catalog governs users, groups, service principals, and agents the same way, so the grant-to-usage comparison and the reverse-access lookup apply to non-human identities too.

How do you keep access from drifting again?

Grant to groups instead of individuals, snapshot grants on a schedule to catch new drift early, and use ABAC with governed tags so access tracks data classification automatically as new objects appear.