Hierarchy-based authorization is still an IAM governance problem

At a glance

What this is: This is an IAM governance analysis of hierarchy-based authorization in multi-tenant applications, showing how Cerbos frames descendant and child access through policy-defined roles or dynamic attributes.

Why it matters: IAM, IGA, and platform teams need a maintainable way to govern fine-grained tenant isolation and hierarchical access without turning authorization logic into policy sprawl or unreadable custom rules.

Context

Hierarchy-based authorization is the problem of deciding who can access a node in a tree of data and whether that access should extend to descendants or immediate children. In multi-tenant systems, that problem becomes an IAM governance issue because the same logic must preserve tenant isolation while remaining understandable to auditors and engineers.

Cerbos presents two implementation patterns for this control problem. One keeps hierarchy logic in explicit role policies, while the other shifts the hierarchy into principal attributes and evaluates it through a generic policy. The underlying challenge is not access syntax but whether the authorization model can stay stable as organisational structure and data shape change.

The article uses a multi-tenant analytics platform to show why this matters in practice. Roles, hierarchy depth, and tenant boundaries all interact, which makes hierarchy-based authorization a lifecycle and governance concern rather than a narrow policy-expression choice.

Key questions

Q: How should security teams govern hierarchy-based access in multi-tenant applications?

A: Start by treating the resource hierarchy as a governed entitlement model, not a coding shortcut. Define tenant boundaries, parent-child reach, and exception handling separately, then decide whether the policy should be explicit per role or centralised through attributes. The right design is the one your teams can review, test, and recertify without losing isolation.

Q: Why do hierarchy-based access rules become risky as tenant structures grow?

A: They become risky when business hierarchies start standing in for approved entitlement boundaries. As the number of tenants, roles, and tree depths grows, small modelling choices can create inconsistent access scopes that are hard to audit. The risk is governance drift: the policy still works, but nobody can explain or review it cleanly.

Q: What is the difference between policy-defined roles and attribute-driven authorization?

A: Policy-defined roles encode hierarchy logic directly in named role rules, which makes the model easier to inspect but harder to scale. Attribute-driven authorization moves the access conditions into principal attributes and evaluates them through a generic policy, which scales better but depends on cleaner identity data and tighter runtime controls.

Q: How do teams prevent tenant isolation from breaking in hierarchical access models?

A: Use a separate deny rule for tenant boundaries and do not rely on hierarchy checks to imply isolation. Resource trees can look structurally similar across customers while belonging to different tenants, so the policy must enforce scope independently. That separation is what keeps descendant access from becoming cross-tenant exposure.

Technical breakdown

How descendant and child access is evaluated in ReBAC

Relationship-based access control, or ReBAC, authorises access by checking relationships between a principal and a resource instead of relying only on static role membership. In the Cerbos example, hierarchy() turns a path such as Global > Europe > Germany into a comparable object, while descendantOf() and immediateChildOf() decide whether the requested resource sits below the permitted node or only one level below it. That gives policy authors a way to express nested access without writing bespoke logic for every branch in the tree. The technical issue is not the hierarchy function itself but the consistency of the hierarchy model across tenants, resource types, and policy updates.

Practical implication: Model hierarchy depth explicitly before writing policies, because ambiguous tree semantics quickly become governance debt.

Policy-defined roles versus dynamic attribute-driven policies

Cerbos contrasts two ABAC-style implementations. In the policy-defined approach, role policies encode hierarchy conditions directly, which keeps each role readable but can multiply policy files as tenants and access patterns grow. In the dynamic approach, the principal carries access rules and the policy evaluates them generically, which centralises logic but increases dependence on correct attribute population at runtime. Both patterns are forms of policy-based access control, but they shift complexity to different control points. That choice affects auditability, change control, and the place where errors become visible.

Practical implication: Decide where governance belongs, in policy files or in principal attributes, before you scale the model across many tenants.

Why multi-tenant isolation is the hard boundary condition

Multi-tenant hierarchy-based access is not just about expanding visibility down a tree. It must also prevent privilege from crossing tenant boundaries when resource hierarchies look similar across customers. The Cerbos example uses a deny rule based on tenantId versus resource tenant as the first guardrail, then layers hierarchy checks on top. That ordering matters because hierarchical matching alone does not prove tenant legitimacy. For IAM teams, the real control question is whether the policy model can express both scope and relationship without making one weaken the other.

Practical implication: Treat tenant isolation as a separate control path from hierarchy traversal, not as an implied side effect of ReBAC rules.

NHI Mgmt Group analysis

Hierarchy-based authorization is an IAM governance problem before it is a policy language problem. The article shows that the hard part is not whether the engine can evaluate descendant relationships, but whether those relationships remain comprehensible, auditable, and stable as business structures change. That is an identity governance question because the access model has to survive organisational growth, role drift, and tenant expansion without becoming opaque. Practitioners should judge the model by governance durability, not syntax convenience.

Policy-defined roles create clarity at the cost of policy proliferation. When each tenant or hierarchy pattern gets its own role policy, the access model is easier to read but harder to scale. The governance burden shifts to change management, review, and lifecycle maintenance, which is exactly where IAM programmes get strained. The practical conclusion is that explicitness is useful only when the number of role variants stays bounded.

Dynamic attribute-driven authorization reduces role sprawl but concentrates trust in runtime data quality. The second approach makes the policy layer generic and pushes variation into principal attributes, which is attractive when tenant count and hierarchy depth grow. That also means entitlement correctness depends on the quality of upstream attribute population, mapping, and governance. The issue for practitioners is not whether attributes are powerful, but whether their source of truth is controlled tightly enough to support access decisions.

Tenant isolation and hierarchical reach are separate governance controls, not one combined control. The article’s deny-by-tenant pattern shows that a resource can be structurally inside the right hierarchy and still belong to the wrong tenant. That distinction matters for modern IAM and IGA design because scope control and relationship control fail in different ways. IAM teams should keep the two controls independently testable, reviewable, and reportable.

Hierarchy-based authorization becomes brittle when organisations confuse business structure with entitlement structure. A geography tree or business-unit tree is not automatically an access model; it is only a context that the access model consumes. The named concept here is hierarchy-to-entitlement drift: when business hierarchies are reused as if they were already approved access boundaries. Practitioners should treat that as a governance design risk and not a modeling shortcut.

What this signals

Hierarchy-to-entitlement drift: the main risk in this pattern is assuming that business structure can double as access structure without extra governance. Once that happens, review teams inherit policies that are technically valid but operationally difficult to justify, especially across tenants and nested resource trees.

IAM programmes should expect more pressure to prove why a principal can see descendants, children, or only a single level of hierarchy. The practical test is whether policy changes can be reviewed as entitlement changes, not just as code changes.

For practitioners

• Define hierarchy semantics before policy authoring Specify what counts as self, child, immediate child, and descendant for each resource tree so policy authors do not improvise different meanings in different roles.
• Separate tenant isolation from hierarchy traversal Keep a distinct deny rule for tenant boundaries and a separate allow path for descendant access, then test them independently during review.
• Choose the governance home for access logic Decide whether hierarchy rules belong in static role policies or runtime principal attributes, and document who approves changes to each layer.
• Validate attribute source quality Check that tenantId, hierarchy_path, and related principal attributes are populated from governed sources before they influence access decisions.
• Limit role variants where hierarchy is stable Use explicit policy-defined roles only for small, predictable hierarchies, and avoid adding new role files when the same access pattern repeats across tenants.

Key takeaways

• Hierarchy-based authorization is an IAM governance problem because access scope, hierarchy depth, and tenant boundary control all have to stay auditable together.
• Cerbos’ two patterns show the trade-off clearly: explicit role policies improve readability, while dynamic attributes improve scale but raise trust in runtime data quality.
• The strongest control design keeps tenant isolation separate from hierarchy traversal and makes both parts independently reviewable.

Key terms

• Hierarchical Authorization: Hierarchical authorization assigns access to a stable parent resource such as a workspace, collection, or project, and lets child objects inherit that decision. It reduces policy volume, keeps revocation manageable, and matches how users usually understand access boundaries in enterprise systems.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
• ReBAC: Relationship-based access control grants access by evaluating paths through relationships between subjects, resources, and intermediary objects. It is useful when permissions depend on how things are connected rather than on simple roles alone, but its runtime cost depends heavily on graph shape and traversal strategy.
• Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.