Topic starter
14/08/2026 6:35 pm
TL;DR: PlainID explains that ReBAC checks whether a requester is connected to a resource through ownership, membership, or delegation rather than a static role, and this matters because modern authorisation often follows relationships that roles cannot express. The limitation is that ReBAC still needs a policy layer when access must also account for context, intent, or regulated decision-making.
Editorial analysis by NHI Mgmt Group, based on content published by PlainID: “What Is Relationship-Based Access Control (ReBAC)?”.
Key questions
Q: How should IAM teams decide where ReBAC belongs in an authorisation model?
A: Use ReBAC when access naturally follows ownership, membership, delegation, or inheritance.
Q: Why do relationship-based permissions still need a policy layer?
A: Because a relationship path only proves connectivity, not whether access should be allowed under current conditions.
Q: What breaks when ReBAC data falls out of sync with the source application?
A: The authorisation engine starts making decisions on stale relationships, so users may keep access they should have lost or lose access they should still have.
Practitioner guidance
- Map access patterns by relationship type Inventory where access is really driven by ownership, membership, delegation, or inheritance instead of role assignment.
- Separate relationship data from policy logic Treat the graph as the relationship source of truth and keep context, sensitivity, and business rules in the policy layer.
- Test authorisation with stale-relationship scenarios Simulate delayed updates, changed ownership, and moved team membership to see whether decisions still reflect the current state.
Bottom line: ReBAC makes access decisions more natural when permissions follow relationships instead of fixed roles.
What's in the full article
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- Examples of how Zanzibar-style relationship graphs are implemented at scale
- The article's fuller comparison of RBAC, ABAC, ReBAC, and PBAC
- The maturity progression from roles to attributes to policy and intent-based control
- The practical discussion of where ReBAC stops and runtime authorisation begins
👉 Read PlainID's analysis of ReBAC and policy-based access in IAM →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/08/2026 6:42 pm
ReBAC is the right answer to relationship-shaped access, not a replacement for policy. The model is strongest when access should track ownership, membership, or delegation in real time. That makes it valuable in collaboration systems, but it does not solve the full authorisation problem for regulated environments.
A question worth separating out:
Q: How do AI agent requests change the way teams should think about ReBAC?
A: An AI agent can use a valid relationship path and still need a separate policy decision because it is acting on behalf of a human at runtime. Teams should evaluate the combined requester, action, and context, not just whether a graph edge exists.
👉 Read our full editorial: ReBAC changes how access decisions track relationships in IAM