Your Role Hierarchy Is Probably Lying to You

Most data platforms look clean on paper.

Roles are defined.
Permissions are assigned.
Access flows in a structured hierarchy.

It’s logical. Predictable. Auditable.

At least, that’s the idea.

In reality, the access model you think you have and the access model you actually have are more than likely two very different things.

And the gap between them is where most data exposure risk lives.

The Model We Think We Have

Most systems are designed around a simple structure:

Users are assigned to roles
Roles are granted permissions
Permissions control access to objects

A clean, layered model:

User → Role → Permission → Object

It’s easy to explain.

It’s easy to diagram.

And it creates the illusion that access is controlled and traceable.

The Model We Actually Have

In production environments, access doesn’t stay linear.

It evolves.

Roles get granted to other roles.
Permissions get layered across multiple levels.
Exceptions get added to keep things moving.

Over time, the model becomes something closer to this:

User → Role A → Role B → Role C → Object
↘ Role D ↗

Not a hierarchy.

A graph.

And that distinction actually matters.

Because hierarchies are fairly easy to think through.

Graphs are not.

Where Things Start to Break

There isn’t a single failure point.

Access control degrades through a series of completely reasonable decisions.

1. Role Chaining Without Visibility

A role is granted to another role to simplify access management.

Then that role gets reused somewhere else.

Then it gets extended again.

Eventually, you have chains of inheritance that look like:

ANALYST → DATA_SCIENCE → SHARED_ACCESS → PROD_READ

No one decision was wrong.

But very few people can trace the full path from user to data.

2. Reuse Without Context

Roles get reused because it’s efficient.

But roles carry history with them.

A role originally designed for one purpose gets applied in another context -without fully understanding what it already includes.

So instead of granting just enough access…

You grant everything that role has accumulated over time.

3. Local Fixes That Become Global Access

A pipeline breaks.

A report fails.

Someone needs access quickly.

So a role gets a new “temporary” permission.

Problem solved.

Except that role is used in five other places.

Now five different user groups have access to something they didn’t have before.

4. No One Owns the Full Picture

Different teams manage different parts of the system:

Data engineering manages pipelines
Analytics manages reporting
Security manages policies

But access spans all of them.

Which means:

No single team has a complete view of effective access across the platform.

Why This Breaks Traditional Auditing

Most access reviews rely on snapshots:

Who has this role?
What permissions does this role have?

But those questions assume access is static.

In reality, access is:

Inherited
Layered
Context-dependent

Which means the real question is:

What can this user actually reach through all possible paths?

That’s not a lookup.

That’s a traversal problem.

Seeing the System for What It Is

Once you stop thinking in hierarchies and start thinking in graphs, everything changes.

Access is no longer:

A list of roles
A set of permissions

It becomes:

A network of reachable paths between users and data.

Some paths are on purpose.

Some are side effects.

Some shouldn’t exist at all.

Simple Example (Snowflake Metadata)

You can start to see this shift using metadata.

For example, looking at role-to-role relationships:

SELECT
    ROLE AS child_role,
    GRANTED_TO AS parent_role
FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
WHERE GRANTED_TO = 'ROLE';

And then layering object access:

SELECT
    grantee_name,
    privilege,
    name AS object_name
FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
WHERE granted_on IN ('TABLE', 'VIEW', 'DATABASE');

Individually, these queries are simple.

But the insight comes from connecting them.

Because that’s what your access model really is:

A connected system—not a flat structure.

What This Means in Practice

If your access model is a graph:

You can’t validate it with static reports
You can’t understand it by looking at one role at a time
You can’t confidently answer “who has access to what” without tracing paths

And that’s exactly where most organizations are today.

Where This Leads

Once you accept that access is a graph, the next step becomes obvious:

You need a way to analyze it like one.

Not just list roles.

Not just audit permissions.

But:

Map relationships
Identify high-risk paths
Measure exposure across the system

Next in the Series

In the next post, we move from structure to measurement.

Because once access is modeled as a graph, you can start asking better questions. Questions like:

Where is access overly concentrated?
Which roles create the most exposure?
What patterns indicate real risk vs normal complexity?

And most importantly:

How do you quantify something that was never designed to be measured?