A model that grants or denies access based on relationships between identities, resources, and contextual objects. Instead of hard-coding who can do what, ReBAC evaluates whether the relevant graph links exist at decision time, which makes it well suited to collaboration-heavy and agentic environments.
How ReBAC Works
Relationship-Based Access Control evaluates whether a requestor is connected to a target resource through an allowed relationship path at the moment access is requested. That path can be direct, inherited, or inferred through a graph of users, groups, tenants, objects, and policy context.
Unlike static role assignment, ReBAC treats authorization as a live graph problem. This makes it useful when the same identity may need different access depending on the object, the collaboration space, the team structure, or the relationship that exists to a specific record, repository, task, or account.
Why ReBAC Emerged
ReBAC fills gaps that become obvious when role counts explode or when attribute logic becomes too coarse for real collaboration. It is often described alongside RBAC and ABAC because all three solve authorization, but ReBAC is the model that most directly captures “who is connected to what” rather than “what role they hold” or “which attributes they match.”
That distinction matters in modern systems where access is not just about a person and a file, but about account hierarchies, shared workspaces, delegated ownership, partner relationships, and tool-mediated actions. The model is especially natural in systems that already store entities and edges as a graph, and it aligns well with Authorisation Models Guide, which places ReBAC in the broader decision landscape.
Where ReBAC Fits in Security Architecture
ReBAC is a policy decision model, not a standalone security control. It usually sits behind an application, policy engine, or authorization service that evaluates relationship queries before granting access, returning data, or allowing an action to proceed.
Because the decision depends on live graph state, the quality of ReBAC depends on the accuracy, freshness, and integrity of the relationship data. If those links are stale, incomplete, or polluted, the authorization result can be wrong even when the policy logic itself is correct. In practice, ReBAC often works best when it is paired with explicit ownership, entitlement review, and careful scoping of who may create or change relationships.
For collaboration-heavy systems, a useful pattern is to treat relationship edges as first-class security objects, not just application metadata. That is why guidance on access governance and entitlement management often sits close to ReBAC discussions, including IAM and IGA Basics.
Common Failure Modes and Security Consequences
ReBAC can fail when the graph is over-permissive, poorly maintained, or assembled from unsafe trust assumptions. If a user can create, inherit, or spoof a relationship that was meant to be tightly controlled, the model can unintentionally authorize access at scale. That risk is especially visible in systems with delegated administration, shared workspaces, partner access, or agent-mediated workflows.
Because relationship evaluation is often fine-grained, one bad edge can expose a large set of objects if the policy language allows transitive or hierarchical traversal. In higher-stakes environments, this turns graph integrity into an authorization assurance issue, not just an application design choice. ReBAC also needs strong handling for emergency access, ownership changes, revocation, and orphaned relationships, or it can quietly accumulate stale privilege.
In non-human and automation-heavy environments, the same pattern can apply to workloads and agents when the system uses relationship context to decide what an automation may touch. That is one reason identity-governance and machine-access models increasingly treat relationship logic as part of the security boundary, not merely an application convenience.
How Practitioners Should Think About It
ReBAC is most effective when the organization can describe access in terms of real business relationships with enough precision to audit and maintain them. If the relationship model is vague, unstable, or impossible to validate, ReBAC can become harder to govern than RBAC, not easier.
Practitioners should therefore treat the relationship schema, the policy evaluation point, and the lifecycle of relationship changes as part of the access-control design itself. The model is strongest when it reduces role sprawl, matches actual collaboration patterns, and supports least privilege without forcing administrators to invent artificial roles for every exception. For a broader comparison of access models, the authorization models guide is the most direct navigation aid.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, OWASP ASVS and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | ReBAC enforces access decisions based on policy-evaluated relationships. |
| AC-6 — Least Privilege | ReBAC is often used to narrow access to only the relationships that justify it. | |
| IA-2 — Identification and Authentication (Organizational Users) | ReBAC depends on reliable identity proof before relationship-based decisions are trusted. | |
| Recommendation — Apply AC-3 to enforce relationship-based authorization before access is granted. Use AC-6 to keep relationship-derived access as narrow as possible. Use IA-2 to ensure the requester is strongly authenticated before relationship checks run. | ||
| OWASP ASVS | V8 — Authorization | ReBAC is an authorization model that decides whether a subject may act on a resource. |
| V15 — Secure Coding and Architecture | ReBAC implementations depend on correct policy architecture and graph handling. | |
| Recommendation — Verify relationship-based authorization logic under ASVS V8. Design the authorization architecture to keep relationship evaluation correct and testable. | ||
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | ReBAC is an IAM authorization pattern used to govern access decisions. |
| Recommendation — Map relationship-based authorization into IAM governance and review processes. | ||
Related resources from NHI Mgmt Group
- What do teams get wrong about RBAC, ABAC, and relationship-based access control?
- Why does relationship-based access control matter for application and NHI governance?
- How should security teams govern relationship-based access control at scale?
- What is the difference between JWT-based access and relationship-based access control?