What Is Relationship-Based Access Control (ReBAC)?

Relationship-based access control decides who gets into a resource by checking how two things connect, not by checking a list of roles. A doctor opens a patient’s chart because the system has linked that doctor to that patient. “Doctor” alone carries no blanket permission to every chart in the hospital. Security teams shorten the name to ReBAC, and once you know what to look for, you see it everywhere: a file shared with one colleague, a repository owned by a single team, a folder that only appears for the people invited into it.

GitHub’s permission model runs on relationships. So does Google Docs sharing, and so does Facebook’s original friends-of-friends visibility settings, the feature that pushed this approach into the mainstream years before most enterprises had a name for it. Grant access based on the connections between people, groups, and resources, then let the system trace those connections at the moment someone asks for something. That’s the whole idea. The part that gets complicated is everything underneath it, and that complexity is exactly why IAM architects need to understand ReBAC before they build a system on top of it.

What Is ReBAC, Exactly?

An access review, sometimes called a user access review or access certification, asks a manager, app owner, or security team to formally attest that a given identity’s access to a system is still appropriate. SOX, SOC 2, ISO 27001, and HIPAA all require some version of this: a named reviewer, a documented decision, and a timestamped record an auditor can pull months later.

Review and certification aren’t quite the same thing, and the difference matters here. A review is the act of looking at access and judging whether it’s still warranted. A certification is the signed, evidentiary version of that look, the kind that holds up when an auditor asks for proof after the fact. Neither one is in question as a control. Certification proves someone checked. It doesn’t prove that what got checked on review day still holds true on any other day of the quarter. That’s a separate problem, and it’s the one that’s gotten harder as SaaS footprints have grown.

Why the gap keeps widening

Strip away the vendor language and ReBAC is a graph problem. Every person, team, file, and document becomes a node. Every connection between them, ownership, membership, delegation, becomes an edge. When someone requests access, the system doesn’t ask what role they hold. It asks whether a path exists between the requester and the resource, and it asks that question fresh, every time.

That’s the line that separates ReBAC from role-based access control. RBAC checks a static assignment: is this person an “editor,” and does “editor” carry the permission being requested? ReBAC checks a live structure: is this person connected, directly or through a chain of other connections, to the thing they want? A contractor added to a project three minutes ago inherits exactly the access that project’s relationships grant, no role reassignment required. The system doesn’t care what title sits on the person’s badge. It cares what they’re linked to.

Where ReBAC Came From

The term has an academic paper trail, which is more than most access control buzzwords can claim. Security researcher Carrie Gates named the pattern in 2006 while studying the privacy problems social networks were about to create. Philip Fong, working at the University of Calgary, formalized it further in 2011 with a protection model and policy language presented at the ACM Conference on Data and Application Security, the paper still cited as the field’s reference point.

The idea stayed academic until Google gave it a production home. In 2019, a Google engineering team published the paper behind Zanzibar, the authorization system running behind Drive, Photos, and YouTube, handling permission checks at a scale most enterprises will never approach: billions of checks a day, across a graph with billions of relationships, with latency measured in milliseconds. Zanzibar didn’t invent relationship-based access control. It proved the model could run at planetary scale without falling over, and that proof is why open-source projects like OpenFGA and SpiceDB exist today, both built to bring Zanzibar’s design to teams who aren’t Google.

Common Relationship Types in ReBAC

Most ReBAC implementations lean on a small set of relationship shapes, and once you recognize them, unfamiliar systems stop looking unfamiliar.

Ownership

The simplest relationship in the model: one entity owns another, full stop. A user owns a document. A team owns a repository. Ownership usually carries the widest set of permissions by default, since the owner is the entity the system trusts to decide who else gets in. Most implementations treat ownership as transferable, which is exactly what happens when an employee leaves and a manager takes over their files.

Parent-Child Hierarchies

Resources rarely stand alone. A file sits inside a folder, a folder sits inside a workspace, a task sits inside a project. ReBAC models this as inheritance: grant access to the parent, and by default, the children inherit it. This is what makes folder-sharing in tools like Google Drive or Notion feel effortless. Share the top-level folder once, and every document dropped inside it later picks up the same access without anyone touching a permission setting again.

Groups and Organizations

People rarely get access one relationship at a time. They get added to a team, and the team’s existing relationships extend to them automatically. An engineer joining the backend group on day one inherits access to every repository the backend group already touches, because the relationship lives at the group level, not the individual level. This is the mechanism that keeps onboarding from becoming a permissions scavenger hunt.

ReBAC in Practice: A Real-World Example

Picture a project management tool with workspaces, projects, and tasks. A workspace has an owner and a set of members. A project belongs to a workspace and inherits its member list unless someone overrides it. A task belongs to a project and inherits from there too, three layers deep.

Now a guest gets invited to comment on exactly one task, nothing else. The system doesn’t add a role. It writes a single relationship: this guest is a viewer of this task. When the guest opens the app, the authorization check doesn’t consult a role table. It asks whether a path connects this guest to this task, and it finds one directly, viewer(guest_47, task_812), without needing to walk the workspace or project layers at all. Ask the same system whether that guest can see the parent project, and the check comes back negative. No path exists. That’s the entire model in action: permission as reachability, evaluated fresh at request time, scoped to exactly the relationship someone wrote down.

The Benefits and Drawbacks of ReBAC

Everything up to this point boils down to one mechanic: ReBAC treats permission as reachability inside a relationship graph, checked fresh at the moment of the request instead of assigned once to a role. That mechanic is what makes the model fit real organizations so well, and it’s also where the trouble starts once that graph has to scale, get audited, and stay in sync with the rest of the business.

What ReBAC Gets Right

ReBAC mirrors how organizations actually work instead of forcing them into role buckets that never quite fit. Most companies don’t run on twelve clean job titles. They run on ownership, delegation, temporary collaborators, and nested teams, and ReBAC represents all of that natively. It also sidesteps role explosion, the problem where an RBAC system grows a new role for every edge case until nobody remembers what half of them do. A well-modeled ReBAC system needs new relationships, not new roles, when the org chart shifts.

Where ReBAC Breaks Down

The graph that makes ReBAC powerful is the same graph that makes it hard to audit. Ask a compliance team to explain exactly why a given contractor can see a given file, and the answer might involve tracing four hops through group memberships and inherited relationships nobody wrote down on purpose. Untangling that after the fact takes real engineering time.

There’s also a sync problem most teams underestimate going in. Relationship data, who owns what, who’s on which team, usually lives in an application’s primary database. The ReBAC engine needs its own copy to check permissions fast, which means every membership change has to write to two places at once. Miss that second write, even briefly, and the authorization system is making decisions on stale relationships. And relationships alone can’t express everything a real policy needs. Time of day, device posture, data classification, the intent behind a request: none of that lives on an edge in a graph. ReBAC tells you who’s connected to what. It has nothing to say about the dozen other conditions a mature access decision might require.

ReBAC vs. RBAC vs. ABAC vs. PBAC: How the Models Compare

None of these models replaced the one before it. Each one showed up to cover a gap the earlier ones left open, and most production systems today run some combination of all four.

Model	What it checks	Best fit	Where it breaks down
RBAC	A fixed role assigned to the person	Small, stable orgs with a handful of clear job functions	Role explosion once access needs get specific
ABAC	Attributes of the requester, resource, and environment	Context-heavy rules: clearance level, time of day, data sensitivity	Policies get hard to write and maintain as attribute count grows
ReBAC	Relationships between entities, traversed as a graph	Nested ownership, shared documents, dynamic teams	No native way to factor in attributes, context, or intent
PBAC	Identity, attributes, relationships, and business context, evaluated together at runtime	Enterprise scale, regulated data, human and AI agent identities alike	Needs a centralized policy engine to run

RBAC assigns permissions to a role and a role to a person. It’s simple to explain and simple to audit, right up until an organization needs access decisions that depend on something other than job title, and that’s usually sooner than teams expect. ABAC answers that gap by evaluating attributes instead: department, clearance level, resource sensitivity, time of day, whatever variables a policy needs to check. ReBAC answers a narrower but stubborn gap ABAC handles poorly: access that depends on a specific connection between two entities rather than a shared attribute both happen to hold.

PBAC sits above all three. Rather than picking one input, a policy-based engine evaluates identity, attributes, relationships, and business context together, in a single decision, at the moment access gets requested. In PlainID’s own maturity model, that progression runs from role, to attribute, to policy, with intent-based control layered on top as the newest addition, one that asks not just who someone is and what they’re connected to, but what they’re actually trying to do right now. Under that framing, ReBAC’s relationships don’t compete with a policy engine. They feed one, as a single input alongside everything else a real authorization decision needs to weigh.

Why ReBAC Alone Isn’t Enough for AI Agents

Every one of these models was built with a human requester in mind, and AI agents break that assumption. Gartner has pointed to a machine-to-human identity ratio climbing past 82 to 1, and a growing share of those machine identities are agents acting on someone’s behalf, retrieving data, calling tools, and taking actions a static relationship graph never anticipated.

An agent doesn’t sit inside ownership or group membership the way a person does. It isn’t a member of a team the way a new hire is. It acts on behalf of a specific human, at a specific moment, for a specific reason, and a graph built to answer “is this entity connected to that resource” has no way to evaluate the intent behind the request or the combined authority of the human-agent pair making it. Relationship data still matters here. It just isn’t enough on its own.

This is the gap runtime authorization platforms are built to close. PlainID treats relationships as one signal among several, alongside identity, business attributes, and live context, evaluated together the instant an agent, a human, or a composite of both requests something. Its Authorization Graph maps the full chain, identity provider to application to agent to the tools and data that agent can reach, giving security teams a single place to see and govern access that used to live scattered across a dozen disconnected systems. The relationship still matters. It’s the decision built around it that determines what an AI agent is permitted to access, do, and expose.

Getting This Right

ReBAC earns its place in collaboration tools, document sharing, and social platforms, anywhere access tracks who’s connected to whom. Build a system on nested ownership and shifting team membership, and a relationship graph will represent that far better than a static role table ever could.

Push into regulated data, AI agents acting with real authority, or an enterprise stack where dozens of applications each need a consistent answer to “who can access what,” and relationships stop being the whole story. What you need at that point is a policy layer that can take relationships as one input among many, evaluate them alongside identity and context, and enforce the result the same way everywhere. By evaluating this complete context, you can consistently govern what every identity can access, do, and expose across your entire technology stack . That’s the layer PlainID builds. If you’re mapping out where ReBAC fits into your own authorization strategy, that’s the conversation worth having next.