What is RBAC?
A support rep leaves the company. If access lives on their account instead of their role, someone has to remember every system they could touch and revoke each one by hand.
RBAC (role-based access control)
role-based access control
Role-based access control, or RBAC, is a permissions model that grants access to a role, such as 'billing admin' or 'support agent'. It does not grant access to a named person directly. A user gets permissions by being assigned a role, and loses them the moment that role is removed.
The role sits between the person and the permission. A permission like 'refund an order' or 'view patient records' attaches to a role once. Every person who holds that role gets it automatically, and every person who loses the role loses it automatically.
This is different from assigning permissions straight to a user account, which is how most systems start. Direct assignment works fine at five users. At fifty, you can no longer list what a given account can do without checking each permission one at a time.
It's the first page of most enterprise security reviews
A buyer's security questionnaire almost always opens with access control. The reviewer wants proof that a person's access traces back to a defined role. Not to whatever permissions piled up on their account over two years of ad hoc requests.
It also answers the question a breach investigation asks first: who could have touched this record. Per-user permissions force you to reconstruct history. Roles give you the list of people who held that role on that date.
AI agents change what needs a role. An agent that reads customer records or triggers a refund is an actor with access, the same as an employee. On builds where we add agents, we scope their roles tighter than the human role they act for. An agent handling support tickets gets read access to the ticket and the order history. Not the billing system the human agent could also open. Nobody reviews each call an agent makes, so the role has to be narrow from the start.
- 01A role change moves a person in or out of a permission set in one action.
- 02You can answer 'who could see this' from the role list, not from account history.
- 03An AI agent gets its own role, scoped tighter than the human it acts for.
- PermissionOne capability, named precisely.
- RoleA named bundle of permissions.
- AssignmentA user or agent gets the role.
- AccessGranted for as long as the role holds.
- RemovalUnassign the role, access ends.
The permission never touches the person directly. The role is the only thing assigned or removed.
Common questions
01What is an example of RBAC?
A hospital system with 'nurse', 'physician' and 'billing clerk' roles is a common example. A nurse can view a patient's chart but not billing records. A billing clerk can view invoices but not clinical notes. Moving someone from nurse to charge nurse changes their access the moment their role changes, with no separate permission edit.
02How is RBAC different from just assigning permissions directly?
Direct assignment attaches a permission to one account at a time, so reviewing or revoking access means checking every account individually. RBAC attaches permissions to a role once, and every account holding that role inherits the change automatically. The difference shows up at review time, not at setup time.
03Does RBAC apply to AI agents?
Yes. An agent that reads or changes data is an actor with access, and it needs a role like any other. The role should match exactly what the agent's task requires. That is usually narrower than the equivalent human role, since nobody reviews an agent's calls one by one as they happen.
04What is the difference between RBAC and ABAC?
RBAC grants access by role membership. Attribute-based access control (ABAC) grants access by evaluating attributes at request time, such as time of day or the record's department. Roles are simpler to audit. Attributes handle conditions a fixed role cannot express. Many systems use RBAC for the broad structure and add attribute checks where a role alone is too coarse.
