RBAC vs ABAC for AI agents
By Matt Doughty, CEO & Co-Founder of Prefactor ·
Role-based access control assigns agents fixed permission bundles; attribute-based access control evaluates each action against attributes of the agent, the resource, and the context. Agents strain RBAC faster than human users do, because an agent's safe permission set changes with its task, its confidence, and its risk profile.
| Dimension | RBAC | ABAC |
|---|---|---|
| Model | Agent gets a role; role carries permissions | Policy evaluates agent, action, resource, context per call |
| Fits agents when | Few agents with stable, narrow jobs | Permissions should vary by task, data class, or risk score |
| Granularity | Coarse — roles accumulate permissions over time | Fine — can express "may refund up to $100 to verified customers" |
| Operational cost | Low to start, role explosion at scale | Policy authoring and testing discipline required |
| Auditability | Easy to read, hard to keep accurate | Decision logs show exactly why each action was allowed |
| Typical tooling | Native IAM roles | Policy engines (e.g. OPA, Cedar) at the tool-call boundary |
The verdict
Start agents on RBAC because it is what your IAM already speaks, but expect to hit its ceiling early: the first time you want an agent's permissions to depend on transaction value, data classification, or its own risk score, you are describing ABAC. The pragmatic pattern is RBAC for coarse boundaries (which systems at all) and ABAC at the tool-call layer for the decisions that actually vary.