IBAC/RBAC/ABAC/ReBAC Compared: Which Access Control Model Fits AI Agents?

When AI Agents become the callers in a system, traditional authorization models start to crack. Access control mechanisms originally designed for human users and service accounts expose significant gaps when faced with intelligent agents capable of autonomous reasoning and dynamic tool invocation. This article compares three mainstream models — RBAC, ABAC, and ReBAC — and explores what the emerging IBAC (Intent-Based Access Control) actually means.

The Core Differences Between Four Authorization Models

When building a system's permission structure, developers are essentially choosing among four models. Understanding their fundamental differences is a prerequisite for determining which best fits AI Agents.

RBAC (Role-Based Access Control) is the most widely adopted model. It binds permissions to roles, and users gain permissions by being assigned those roles. RBAC's strengths are simplicity, auditability, and ease of management — administrators only need to maintain a limited number of role definitions. However, its granularity is coarse. When permission requirements are highly dynamic, the number of roles can explode, creating what's known as "role explosion."

ABAC (Attribute-Based Access Control) makes decisions by evaluating attributes of the subject, resource, action, and environment. It is far more flexible than RBAC and can express complex policies like "employees in the finance department can access expense reports in their region during business hours." The trade-off is a significant increase in policy complexity and debugging difficulty, with reduced predictability of permissions.

ReBAC (Relationship-Based Access Control) originates from Google Zanzibar's design philosophy, with a graph of relationships between entities at its core. Relationships like "owner of a document" or "member of a team" are modeled as graph structures, and permissions propagate along these relationships. ReBAC excels at handling hierarchical, shared resources such as collaborative documents and organizational structures.

The Origins of ReBAC: Google Zanzibar is a large-scale, consistent global authorization system that Google made public in 2019. It manages billions of user permission relationships across products like Google Drive, YouTube, and Google Photos. Zanzibar models "who has what relationship to what resource" as triples (user, relation, object) and uses graph traversal to determine whether access is permitted. This design has had a profound influence on open-source projects, with SpiceDB and OpenFGA both modeled after it. ReBAC's advantage in enterprise collaboration scenarios is its ability to naturally express transitive permissions like "A shares with B, and B can further delegate to C's team members" — without needing to write separate policies for each case. The trade-off is the cost of maintaining the relationship graph and query performance challenges when relationship chains grow long.

Where the Models Break Down When the Caller Is an Agent

The introduction of AI Agents breaks the fundamental assumptions of traditional authorization. Most authorization models assume the caller's identity is static and predictable — a user, a service, a fixed set of permissions. But Agent behavior is dynamic and non-deterministic.

RBAC faces the most straightforward problem: what role should an Agent be assigned? If assigned maximum permissions, the blast radius becomes uncontrollable if the Agent is compromised by prompt injection or produces faulty reasoning. If assigned minimal permissions, the Agent may lack the access needed to complete its task, requiring frequent human intervention. The static nature of roles cannot match the variability of Agent tasks.

ABAC can theoretically express more fine-grained conditions through attributes, but the Agent's "intent" is itself difficult to encode as an evaluable attribute. Traditional attributes describe "who you are" and "what the resource is," while what Agent scenarios truly need to answer is "what do you want to do right now, and why."

ReBAC encounters relationship discontinuity in Agent delegation chains. When a user delegates to an Agent, and that Agent in turn calls sub-agents or external tools, the original relationship graph cannot naturally extend — the permission propagation path becomes ambiguous.

Prompt Injection is a classic attack vector for permission failures in AI Agent scenarios and deserves special attention. Attackers embed malicious instructions in external content processed by an Agent — web pages, documents, emails — tricking the Agent into executing operations beyond the original task scope, such as reading sensitive files, sending data to external addresses, or performing destructive actions on behalf of the user. If an Agent holds excessively high static permissions, the damage from prompt injection is dramatically amplified, because malicious instructions can directly drive the Agent to fulfill the attacker's intent without bypassing any additional barriers. This is precisely why the principle of "least privilege" is more urgent for Agent scenarios than for traditional service accounts — an Agent's attack surface comes not only from code logic vulnerabilities, but from every piece of unstructured input it processes.

What IBAC Is — and What It Isn't

IBAC (Intent-Based Access Control) is a concept proposed specifically for Agent scenarios. Its core claim is that authorization decisions should be based on the caller's intent, not just identity or attributes.

Intent refers to the specific goal an Agent is trying to achieve at a given moment. IBAC attempts to introduce this dimension into permission evaluation — the question shifts from "does this Agent have permission to access the database" to "does this Agent's current intent require, and reasonably justify, access to that database."

To be clear, IBAC is not about letting the LLM decide what permissions to grant itself — that would introduce serious security risks. Nor is it intended to replace existing RBAC or ABAC. Rather, it functions more like an intent-verification layer on top of existing authorization mechanisms. True intent must be captured and constrained in some verifiable way, rather than relying on the model's self-declaration.

Making IBAC's "verifiable intent" requirement a reality is an active area of exploration in both academic research and engineering practice. One approach is a Task Token mechanism: when an Agent task is initiated, a trusted orchestration layer issues a token containing an explicit task description and permission scope. Every resource call the Agent makes must carry this token, and the authorization system checks whether the call falls within the intent declared in the token. Another approach is Plan Review: for high-privilege operations, the Agent is required to output its action plan before execution, which is reviewed by an independent policy engine or human reviewer for intent compliance before permissions are released. These approaches are still in early stages with no widely adopted standard, but their shared principle is: intent must be externally anchored at the task boundary, not self-declared by the model during execution.

How to Choose

For practical AI Agent deployments, a single model is rarely sufficient. The reasonable approach is typically a layered combination: use RBAC or ReBAC to define the resource boundaries an Agent can reach, use ABAC to layer in environmental and contextual conditions, and then consider using an intent layer for dynamic narrowing.

The key principle is: permissions granted to Agents should be revocable, auditable, and minimal by necessity — and should be dynamically adjusted based on task context. Any approach that statically grants high-level permissions to an Agent leaves a security gap. As Agent autonomy increases, the evolution of authorization models from static identity toward dynamic intent will remain an ongoing engineering challenge.