Stop Guessing: Build a “Who Has Access to What” Dashboard

By now, a few things should be clear:

Your access model isn’t a hierarchy – it’s a graph.
That graph contains hidden exposure paths.
And those paths can be measured using real signals.

That’s a solid foundation.

But there’s still a gap:

You can’t manage what you can’t see.

SQL queries are great for analysis.
They’re terrible for understanding a system at a glance.

If you want to control access, you need to make it visible.

What This Dashboard Is (and Isn’t)

This is not a compliance dashboard.
It’s not a list of roles.
And it’s definitely not a vanity metrics page.

This is simply a visibility layer over your access graph.

It should answer questions like:

Who can access this dataset?
How did they get that access?
Where is access overly concentrated?
What looks wrong immediately?

If it doesn’t answer those, it’s just decoration.

The Core Views That Actually Matter

You don’t need 20 visuals.

You need a few that make the system understandable.

User → Role → Object Mapping

This is your foundation.

At a minimum, you need to trace:

User → Role → (Inherited Roles) → Object

Most tools stop at direct relationships.

That’s the problem.

Your dashboard needs to show effective access, not just assigned access.

Object Exposure View

Flip the perspective.

Instead of asking “what can this user see?” ask:

“Who can see this object?”

Example query pattern:

SELECT
    name AS object_name,
    grantee_name AS role,
    privilege
FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
WHERE privilege = 'SELECT';

What you’re looking for:

Objects with a high number of roles
Shared datasets with unclear ownership
Anything that feels “too accessible.”

These are your risk hotspots.

Role Inheritance Graph (This Is the One That Will Shake Things Up)

This is where the illusion breaks.

Visualize roles as nodes and grants as edges:

Role → Role relationships
Deep inheritance chains
Shared roles across multiple domains

Once you see this, you stop guessing.

You start understanding.

Risk Score Overlay

Now layer in what you built in Post 3 (Insert link here)

Assign a risk score to:

Roles
Objects
Domains

Based on:

Exposure
Inheritance depth
Stale access

Now your dashboard doesn’t just show structure.

It shows priority.

What This Looks Like in Practice

A useful dashboard will let you:

Click a user and see all reachable data
Click a table and see all access paths
Click a role and see inheritance and dependencies

And most importantly:

Spot something that doesn’t feel right within seconds.

That instinct is valuable.

Most systems bury it if they show it at all.

A Simple Architecture That Actually Works

You don’t need a new platform.

If you’re using Snowflake, the data is already there.

At a high level:

Pull from system metadata
Build relationship mappings
Flatten into something usable
Visualize it in a tool your team already uses

That’s it.

The complexity is in the relationships – not the tooling.

The One Table That Changes Everything

If you build nothing else, build this:

A table that represents effective access paths.

Conceptually:

user_name
role_name
inherited_role
object_name
access_path
depth

This turns your access model into something you can:

Query
Visualize
Score

Without it, everything stays fragmented.

What Most Dashboards Get Wrong

Let’s save some time.

Most access dashboards fail because they:

Show raw grants instead of effective access
Focus on completeness instead of clarity
Try to visualize everything at once
Ignore inheritance depth
Don’t highlight risk

The result is technically correct…

…and practically useless.

What “Good” Actually Looks Like

A good dashboard should:

Make hidden paths visible
Highlight anomalies quickly
Prioritize risk automatically
Support exploration, not just display

If it doesn’t do those things, it’s just a report that is filed away for someone to never look at again.

Where This Leads

Once access is visible, something shifts.

You stop reacting to problems.

You start preventing them.

Because patterns become obvious:

Roles that shouldn’t exist
Access that’s too broad
Objects that are overexposed

And now you can act before AI – or anyone else – finds those paths first.

Next in the Series

So far, we’ve:

Identified the problem
Understood the structure
Measured the risk
Made it visible

Now comes the part most teams struggle with:

Fixing it – without slowing everything down.

How to clean up access control without breaking your data platform.