Skip to lesson
Exit
Deep Dive - Authentication Architecture1 / 2

1 min lesson

Where pure RBAC breaks: resource-level access

Use the lesson to respond to this: "Users want to share a single repository with one specific teammate. Your model is plain role-based access control. Why is that a poor fit and what do you reach for?" Keep the answer plain.

Step 1 of 2

Where pure RBAC breaks: resource-level accessand why ReBAC enters

Roles answer org-wide questions well and resource-specific questions badly. "Can Maya read repo X" is not a role - it's a relationship between a user and one resource and modeling every such grant as a role explodes into role sprawl. This is the case for ReBAC (relationship-based access control), the Google Zanzibar model behind tools like SpiceDB and OpenFGA.

Model
RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. Press Enter for the full definition.
Good at
Coarse org-wide capability (admin vs member)
Weak at
Per-resource sharing, exploding role counts
Use it for
Org/team roles, billing, policy
Model
ReBAC (Zanzibar)
Good at
"user X relates to resource Y" at scale
Weak at
Conceptual overhead, another system to run
Use it for
Repo/file/agent-run-level sharing
Model
ABAC (attribute)
Good at
Conditional rules (region, time, IP)
Weak at
Hard to audit, decisions get opaque
Use it for
Compliance overlays, residency

Real systems blend them: RBAC for the spine, ReBAC for resource sharing.

For Cursor specifically, repo and agent-workspace access is the relationship-heavy part, so a Zanzibar-style layer for resource sharing on top of plain RBACRole-Based Access Control. Granting permissions by role rather than configuring each person individually. Press Enter for the full definition. for org roles is a defensible answer. Frame it as general-industry practice - you don't need to claim Cursor runs OpenFGA, only that the resource-sharing shape calls for ReBAC thinking.