Governance · 9 min read
ReBAC vs RBAC for AI agents
ReBAC vs RBAC for AI agents — why role-based access hits role explosion with autonomous agents, and why relationship-based access fits agentic work.
Access control was built for people. People are relatively few, change roles slowly, and act at human speed. AI agents are none of those things — they multiply, they take on shifting scopes per task, and they act at machine speed across many systems at once. The model most platforms reach for, RBAC, was already straining under modern B2B complexity. Hand it a fleet of autonomous agents and it breaks in a specific, predictable way. ReBAC is the model that doesn’t.
Citable answer — RBAC (role-based access control) grants permissions through assigned roles and tends toward “role explosion” — a sprawl of near-duplicate roles — as scenarios multiply. ReBAC (relationship-based access control) grants permissions by the relationships between entities, so access scales with relationships instead of a role table. For AI Agents, which spawn in numbers and shift scope per task, ReBAC fits where RBAC fractures.
What is RBAC, and what is its limit?
RBAC, role-based access control, grants permissions by assigning a user to a role — “editor,” “analyst,” “billing-admin” — and attaching permissions to that role. It is simple, well-understood, and genuinely good when the set of roles is small and stable. Most enterprise software has used it for decades, and for good reason.
Its limit has a name the industry uses openly: role explosion. As real-world access requirements grow more conditional — this team but not that project, this region but not that customer, read here but write only there — you create more and more narrow roles to capture each combination. Security and identity practitioners describe RBAC as suffering role explosion and being a poor fit for complex B2B scenarios, with relationship-based models increasingly the go-to alternative (permit.io, securityboulevard.com). You end up with a role table no one can fully reason about, which is the opposite of what an access model is for.
This is not a strawman of RBAC, and the fix is not “RBAC is bad.” For a stable, low-cardinality set of actors with coarse permissions, RBAC is the right tool. The argument is about fit: the conditions RBAC handles well are exactly the conditions AI agents violate.
What is ReBAC?
ReBAC, relationship-based access control, defines permissions by the relationships between entities — people, Agents, workspaces, data — rather than by a static role assigned in advance. Instead of “this user has the analyst role, and the analyst role can read finance reports,” ReBAC says “this Actor has an owns relationship to this workspace, and owner can read its reports.” Access follows the relationship graph that already describes how your organisation is structured.
ReBAC is an established model with a defined entity in the wider field (Wikipedia: Relationship-based access control); Google’s Zanzibar system popularised the approach at scale. The practical payoff is that permissions scale with relationships you already maintain rather than with a hand-curated role catalogue. When a new project, customer, or Agent enters the picture, you express its relationships, and the permissions fall out — you do not mint a new role for every combination.
Why do AI agents specifically need ReBAC?
Agents break RBAC’s assumptions in four ways at once, and each one pushes toward relationship-based access.
- Agents proliferate. You don’t have ten Agents the way you have ten “editors.” You can have an Agent per task, per workspace, per goal — and a new one tomorrow. Minting a role per Agent recreates role explosion at agent scale.
- Agents have shifting scope. A human’s role is relatively stable; an Agent’s appropriate access depends on the specific job in front of it. Relationship-to-the-resource captures “this Agent, working this Harness, on this data” far better than a fixed role does.
- Agents act at machine speed and breadth. An Agent reads, joins, and acts across systems unattended. The cost of an over-broad role is no longer one person seeing one extra screen — it is automated access exercised in bulk. Access defined by relationship to the specific resource is the natural constraint.
- Agents and people must share one model. A second mind needs one access model for human Actors and Agent Actors alike. Maintaining RBAC for people and something else for agents guarantees the two drift apart — and the gap between them is where access leaks. ReBAC governs both under the same relationships.
The deeper point: an Agent’s right to touch something is almost always a function of a relationship — this Agent belongs to this workspace, which owns this data, on behalf of this Operator — not of a label assigned at provisioning time. ReBAC encodes that directly.
ReBAC vs RBAC for AI agents — an honest comparison
| RBAC (role-based) | ReBAC (relationship-based) | |
|---|---|---|
| Access decided by | Assigned role | Relationship between entities |
| Scales with | A maintained role table | Relationships you already model |
| Failure mode | Role explosion (near-duplicate roles) | Graph complexity; needs a relationship store + clear modelling |
| Fit for stable, coarse access | Excellent — often the right choice | Overkill for simple, low-cardinality cases |
| Fit for many short-lived AI Agents | Poor — a role per Agent re-creates explosion | Strong — access follows the Agent’s relationships |
| Per-task / conditional scope | Awkward — encoded as more roles | Natural — encoded as relationships |
| One model for humans + Agents | Possible but tends to fork | Same relationship model governs both |
| Auditability | ”Which roles grant this?" | "Which relationship path grants this?” — traceable |
Being fair to RBAC: ReBAC is not free. A relationship-based model needs a relationship store and disciplined modelling, and for genuinely simple cases it is more machinery than the problem warrants. The honest position is fit, not superiority — and agentic work is precisely the case where the fit flips to ReBAC.
How Oraclous applies ReBAC to agents
Oraclous enforces ReBAC platform-wide, at the Harness level, so the same fabric that runs the work records who could touch what, and why. What an Agent can reach is decided by its relationships and enforced in code — not by a role you remembered to scope correctly, and not by anything the model decides for itself.
Three details make this concrete and worth a security reviewer’s time:
- Two-layer enforcement, and code wins. ReBAC checks, capability allocations, budget caps, and human-in-the-loop gates are coded enforcement; the prose inside a manifest is interpreted flexibly. A prose instruction that contradicts a structured policy never overrides it — governance lives in code, flexibility lives in prose, code wins.
- Versioned policy sets. Each Harness runs under one of five named, versioned policy sets (development through production-strict to production-federated), declaring trust tier, budget ceilings, BYOM constraints, capability allow/deny, and audit retention. Access is configured and inspectable, not improvised per run.
- Provenance auditors can read. Provenance is a universal sink on the Substrate; every node, relationship, query, and audit log carries an
organization_id. “Prove you control what this Agent can access” becomes a query against the relationship graph, not a verbal assurance.
This is the wedge worth stating plainly: most governed agent platforms — including ones that lead with “enterprise-grade security” — implement RBAC. Relationship-based access control for AI agents is where the model and the workload finally fit. For the full mechanism, see ReBAC governance and how to govern and audit AI agents; for the definition, the ReBAC glossary entry.
Frequently asked questions
Q: What is the difference between ReBAC and RBAC? A: RBAC grants access through assigned roles and attaches permissions to those roles; ReBAC grants access through the relationships between entities — people, agents, workspaces, data. RBAC scales with a role table and tends toward role explosion; ReBAC scales with relationships you already model, so it fits conditional, high-cardinality access better.
Q: Why is ReBAC better for AI agents than RBAC? A: AI agents proliferate, shift scope per task, and act at machine speed — conditions that push RBAC into role explosion. ReBAC ties an agent’s access to its relationships (which workspace, which data, on whose behalf), so access scales naturally and humans and agents are governed under one model rather than two that drift apart.
Q: What is role explosion? A: Role explosion is the proliferation of near-duplicate roles that happens when RBAC tries to capture increasingly conditional access. Each new combination of team, project, region, or permission level becomes another narrow role, producing a role table too large to reason about — a problem the industry widely attributes to RBAC in complex B2B settings.
Q: Is RBAC ever the right choice? A: Yes. For a stable, low-cardinality set of actors with coarse permissions, RBAC is simple, well-understood, and often the right tool. The case for ReBAC is about fit: it wins specifically where access is conditional and high-cardinality — which describes AI agents, not every system.
Q: How does Oraclous enforce ReBAC for agents?
A: Oraclous enforces ReBAC in platform code at the Harness level. Each Agent’s capability allocation and relationships are checked by the Runtime under a versioned policy set; prose in a manifest can never override a coded policy, and every access is provenance-tracked with an organization_id, so auditors get an inspectable record.