Access control: RBAC, ABAC, and least privilege.
Every system that holds other people's data answers one question over and over: who is allowed to do what, to which records, right now. That is access control.
This is a plain-language guide to the field. We walk it the way it is built: what access control is, why it is hard, how role-based and attribute-based models work, what they make possible, and where the field is heading. The source papers and the standards behind each idea are linked, so you can read them yourself. It is educational. It makes no claim about how any one product is built.
Who is allowed to do what, to which records.
Access control decides which subjects may perform which actions on which objects, and enforces that decision at the moment of the request.
It sounds simple until an organization has thousands of people, hundreds of teams, and data that some folks may see and others may not. The field gives three load-bearing ideas, and they build on each other.
Least privilege is the governing principle: give each person and each program only the access they need to do the job, and nothing more. Saltzer and Schroeder named it in 1975, alongside the companions a security reviewer still cites: fail-safe defaults (deny unless explicitly allowed), complete mediation (check every access), and separation of privilege. Limiting privilege limits the blast radius when something is misused, compromised, or simply wrong.
RBAC, role-based access control, is the common way to organize that. Instead of granting permissions to people one at a time, you grant permissions to roles, for example "sales rep," "sales manager," "billing admin," then put people into roles. When someone changes jobs, you change their role, not a hundred individual settings. Sandhu et al. framed the model family; the proposed NIST standard (Ferraiolo et al., 2001) unified it, and it later became an ANSI standard, INCITS 359.
ABAC, attribute-based access control, is the more flexible successor. Access is decided at request time by evaluating attributes of the person, the record, the action, and the surrounding context (department, region, time of day, deal ownership) against written policy. RBAC asks "what role are you in." ABAC asks "do your attributes, and this record's attributes, satisfy the rule." NIST SP 800-162 is the reference definition.
| Resource | Read | Update |
|---|---|---|
| West team deals | Allow | Allow |
| Other team deals | Deny | Deny |
| Billing settings | Deny | Deny |
The hard part was never the mechanism.
Granting access is easy. Keeping privilege minimal, and keeping intent legible as an organization changes, is the work.
People join, move, and leave constantly.
Permissions granted one at a time rot into a mess no one can reason about. RBAC exists largely to tame this: manage roles, not a tangle of individual grants.
One role per nuance does not scale.
When you try to encode every detail as a role, you can end up with more roles than users. That classic failure mode is what pushes organizations toward attributes and policy.
Access accumulates and rarely gets revoked.
Least privilege is easy to state and hard to sustain. It needs periodic review and tooling, not a one-time setup, or yesterday's access quietly becomes today's risk.
Some powers are dangerous together.
The person who creates a vendor should not also approve its payments. Access models have to express constraints, not just grants. RBAC includes static and dynamic separation-of-duty rules for exactly this.
The boundary between customers is a different problem.
In shared software, two different customers of the same vendor should never see a trace of each other's data. A cross-tenant leak is a different and more serious class of failure than an over-broad internal role. This is where the field's ideas get stressed.
"Who could access this, and why" must be answerable.
ABAC moves the difficulty into writing, testing, and governing policy: wrong policy is now a security bug. A model that cannot be explained or reviewed is a liability regardless of how it performs day to day.
Grant to roles, decide from attributes, enforce at the door.
RBAC organizes who gets what. ABAC computes the decision at request time. Both are only as strong as the point that enforces them.
1RBAC mechanics
Permissions attach to roles, people get the roles.
Core RBAC is users, roles, permissions, and sessions, plus the user-to-role and permission-to-role assignments. The indirection is the whole point: administration scales with the number of roles, not the number of people times the number of permissions.
Hierarchical RBAC adds inheritance, so a manager role inherits the rep role's permissions. Constrained RBAC adds separation-of-duty rules that keep certain powers apart. The proposed NIST standard (Ferraiolo et al., 2001) is the reference for these levels, and Sandhu et al. (1996) is where the model family was first framed.
| Person | Role | Allowed action |
|---|---|---|
| Dana | Rep | View assigned accounts |
| Wei | Manager | View team pipeline |
| Sam | Billing | View invoices |
2ABAC mechanics
The decision is computed, not pre-baked.
A policy is a set of rules over attributes. At request time the decision point gathers attributes about the subject, the object, the action, and the environment, and evaluates the rule. For example: permit if the request's team matches the record's owning team, the role is "manager," and the time is within business hours.
Because decisions are computed rather than stored, ABAC can express fine-grained, context-aware rules that would need an unwieldy number of roles to capture. That flexibility is also its operational cost: the policy has to be readable, testable, and governed. Many real systems combine the two, with roles that also carry attributes. NIST SP 800-162 sets out the definitions.
- Person
- Manager · West team
- Record
- Owner team: West
- Context
- 10:24 · permitted business hours
All three conditions satisfy this example policy.
3Decision and enforcement are separate jobs
One point asks, another point answers.
NIST SP 800-162 gives the cleanest framing of the architecture, in four points. The policy enforcement point (PEP) sits in the request path, intercepts the access, and enforces the result. The policy decision point (PDP) evaluates the applicable policy and returns permit or deny. The policy information point (PIP) supplies the attribute values the decision needs. The policy administration point (PAP) is where policies are authored and managed.
Splitting decision from enforcement is what lets policy live in one place, be tested like software, and be reasoned about. It also concentrates the responsibility: a model that is bypassable is not access control. The secure posture, per Saltzer and Schroeder, is deny by default and mediate every access.
- PEP: intercept
A request to export a deal reaches the enforcement point.
- PDP: evaluate
The decision point checks policy from the PAP and attributes from the PIP.
- PEP: enforce
Apply the permit or deny decision before returning data.
4A spectrum, not rivals
Where the practice has gone.
It helps to see the models as a spectrum. Discretionary and mandatory access control are the older poles. RBAC is the workhorse of enterprise software. ABAC adds context and granularity. They are often combined rather than one replacing the other.
Two newer directions are worth naming as part of the field. Relationship-based access control (ReBAC), brought to prominence by the Zanzibar design (Pang et al., 2019), decides access by graph relationships: is this user a member of the group that owns this document. Policy-as-code engines evaluate written policy at a decision point, with the policy kept in version control and tested like software. These are described here as where the practice has gone, not as endorsements.
| Model | Example rule |
|---|---|
| RBAC | Managers can view the team pipeline. |
| ABAC | Allow when user.team equals record.team. |
| ReBAC | Allow an editor of the parent workspace. |
| Policy as code | Version and test these rules as code. |
Done well, access control is what makes a boundary real.
At the field level: administration that scales, fine-grained decisions, provable boundaries, contained blast radius, and data isolation as a feature.
Picture a CRM used by a whole sales organization. A rep should see the accounts they own and their team's, not the entire company book. A manager should see the team's pipeline. A billing admin should see invoices but not call notes. And two different customers of the same software should never see a trace of each other's data. Access control is the machinery that makes those boundaries repeatable and auditable, rather than a matter of trust and good intentions. For a sales voice co-pilot built on enterprise data, the same discipline is what lets a system answer only from data the person asking is permitted to see. That is the field's payoff, and an example for enterprise software. It is not a claim about how any one product is built.
Administration that scales.
Roles and policy let a small team manage access for a large organization without hand-editing thousands of grants.
Provable boundaries.
A clear model makes "who can see this, and why" auditable, which is what security reviews, regulators, and customers actually ask for.
Contained blast radius.
Least privilege means a mistake or a compromised account reaches less. The damage is bounded by design, not by luck.
Data isolation as a feature.
Kept well, access control is what lets one organization's data stay walled off from another's. Stated as the field's payoff, illustrated for enterprise software.
| Request context | Available data |
|---|---|
| Tenant A | Only Tenant A’s authorized records |
| Tenant B | Only Tenant B’s authorized records |
In shared software, the boundary between customers is the one that has to hold. A question is answered only from data the asker is permitted to see. Illustrative of the field, not a product claim.
For AI REV Voice's data protection and access controls, see Security & privacy. This explainer covers the underlying research.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Toward computed decisions.
The center of gravity keeps moving from static roles toward attribute- and policy-driven decisions, with RBAC and ABAC often combined rather than one replacing the other.
Judge every request on its own.
NIST SP 800-207 reframes access as a per-request decision based on identity, device posture, and context, with no implicit trust from network location. Least privilege and dynamic policy are central to it.
Externalized, version-controlled decisioning.
A shared decision point, policies kept in version control and tested like software, is becoming the norm for fine-grained access.
Graph relationships at scale.
Relationship-based authorization in the Zanzibar lineage is spreading for product-level, document-level, and record-level sharing.
Least privilege as an ongoing process.
Access certification, just-in-time elevation, and automated detection of over-privilege turn least privilege from a one-time configuration into a habit.
No model removes the need for good policy.
The mechanism was never the hard part. Keeping privilege minimal and intent legible as the organization changes is the lasting work, and it pays back as credibility.
The papers and standards behind this page.
- Saltzer, J. H. and Schroeder, M. D. (1975). The Protection of Information in Computer Systems. Proceedings of the IEEE, 63(9), 1278-1308. Open mirror.
- Sandhu, R. S., Coyne, E. J., Feinstein, H. L. and Youman, C. E. (1996). Role-Based Access Control Models. IEEE Computer, 29(2), 38-47.
- Ferraiolo, D. F., Sandhu, R., Gavrila, S., Kuhn, D. R. and Chandramouli, R. (2001). Proposed NIST Standard for Role-Based Access Control. ACM TISSEC, 4(3), 224-274. NIST CSRC.
- Hu, V. C. et al. (2014). Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication 800-162.
- Pang, R. et al. (2019). Zanzibar: A Consistent, Global Authorization System. 2019 USENIX Annual Technical Conference (USENIX ATC 19).
- Rose, S., Borchert, O., Mitchell, S. and Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
Strong boundaries are what let a co-pilot answer from the right data and nothing else. See it on a real call.
No app required. Just your phone number.