ReBAC in practice: what OpenFGA and Permit.io change

At a glance

What this is: This is a comparison of OpenFGA and Permit.io that shows why relationship-based access control is better suited to graph-like authorization decisions than fixed-role models.

Why it matters: For IAM and application security teams, the issue is not whether ReBAC works in theory but whether they can run it, govern it, and avoid creating an authorization graph they cannot audit.

Context

ReBAC, or Relationship-Based Access Control, defines authorization from how entities relate to each other rather than from static roles alone. That matters when users, groups, organisations, folders, and documents inherit access through real business relationships instead of one-off permission checks.

The article compares OpenFGA and Permit.io as two ways to operationalise that model. The practical issue for identity teams is not just whether relationships can express access, but whether the operating model, policy tooling, and governance controls can keep pace with graph complexity.

This is primarily an authorization architecture question for human and application access in modern software platforms. The article sits at the intersection of IAM, application authorization, and governance of fine-grained permissions.

Key questions

Q: How should teams implement ReBAC without creating an authorization blind spot?

A: Start by modelling the real business relationships that grant access, then define ownership for who creates, reviews, and removes those relationships. ReBAC becomes risky when the graph is treated as developer plumbing rather than governed authorization data. Teams need reviewable policy semantics, clear data sources, and audit trails that explain why access exists.

Q: Why can relationship-based access control be better than static roles for collaborative systems?

A: Static roles are coarse and break down when access depends on ownership, membership, tenancy, or inherited business relationships. ReBAC can express those patterns directly, so teams avoid hard-coded checks and repetitive manual grants. The trade-off is that the relationship graph itself must be accurate, visible, and governable.

Q: What are the main mistakes teams make when adopting ReBAC?

A: The most common mistakes are failing to govern tuple data, letting application data sync drift out of step with the policy graph, and combining relationship logic with attributes in ways no one can explain later. Another frequent error is treating the engine as the control, when the real control is the policy model and its lifecycle.

Q: Should organisations choose self-hosted or managed authorization for ReBAC?

A: Choose based on operating model, not ideology. Self-hosted ReBAC makes sense when you want direct control over infrastructure and can own scaling, caching, and policy operations. Managed authorization makes more sense when you need faster deployment, clearer admin tooling, and less operational burden around the decision service.

Technical breakdown

Why ReBAC changes the authorisation model

Relationship-based access control represents permissions as edges in a graph rather than as fixed role assignments. That lets applications answer questions such as whether a user can view a document because they own it, belong to a group that owns the folder, or sit inside the managing organisation. The architectural advantage is inheritance: access can flow through entity relationships without re-encoding nested logic in every service. The governance trade-off is that access meaning becomes distributed across graph structure, so the model is only as trustworthy as the relationship data feeding it.

Practical implication: treat relationship data as part of the authorization control plane, not as application convenience data.

OpenFGA and the code-first ReBAC pattern

OpenFGA implements Zanzibar-style authorization as a self-hosted service where teams define a model in a DSL and store relationship tuples in a database. Applications then query the service at decision time. This gives strong control over the authorization model, but it also creates operational dependencies on storage, caching, and synchronization of application data into the graph. Because the service is purely ReBAC, teams do not get native attribute-based conditions inside the same decision model, which can force additional logic elsewhere.

Practical implication: if you choose a code-first engine, design the data sync, caching, and policy ownership model before you depend on it in production.

Managed hybrid authorisation and the ReBAC-plus-ABAC boundary

Permit.io extends ReBAC with a managed service layer, a policy editor, SDKs, Terraform support, and attribute-based conditions. That changes the implementation burden more than the authorization concept itself. The important architectural distinction is that relationship inheritance and attribute checks can be combined in one decision path, which reduces custom glue code but also makes governance depend on how clearly teams separate graph relationships from attribute logic. When that boundary is blurred, auditability becomes harder even if the developer experience improves.

Practical implication: define which decisions come from relationships and which come from attributes before combining both models in production.

Breaches seen in the wild

• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ReBAC is a governance model, not just a better permission syntax. Once authorization is expressed as entity relationships, the security question shifts from role assignment to relationship integrity. That means teams are governing a graph, not only a list of entitlements, and graph correctness becomes a first-order identity control concern. Practitioners should treat relationship design as part of authorization governance, not as a developer convenience layer.

Authorization complexity becomes the new blind spot when access inheritance is implicit. ReBAC is attractive because it removes nested permission checks and manual propagation, but those benefits also hide how access actually accumulates. If the relationship graph is poorly modelled, teams can create inherited access paths that are harder to inspect than classic roles. The practical conclusion is that visibility must be designed alongside expressiveness.

Managed authorization changes the operating model more than the policy model. The difference between a self-hosted engine and a managed platform is not only infrastructure ownership; it is where policy lifecycle, auditability, and operational responsibility sit. That distinction matters for IAM and IGA teams because governance fails when ownership of the authorization graph is split across developers, platform teams, and security without a clear control boundary.

ReBAC exposes the limits of role-centric thinking in collaborative systems. Roles remain useful for coarse access, but they are a poor fit when access depends on ownership, membership, tenancy, or delegated relationships. ReBAC solves that expressiveness gap, yet it also requires tighter discipline around model design and review. For practitioners, the real decision is whether the organisation can govern relationship-driven access at the same speed it changes business structure.

Hybrid ReBAC and ABAC is powerful, but only if policy semantics stay separable. Combining relationships with attributes can reduce implementation friction, but it also increases the risk of policy sprawl if teams cannot explain which layer made the decision. That is where authorization drift starts. The strongest operating model is one where relationship rules, attribute rules, and audit records remain clearly attributable, so reviewers can reconstruct why access was granted.

What this signals

ReBAC makes authorization data more expressive, but also more governable. The shift from role checks to relationship graphs means access decisions become dependent on the quality of relationship data, not just on policy syntax. For identity teams, that pushes governance upstream into model design, ownership, and reviewability rather than leaving it at the application layer.

Authorization drift is the hidden risk in hybrid policy models. When teams combine ReBAC and ABAC without clear semantic boundaries, they can no longer easily reconstruct why a decision was made. That matters for audit, incident review, and access certification, because a control that cannot explain itself is already weakening.

Relationship-aware access should be evaluated like any other governed identity control. If the organisation cannot show who manages relationships, how they are reviewed, and how inherited access is revoked, the model will scale policy complexity faster than it scales control.

For practitioners

• Map inherited access paths before replacing roles Inventory the business relationships that currently imply access, such as ownership, tenancy, folder membership, and organisation membership. Use that map to decide which entitlements should be graph-derived rather than explicitly assigned.
• Separate relationship logic from attribute logic Document which authorisation decisions should come from graph relationships and which should come from attributes or contextual conditions. Keep those semantics distinct so reviewers can explain a decision without reverse engineering the entire model.
• Treat the relationship graph as governed data Assign clear ownership for tuple creation, changes, and removals, and include relationship data in access review and audit processes. If the graph cannot be reviewed, it should not be treated as a production control.
• Evaluate operational ownership before choosing the engine Decide whether your team can run storage, caching, policy sync, and model lifecycle internally, or whether a managed authorization service better matches your operating model and governance capacity.

Key takeaways

• ReBAC changes access control from role assignment to relationship governance, which is better aligned to collaborative and inherited access patterns.
• OpenFGA and Permit.io represent two operating models for ReBAC, one code-first and self-hosted, the other managed and hybrid with ABAC.
• The control question is whether teams can keep the relationship graph explainable, reviewable, and operationally owned as access decisions become more dynamic.

Key terms

• Relationship-Based Access: An access model where entitlements are justified by the current business relationship, such as employee, contractor, student, vendor, or service account status. In practice, the relationship defines scope, duration, ownership, and review requirements.
• Authorization Graph: An authorization graph is the network of identities, resources, roles, and inheritance rules that determine access decisions. In practice, it must stay consistent with the application's structure or it becomes a source of drift, exceptions, and maintenance overhead.
• Inherited Access: Inherited access is permission a tool receives from a connected user, service account, or integration rather than from a purpose-built identity. It often hides privilege expansion because the tool appears lightweight while actually operating under broad, durable entitlements.
• Policy lifecycle: Policy lifecycle is the governed process of creating, testing, approving, distributing, monitoring, and retiring authorization rules. For modern IAM programmes, it is the control layer that keeps access decisions consistent as applications, runtimes, and business requirements change.

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 building or maturing an IAM programme, it is worth exploring.