Authorisation Models Guide: RBAC, ABAC, ReBAC and Policy Engines

Authentication proves who someone or something is. Authorisation decides what they may do, and it is where most access problems actually live. Over-privileged users, service accounts with wildcard permissions, applications that trust any authenticated caller and APIs that check the user but not the object all come down to authorisation design. This guide explains the main access control models (RBAC, ABAC, ReBAC and policy-based access control), how they compare, and how externalised authorisation and policy engines work. It covers how to choose and combine models for people, workloads and AI agents, how to map the work to NIST, ISO/IEC 27001, CIS and OWASP, and how to measure progress. It is written for identity architects, application security engineers and platform teams who own access decisions.

Key takeaways

• Each model fits a different problem: RBAC is simple and auditable but becomes coarse and bloated at scale, ABAC adds context, ReBAC fits sharing and ownership, and policy-based (externalised) authorisation makes decisions consistent and auditable across applications.
• Combine models rather than pick one: roles for coarse boundaries, attributes and relationships for fine-grained decisions, all evaluated by policy you can read and test.
• Externalise authorisation from application code where it pays off, so policy can be reviewed, tested, versioned and changed centrally, with every decision logged.
• Always enforce object-level and function-level checks: checking only that a caller is logged in leads to broken object level authorisation, the first risk in the OWASP API Security Top 10 2023.
• Treat workloads and AI agents as first-class subjects: give them their own identities, narrow per-task permissions and per-action decisions, never a borrowed human role or an account-wide token.

The models

All four models answer the same question: may this subject perform this action on this resource, now? They differ in what information the decision uses and where that information lives. The OWASP Authorization Cheat Sheet notes that the choice between models "has significant implications for the entire SDLC and should be made as early as possible".

Role-based access control (RBAC)

Permissions are grouped into roles, and roles are assigned to identities. "Accounts payable clerk" can create invoices; "finance approver" can approve them. NIST's RBAC project describes the model as formalised in 1992 by David Ferraiolo and Rick Kuhn and later adopted as ANSI/INCITS 359-2004, revised as INCITS 359-2012. NIST SP 800-53 Rev. 5 control AC-3(7) explains that when users are assigned to roles "they inherit the authorizations or privileges defined for those roles", which simplifies administration because privileges are not assigned to every user directly.

• Strengths: easy to understand, audit and certify; supported by almost every directory, IdP, database and cloud platform; maps cleanly to job functions and access reviews.
• Weaknesses: role explosion as exceptions pile up; cannot express context such as time, location, data sensitivity or ownership; tends towards over-privilege because broad roles are easier to grant than narrow ones.

NIST SP 800-162 describes the failure mode directly: trying to express dynamic decisions with roles "would require the creation of numerous roles that are ad hoc and limited in membership, leading to what is often termed 'role explosion'". See the Role Mining and Role Design Guide.

Attribute-based access control (ABAC)

NIST SP 800-162 defines ABAC as a methodology where authorisation is determined "by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships". A typical rule: "Clinicians may read records of patients in their department during their shift from a managed device." SP 800-162 also notes that access decisions "can change between requests by simply changing attribute values", so new joiners need the right attributes, not new rules.

• Strengths: fine-grained and contextual; fewer roles; adapts as attributes change; works across organisations without pre-provisioning every identity.
• Weaknesses: depends on accurate, timely attributes from authoritative sources; policies can be hard to reason about and audit without good tooling; the NIST RBAC project page describes ABAC as "easy to set up but complex to manage".

Relationship-based access control (ReBAC)

Access follows relationships in a graph: a user can edit a document because they are a member of the team that owns the folder containing it. The best documented example is Google's Zanzibar paper (USENIX ATC 2019), which stores access control lists as relation tuples such as doc:readme#viewer@group:eng#member (members of group eng are viewers of doc readme) and derives inherited permissions through rewrite rules. According to the paper, Zanzibar serves Calendar, Cloud, Drive, Maps, Photos and YouTube and scales to trillions of access control lists.

• Strengths: natural for collaboration, multi-tenant SaaS, hierarchies and delegation; scales to large numbers of objects; ownership and sharing are first-class.
• Weaknesses: requires maintaining a relationship graph that stays consistent with application data; "why does this user have access?" can involve a long chain of relations.

Policy-based access control (PBAC) and externalised authorisation

Authorisation logic is written as policy and evaluated by a policy decision point (PDP). Applications, gateways and agent runtimes act as policy enforcement points (PEPs), asking the PDP for decisions. PBAC can implement RBAC, ABAC and ReBAC rules together, because roles, attributes and relationships are all just inputs to policy. The Open Policy Agent project describes the goal as decoupling policy from the service "so that the people responsible for policy can read, write, analyze, version, distribute, and in general manage policy separate from the service itself".

• Strengths: consistent decisions across applications; policy as code, versioned and tested; central audit of decisions; one place to change a rule.
• Weaknesses: adds a runtime dependency and latency; requires integration work in each application; a badly governed policy repository becomes a single point of failure.

Comparison

No model wins on every dimension. The table summarises the trade-offs practitioners meet most often.

The OWASP Authorization Cheat Sheet goes further than most guidance and recommends that ABAC and ReBAC "should typically be preferred for application development", citing support for fine-grained logic, multi-tenancy and easier management at scale. In practice most organisations keep RBAC for workforce provisioning and access reviews and add attributes and relationships inside applications.

Standards and tools

Most externalised authorisation designs use the component vocabulary from NIST SP 800-162 and the OASIS XACML 3.0 standard. Knowing the parts makes vendor and open source architectures easier to compare.

• OAuth scopes and Rich Authorization Requests: OAuth scopes express coarse delegated permissions. RFC 9396 adds the authorization_details parameter because scopes are "not sufficient to specify fine-grained authorization requirements, such as 'please let me transfer an amount of 45 Euros to Merchant A'". See the OAuth 2.0 and OpenID Connect Guide.
• OpenID AuthZEN Authorization API 1.0: approved as a Final Specification in January 2026, it standardises the PEP-to-PDP interface. A request carries a subject, resource, action and context; the API also defines batched evaluations and search endpoints for discovering permitted subjects, resources or actions.
• XACML 3.0: an OASIS Standard published in January 2013 that defines an XML policy language, combining algorithms and obligations. It is less common in new builds but still underpins many enterprise authorisation products and defined much of the vocabulary.
• Policy languages and engines: general-purpose engines such as Open Policy Agent evaluate declarative policy over structured input and data, and can run as a sidecar, host daemon or library.
• Relationship stores: the Zanzibar paper's relation tuples, userset rewrite rules and consistency tokens (which it calls zookies) give a useful checklist when evaluating any ReBAC system: how are relations modelled, how is inheritance expressed and how are stale reads prevented?
• NIST SP 800-162 and SP 800-53: SP 800-162 defines ABAC concepts and enterprise considerations; SP 800-53 Rev. 5 includes AC-3(7) for RBAC, AC-3(13) for ABAC and AC-24, which separates access control decisions from enforcement.

Authorisation for non-human identities and AI agents

Service accounts, workloads and AI agents act at machine speed and often hold long-lived credentials, so coarse authorisation does the most damage here. The OWASP Non-Human Identities Top 10 lists "Overprivileged NHI" as NHI5:2025, noting that developers or administrators "may assign NHIs with significantly more privileges than required for their function".

Service accounts and workloads

• One identity per workload: service accounts and workloads usually get roles or cloud IAM policies. Keep them per workload, least privilege and owned. See the Service Account Security Guide.
• Use conditions: cloud IAM policies already combine roles with attribute conditions (resource tags, source network, time). Use them to tighten broad grants. See the AWS IAM Policies and Roles Guide and the Google Cloud IAM and Service Accounts Guide.
• Remove unused permissions: compare granted permissions with observed use and right-size. See the Cloud PAM and CIEM Guide.

AI agents

AI agents need task-scoped, per-action decisions that combine the agent's own permissions with those of the user it acts for. A role is too coarse: the same agent may be allowed to read a ticket but not close it, or to draft a payment but not send it. OWASP LLM06:2025 Excessive Agency names three root causes (excessive functionality, excessive permissions and excessive autonomy), and each is an authorisation design problem.

• Decide per tool call: put a PEP in front of every tool or MCP server and ask the PDP about the specific action and resource. See the MCP Security Guide.
• Represent delegation explicitly: token exchange (RFC 8693) can carry both the user and the acting agent, so policy can evaluate both. See the OAuth Token Exchange and Delegation Guide.
• Filter retrieval by permission: agents that read documents must see only what the requesting user could see. See the Permission-Aware RAG Guide.

See the AI Agent Authorisation Guide for the full agent pattern.

Designing an authorisation strategy

A workable strategy chooses a model per use case, puts decisions in a small number of well-governed places and keeps the data that feeds them accurate.

1. Start with RBAC for coarse access to applications and systems, based on job function, with a small, well-governed role catalogue. CIS Safeguard 6.8 asks organisations to define and maintain role-based access control and review it "at a minimum annually, or more frequently".
2. Add attributes and relationships for fine-grained, context-dependent decisions within applications.
3. Externalise where it pays off: new applications, shared APIs, regulated data and AI agent tool access.
4. Enforce object-level checks in every API. OWASP API1:2023 says every endpoint that receives an object ID "should implement object-level authorization checks", and that comparing the session user ID with the ID parameter "could address only a small subset of cases".
5. Deny by default: the OWASP Authorization Cheat Sheet recommends that an application "should be configured to deny access by default" and that permissions be validated on every request.
6. Govern the model: review roles and policies, test policy changes, and log decisions for audit.

Separation of duties belongs in the design from the start rather than as a later report. See the Segregation of Duties Guide and IAM and IGA Basics.

Detection and monitoring

Externalised authorisation produces a valuable by-product: a decision log. Every PDP decision records who asked, for what, on which resource and why it was allowed or denied. The OWASP Authorization Cheat Sheet recommends consistent, parseable logging and centralising logs in a SIEM.

• Spikes in denials from one subject across many object IDs can indicate ID enumeration against an API (the BOLA pattern).
• Calls to administrative functions from non-administrative subjects point to probing for broken function level authorisation (OWASP API5:2023).
• Workloads using permissions they have never used, especially destructive ones, deserve an alert before they deserve an incident.
• Policy and role changes should be logged, reviewed and correlated with decision changes. SP 800-53 AU-6 asks for audit records to be reviewed and analysed for indications of inappropriate or unusual activity.
• Agent actions should be logged with the agent identity, the delegating user and the tool call. See the AI Agent Observability and Incident Response Guide.

Common failure patterns

• Role explosion: hundreds of near-duplicate roles created for individual exceptions, which nobody can review meaningfully.
• Scattered logic: authorisation checks spread through application code, impossible to audit and easy to miss on a new endpoint.
• Authentication mistaken for authorisation: APIs that check the caller is logged in but not whether they may access the specific object or function.
• Account-wide tokens for narrow jobs: in the PocketOS Database Deletion 2026, an AI coding agent found a token created for managing custom domains that, according to the provider, carried authority over the whole account, and used it to delete a production volume.
• Stale attributes: department, clearance or employment status that lags reality, so ABAC decisions are wrong. SP 800-162 stresses that attributes come from authorities responsible for them. See the Joiner-Mover-Leaver Guide.
• Stale relationships: the Zanzibar paper's "new enemy" problem, where a user removed from a folder still sees new content because a check used an old access list.
• Client-side checks: hiding buttons in the interface while the server accepts the request. OWASP says client-side checks "should never be the decisive factor".
• Untested policy changes: policy edited in production without regression tests, opening or closing access silently.

Framework mapping

The table maps authorisation practices to the frameworks most organisations report against. Control IDs were checked against the published texts.

Metrics that show progress

Pick a handful of measures that show whether access is getting narrower and decisions more consistent. See the Identity Security Metrics Guide.

Implementation roadmap

Pair the roadmap with standing-access reduction. See the JIT Access Guide and the Zero Trust Identity Guide.

Practitioner checklist

• Choose models per use case and document the rationale.
• Keep the role catalogue small; use attributes and relationships for exceptions.
• Deny by default and validate permissions on every request, server-side.
• Enforce object-level and function-level authorisation on every API endpoint.
• Externalise authorisation for new applications, shared APIs and AI agent tools.
• Source attributes and relationships from authoritative systems and keep them current.
• Give every workload and agent its own identity with narrow, per-task permissions.
• Version, test and peer-review policy before it reaches production.
• Log every decision with subject, action, resource and outcome, and review the logs.
• Review roles and privileges regularly. See the Access Reviews Guide.

Standards and references

• NIST: SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations
• NIST CSRC: Role Based Access Control project
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: Cybersecurity Framework (CSF) 2.0
• OpenID Foundation: AuthZEN Authorization API 1.0
• IETF: RFC 9396, OAuth 2.0 Rich Authorization Requests
• OASIS: eXtensible Access Control Markup Language (XACML) Version 3.0
• USENIX: Zanzibar, Google's Consistent, Global Authorization System
• OWASP: Authorization Cheat Sheet
• OWASP: API1:2023 Broken Object Level Authorization
• OWASP: API5:2023 Broken Function Level Authorization
• OWASP: Non-Human Identities Top 10 2025

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · API Security Guide · Role Mining and Role Design Guide · Zero Trust for AI Agents Guide · Segregation of Duties Guide