ABAC vs RBAC for AI Agent Permission Models

That mismatch, between permissions that are supposed to expire and a model that has no concept of expiration, is the entire argument for why role-based access control is running out of road. The question is what to build on top of it now that software, not people, is making most of the calls.

RBAC was designed for humans with stable jobs, not for software acting on their behalf

Role-based access control earned its dominance by answering one question cleanly: does this user have a role that grants this permission? A Finance Manager's scope of work is knowable before she ever logs in, stable enough to write down in a policy document and leave alone for months. That predictability is the entire engine of RBAC. It lets an organization map people to roles and roles to permission bundles once, then stop thinking about it.

NIST formalized this logic in INCITS 359-2012, which defines RBAC across four components: Core RBAC, Hierarchical RBAC, Static Separation of Duty Relations, and Dynamic Separation of Duty Relations. Each layer adds nuance, hierarchy, conflict-of-interest constraints, session-level limits, but all four assume that the caller is a person occupying a job function that doesn't change by the hour. Onboarding becomes a single role assignment. Offboarding becomes a single revocation. Auditing becomes a query over roles rather than a forensic crawl through thousands of individual grants. That operational simplicity is built into RBAC's design, and it's the reason RBAC became the default model for enterprise identity in the first place, and for a workforce of humans with job titles, it still holds up.

How AI agents violate RBAC's assumptions about the caller

An agent's permission needs are a function of the task in front of it and who delegated that task, not of any role someone assigned it last quarter. That's a structural break in the model itself, not something a configuration change can fix.

Consider what a single prompt can trigger: an agent reads an issue tracker, pulls a record from billing, sends a follow-up email, all before finishing one task, and none of that sequence was known in advance, not even by the person who wrote the prompt. As WorkOS's analysis puts it, the whole discipline is built on the assumption that a caller's needs can be described ahead of time, and agents broke an assumption the other three models share: that you can know what a caller needs before it starts running.

Scaled across a fleet of agents running in parallel, the failure compounds. A role like "clinical documentation agent," granting blanket access to a PHI repository, cannot express that this particular instance is authorized to touch three specific encounter records for one patient, on behalf of one clinician, expiring the moment the session ends. RBAC has no field for "on behalf of this specific user" and no field for "during this specific session," and those two dimensions define legitimate agent authorization in practice. Grant an agent a role broad enough to complete any job it might encounter, and that breadth doesn't retract when the job is done. It persists, permanently, for every future run, long after the task that justified it has ended.

Faced with that gap, most teams reach for the same fix: more roles. Split "support_engineer" into tier-1 and tier-2 variants, add a "read_only_agent," repeat until there are forty overlapping roles nobody can fully explain. The DEV Community's analysis calls this role explosion the symptom, not the disease. The CIAM Compass guide puts a number on the ceiling: maintenance cost rises sharply past a handful of roles, and beyond that point the system becomes genuinely unmanageable. Adding roles to patch a context problem just produces more roles with the same missing context.

What ABAC adds: context-aware policy evaluation at request time

Attribute-based access control answers the question RBAC structurally cannot: given everything knowable right now about the caller, the resource, and the environment, does this specific action pass policy? That's a live evaluation performed at request time, against a table assembled months earlier.

Where RBAC asks what role a subject holds, ABAC asks about attributes of the subject (which team, what clearance, who delegated the task), attributes of the resource (owner, classification, sensitivity), and attributes of the environment (time of day, whether there's an active incident), all evaluated together the moment a request comes in. That lets a single policy encode constraints that would take three separate roles to approximate badly: a support agent reads tickets only in its own team's queue, acts during business hours on a live incident but not unattended at 3am, and acts only on behalf of the specific user who invoked it, not anyone who happens to share its role.

Most production ABAC today runs on Open Policy Agent with Rego as the policy language, which the CIAM Compass guide identifies as the dominant choice as of 2026, replacing the older XACML standard.

ABAC's real costs: policy complexity, authoring burden, and audit difficulty

ABAC's expressiveness is genuine, but it doesn't eliminate the governance burden. It relocates it, from role sprawl into policy complexity, and a badly maintained ABAC deployment is harder to audit than forty overlapping roles ever were.

Rego is a real programming language, and policy changes typically need dedicated review before they ship, because allow-deny precedence errors and missing default-deny clauses are subtle mistakes that don't appear until something breaks in production. The DEV Community analysis makes the honest tradeoff explicit: RBAC is easier to audit, since "show me everyone with the admin role" is a one-line query, while ABAC moves that same thinking into policy definitions rather than eliminating it. The labor shifts into policy definitions instead of disappearing. It just changes shape.

ABAC also isn't the right tool for every access problem. When the access model genuinely reduces to a relationship, Alice can edit Project X, forcing that into attribute logic adds complexity for no payoff. That's a ReBAC problem wearing an ABAC costume. ABAC earns its cost when policy logic genuinely resists reduction to roles, when the team authoring policy has the competence to do it safely, and when the access decision needs context that no role assignment could ever capture. An unmaintained ABAC system is harder to audit than RBAC, not safer. It's a harder one to audit, because the same discipline RBAC required of role definitions is now required of policy definitions, and skipping it doesn't make the requirement disappear.

ReBAC, and the multi-agent delegation problem RBAC and ABAC don't reach

Relationship-based access control handles per-object sharing that both RBAC and ABAC handle awkwardly, but it doesn't close the real gap. None of the three models tracks the chain of accesses that a multi-agent workflow actually produces.

ReBAC, popularized by Google's Zanzibar paper, decides access by traversing a graph of stored relationships, checking whether user:alice is editor of document:roadmap-v3, and whether a path exists from caller to resource carrying the right relationship. Zanzibar-style implementations now include OpenFGA, SpiceDB from Authzed, Permify, Ory Keto, Auth0 FGA, and WorkOS FGA, each built to check relationship-level permissions across large numbers of objects. The model works well when permission really is a graph edge. It breaks for agents for a specific reason: the edge has to exist before the check can run, and an agent working a genuinely novel task needs access to resources nobody has drawn a relationship to yet. The organization is left choosing between pre-granting broad access, which defeats the purpose of the model, or letting the agent stall on a resource it has a legitimate reason to touch.

The deeper problem sits above all three models, not inside any one of them. ABAC evaluates each access decision in isolation and has no mechanism for constraining what happens when individually authorized accesses accumulate into something nobody approved as a whole, a propagation problem a 2025 arxiv paper on authorization in multi-agent systems treats as the strongest case against relying on either model by default. Picture a chain of API calls across several cooperating agents: each call, checked individually, satisfies RBAC, satisfies ABAC, satisfies ReBAC. The chain as a whole still violates a constraint nobody wrote down, because no model in the stack is watching the chain itself, only its individual links. RBAC compounds the problem further by having no native concept of transitive delegation. It cannot express "this agent may touch this dataset only while acting on behalf of this user, inside this workflow." That sentence simply has no home in a role definition.

Intent-based access control: what it adds on top of the existing models

Intent-based access control checks something the other three models have no mechanism for: whether a given API call is actually consistent with the task the agent was assigned to perform.

RBAC checks role. ABAC checks attributes. ReBAC checks relationships. IBAC checks intent: it asks what the caller is currently trying to accomplish, and a call that cleanly passes all three prior checks can still get flagged if it has nothing to do with the job the agent was actually given. The illustration that makes this concrete is an agent authorized for a customer-lookup task in the CRM that starts calling billing export endpoints. RBAC approves it. ABAC approves it. ReBAC approves it. IBAC notices when the call falls outside the stated task and routes it for approval or blocks it.

The term itself is unsettled. Several vendors shipped products under the IBAC name during 2026, each with a different definition, and WorkOS's September 2026 analysis notes the term has a history in access control going back well before any of them, with real disagreement remaining about what it means. It doesn't replace the baseline authorization that determines what the agent may ever be allowed to do.

Incidents where governance gaps cost enterprises

This isn't theoretical risk. Cyera's 2026 research documented 344 verified incidents of agent-inflicted damage between September 2023 and May 2026, and in most of them the agent was doing what it was built to do, without the guardrails to keep that behavior bounded.

Three cases from that research make the pattern concrete. A coding agent at PocketOS, a car-rental software vendor, deleted the company's production database, then its backups. An API enrichment loop ran unsupervised long enough to accumulate a large, undetected charge before anyone caught it. An AWS-connected agent attempted to "delete and recreate" a production environment and triggered a 13-hour outage. None of these required a malicious actor. Each agent was simply granted scope wider than the task in front of it, and nothing in its permission model noticed the mismatch.

The exposure is larger than any single incident, because most organizations don't know how many agents they're running. A Harmonic Security analysis of enterprise prompts found that the typical CIO's estimate of AI tools in use across the organization undercounts the real figure by several times once actual monitoring is turned on, and most of those unaccounted-for tools bypass IT governance entirely. The IBM Cost of a Data Breach Report 2025 found that among organizations reporting an AI-related security incident, a large majority lacked proper AI access controls. And the governance gap has a regulatory deadline attached now: the EU AI Act's high-risk system requirements took effect August 2, 2026, at a moment when over half of organizations still lack a systematic inventory of the AI systems running in production. Access control has stopped being purely a security conversation. It's now a compliance exposure with a filing deadline.

Building a mature enterprise authorization stack for agents

The organizations handling this well are layering RBAC and ABAC together. They're layering both, adding dedicated identity infrastructure for agents specifically, and enforcing policy at every single tool invocation through a governed distribution layer rather than trusting any one check to catch everything.

Uber's internal AI infrastructure writeup describes a three-layer production stack: an LLM gateway handling PII redaction, access control, and other concerns sits in front of everything else. RBAC still handles the coarse question of what an agent category may ever touch. ABAC handles the fine-grained, per-request question of what a specific instance may do right now, given everything known about the caller and the environment. ABAC is also well-positioned to meet regulatory requirements limiting access to what a specific authorized task requires, such as HIPAA's minimum necessary principle, CMMC's AC.2.006, and NIST 800-171 practice 3.1.2, constraints RBAC alone cannot express. ReBAC handles the object-level sharing questions that roles and attributes both express awkwardly. And an intent layer, whatever a given vendor chooses to call it, sits on top, watching whether the specific call being made still matches the task the agent was actually handed.

None of these models was built anticipating the others would need to coexist in one stack. That coexistence is now the job. It is here that ABAC earns its place in the stack, since agents need the access decision made live at request time rather than resolved once in advance.