RBAC vs ReBAC.
Role-based access control (RBAC) grants access through roles assigned to identities — simple to reason about and audit, but prone to role explosion as exceptions pile up. Relationship-based access control (ReBAC) grants access through relationships between entities — "this user is an editor of this document", "this folder is in this workspace" — evaluated over a graph, the model popularized by Google Zanzibar. RBAC suits coarse, role-shaped access; ReBAC handles fine-grained, hierarchical, multi-tenant, and delegated authorization, including the per-resource decisions AI agents increasingly require.
Key takeaways
- RBAC grants access through roles; ReBAC grants it through relationships over a graph (the Zanzibar model).
- RBAC is simpler to audit but hits role explosion; ReBAC handles fine-grained, hierarchical, multi-tenant access.
- For AI agents, ReBAC expresses delegated, per-resource access cleanly.
- They combine — RBAC for broad roles, ReBAC for resource-level sharing.
RBAC vs ReBAC.
| Dimension | RBAC | ReBAC |
|---|---|---|
| Access driven by | Roles assigned to identities | Relationships between entities (a graph) |
| Granularity | Coarse — role → permission set | Fine — per resource, per relationship |
| Multi-tenancy | Tends toward role explosion | Native — tenants/orgs modeled as relationships |
| Hierarchies | Awkward (nested roles) | First-class (inheritance through the graph) |
| Audit | List a user’s roles | Traverse the relationship graph |
| For AI agents | Good for coarse guardrails | Fits delegated, downscoped, resource-level access |
| Seen in | Most apps; Okta/Entra roles | Google Zanzibar, OpenFGA, SpiceDB, policy services |
Where RBAC breaks down
RBAC is excellent until reality adds exceptions. "Editors, but only for their own team’s documents", "admins, except in the EU tenant", "this contractor, just this project" — each becomes a new role. Roles multiply faster than people, audits get harder, and the model that was meant to simplify access becomes the thing nobody fully understands. This is role explosion, and it is the usual reason teams look past RBAC.
How ReBAC works (the Zanzibar model)
ReBAC stores relationships as tuples — (object, relation, subject), e.g. (doc:42, editor, user:alice) — and answers "can alice edit doc:42?" by checking for a path through that graph, including inherited relations (alice is a member of team:7, team:7 is editor of folder:9, doc:42 is in folder:9). Google’s Zanzibar paper formalized this at scale; OpenFGA, SpiceDB, and modern policy services implement it. The result is fine-grained, per-resource authorization without inventing a role for every exception.
RBAC, ABAC, ReBAC — which to use
They are not mutually exclusive. RBAC gives coarse guardrails; ABAC decides on attributes at request time (see "RBAC vs ABAC"); ReBAC decides on relationships over a graph. Many systems combine them — RBAC for broad roles, ReBAC for resource-level sharing and multi-tenancy. For AI agents, ReBAC is increasingly the model that expresses delegated, downscoped access ("this agent may act on resources this user can access, and only those").
When to use each.
Use RBAC when…
- Access is genuinely role-shaped and exceptions are rare.
- You need simple, auditable assignments fast.
- You want coarse guardrails for agents or services.
Use ReBAC when…
- You have per-resource sharing, hierarchies, or multi-tenancy.
- Role explosion is already happening.
- You need delegated, resource-level authorization for AI agents.
Common questions.
Is ReBAC better than RBAC?+
Neither is universally better — they fit different shapes of access. RBAC is simpler and easier to audit for role-shaped access; ReBAC handles fine-grained, hierarchical, and multi-tenant authorization that would cause role explosion under RBAC. Many production systems use both.
What is the Zanzibar model?+
Zanzibar is Google’s globally-distributed authorization system, described in a 2019 paper, that stores access as relationship tuples and answers permission checks by traversing that graph. It is the reference design behind ReBAC implementations like OpenFGA and SpiceDB.
Can you combine RBAC and ReBAC?+
Yes, and it is common. Use RBAC for broad, organization-wide roles and ReBAC for resource-level sharing, hierarchies, and multi-tenancy. A single policy layer can evaluate both; the goal is to express each access rule in the model that fits it, rather than forcing everything into roles.
The whole picture, in one place.
This explainer is part of our complete guide to IAM — authentication, authorization, governance, privileged access, the standards, and how to run a program.