IBAC vs RBAC vs ABAC vs ReBAC: Which access control model fits AI agents?
Compare the four authorization models developers actually choose between, see exactly where each one breaks when an agent is the caller, and understand what intent-based access control does and doesn't mean.
Authorization used to be a question you could answer in advance. You knew who your users were, you knew roughly what their jobs required, and you could write that down as roles, attributes, or relationships before anyone signed in. The whole discipline is built on the assumption that a caller's needs can be described ahead of time.
AI agents broke that assumption in a specific way. An agent working from a single prompt might read your issue tracker, pull a figure out of billing, and send an email on the way to finishing one task, and nobody knows that list in advance, including the person who wrote the prompt. Scope the agent narrowly and it stalls halfway through. Scope it broadly and you have handed a nondeterministic system standing access to your most sensitive tools.
That gap has produced a new acronym, IBAC, along with a fair amount of disagreement about what it means. Several vendors shipped products under that name during 2026 and defined it differently each time, and the term has a history in access control going back well before any of them.
This guide compares the four models developers actually choose between: RBAC, ABAC, ReBAC, and IBAC. For each one, how it works, what it is genuinely good at, and exactly where it breaks when the caller is an agent rather than a person. It closes with what to evaluate if you decide you need an intent layer, and why that layer belongs on top of your existing model rather than in place of it.
The question each model answers
Every access control model is a different answer to the same question: given a caller and a resource, should this call go through?
What separates the models is what they look at to decide.
- RBAC looks at who the caller is, expressed as a role.
- ABAC looks at properties of the caller, the resource, and the environment.
- ReBAC looks at the relationship between the caller and the specific resource.
- IBAC looks at what the caller is currently trying to accomplish.
The first three are mature, well understood, and widely deployed. The fourth is new, contested, and arrived because AI agents broke an assumption the other three share: that you can know what a caller needs before it starts running.
This guide covers how each model works, where each one breaks for agents, and what to make of intent-based access control now that it has several competing definitions in the market.
Role-based access control (RBAC)
RBAC assigns permissions to roles, and roles to users. An admin can do everything, a member can read and write, a viewer can read. Users inherit whatever their role carries.
It works because roles map cleanly onto how companies are already organized. Onboarding is one assignment. Offboarding is one revocation. Auditing is a question about roles, not about thousands of individual grants.
RBAC's limits are well documented: role proliferation as exceptions accumulate, and rigidity when someone's work doesn't match their job title.
Where it breaks for agents. Roles are shaped like job functions. An agent's work is shaped like a task, and a single agent may need to touch your CRM, your issue tracker, your mail, and your billing system over the course of one prompt. Assign it a role broad enough to finish the job and you have granted it that breadth permanently, for every future run. As Michael Grinich put it on stage at Agent Night, a local permission check "won't stop you from deleting a thousand Salesforce records in your CRM."
Attribute-based access control (ABAC)
ABAC evaluates policies over attributes: attributes of the user (department, clearance, employment status), of the resource (classification, owner, region), and of the environment (time of day, IP, device posture).
A policy might allow finance staff to open documents classified as financial, during business hours, from a managed device. The engine evaluates all of it at request time.
ABAC buys real flexibility, and it is the model most often reached for when RBAC runs out of room. The cost is policy complexity. Attributes multiply, policies interact in ways nobody predicted, and the system becomes hard to reason about.
Where it breaks for agents. ABAC is dynamic about context but static about purpose. It can tell you the caller is in finance and the file is financial, and it will happily approve an agent reading a revenue report it has no business reading on this particular run. The attributes are all satisfied. The action is still wrong.
Relationship-based access control (ReBAC)
ReBAC, popularized by Google's Zanzibar paper and the systems built on it, decides based on relationships stored as tuples: this user is an editor of that document, that document lives in this folder, this user is a member of that team.
Permission checks become graph traversals. Does a path exist from this user to this resource with the right relationship along it? This is what makes per-object sharing practical at scale, which is why it underpins Google Drive, GitHub, and most modern collaboration products.
Where it breaks for agents. ReBAC is the most precise of the three, and precision is exactly what makes it awkward here. The relationship graph has to exist before the check runs. An agent working through a novel task needs access to resources nobody has drawn an edge to yet. You either pre-grant broadly, which defeats the point, or the agent stalls.
What agents actually broke
Every model above depends on the same thing: the ability to decide what a caller needs before it runs.
That assumption held for decades because it was true. For a human, the job title is a reasonable proxy. For a service, you can read the code, see the three systems it touches, and scope the credential to exactly those three.
A prompt gives you none of that. "Go handle this for me" carries no information about which systems the work will require, and the person writing it doesn't know either. There is no compile time in agentic software.
This leaves teams choosing between two bad options. Approve every action by hand, which works until you stop reading the prompts you are approving, or run with permissions checks disabled and hope. Most of the interesting ground sits between those extremes, and until recently nothing lived there.
Intent-based access control (IBAC)
IBAC makes the decision input the task itself. Rather than asking what role the caller holds, it asks what the caller is trying to accomplish on this particular run, and whether the call in front of it follows from that.
In practice this means three things happen that don't happen in the other models:
- The intent is captured. A prompt becomes a stated outcome, not a permission grant.
- The intent is compiled into expected actions. Which connectors, which operations, which shape of request.
- Every call is evaluated against it at runtime, with more possible answers than yes or no. Allow, deny, escalate to a human, or ask for more information.
That third outcome is the one the older models cannot express. The honest answer to "can this agent do this" is frequently "it depends, ask someone," and a model that can only return a boolean has nowhere to put that.
Where the term comes from
IBAC has a longer and messier history than most vendor pages suggest, and it is worth knowing before you evaluate anyone's claim to it.
Nobody in this market coined the term, including us. It has been reached for repeatedly because it names something real, which is the gap between what a caller is permitted to do and what it is currently supposed to be doing.
The split that actually matters
Within the 2026 wave, there are two meaningfully different implementations hiding under one acronym.
Inferred intent. A model sits in the path, reads the agent's reasoning and its tool calls, and judges whether the action follows from the task. This catches things you never anticipated, which is its real strength. It is also probabilistic, and a model in the enforcement path can be worked on by the same input it is supposed to be judging.
Declared intent. The task is captured up front as an explicit scope, before any untrusted content reaches the context window, and enforcement is a deterministic check against that scope. This is provable and injection-resistant. It only covers what was declared.
Most vendors in this space now claim enforcement rather than alerting, so "they detect, we block" is not the useful distinction. The useful questions are whether a given system's decisions are inferred or deterministic, and where the enforcement point sits. A system placed between the agent and its model protects the reasoning loop, and its coverage follows the agent surfaces it proxies. A system placed between the agent and the service provider constrains the call itself, and its coverage follows the providers it integrates.
The strongest implementations do both kinds of check. Deterministic rules gate which endpoints, methods, and arguments are reachable at all, and runtime judgment handles what a matcher cannot express, such as whether a message body contains financial data. When someone asks who checks the checker, the deterministic layer is the answer: it holds regardless of what the runtime judgment concludes.
One more property separates IBAC systems worth evaluating from the rest. If the agent still holds the provider credential, the enforcement is advisory, because anything that can reach the API directly can route around the checker. Brokering the credential so the agent never sees it is what makes the boundary real.
How the four models compare
IBAC does not replace the other three
This is the part most coverage of the category gets wrong.
You still need RBAC, because humans still have jobs and roles are still the right shape for that. You still need ReBAC or fine-grained authorization, because per-document sharing is a real requirement that intent has nothing to say about. ABAC still handles the conditions that have nothing to do with purpose, like blocking access from an unmanaged device.
IBAC narrows within those boundaries. Your existing model establishes the outer limit of what is reachable at all. Intent decides how much of that limit this particular run gets to use. An agent operating on behalf of a user should never exceed what that user could do themselves, and intent should shrink it further.
The right way to read IBAC is as a fourth input added to the three you already evaluate, not as a migration you undertake.
How to choose
Work through these in order.
- Are your callers humans doing their jobs? RBAC, plus groups so you are not assigning roles one user at a time.
- Do you need conditions that have nothing to do with identity? Add ABAC for time, location, device, and data classification.
- Do users share individual objects with each other? ReBAC or fine-grained authorization. This is a data modeling problem before it is a policy problem.
- Are agents calling your systems, or calling other systems on your users' behalf? You need an intent layer on top, because none of the first three can scope a caller whose requirements are unknown until it runs.
If you reach the fourth question, evaluate candidates on four things: whether decisions are deterministic, inferred, or both; where the enforcement point sits; whether the agent ever holds the provider credential; and whether a denied call produces an audit record you can actually reconstruct afterward.