What is RBAC (role-based access control)?

Role-based access control grants permissions to roles, and people to roles, rather than attaching permissions to individuals. An administrator defines what "Support agent" may do once; everyone who holds that role inherits it, and someone changing jobs changes role rather than having twenty permissions edited by hand.

It has been the default model for enterprise software for thirty years because it scales with headcount instead of with people × permissions, it maps onto how companies already describe themselves, and it makes access reviews tractable — you audit a dozen roles, not nine hundred users.

The pieces

• Permission — one allowed operation: read an invoice, void an invoice.
• Role — a named bundle of permissions: "Bookkeeper".
• Assignment — a person holding a role, ideally pushed from the directory by SCIM rather than maintained by hand.
• Scope — the boundary a role applies inside: a team, a workspace, one connected system.

Most real systems also need resource-level rules that pure RBAC cannot express — this person may read this one account — which is where people reach for ABAC (attribute-based) or ReBAC (relationship-based) models, or quietly bolt exceptions onto their roles.

Where RBAC breaks for AI

This is the part worth reading, because it is new and most products have not worked it out.

Classic RBAC assumes the actor is a person operating a user interface. A person who holds "can void an invoice" sees a button, and pressing it is a deliberate act. An AI agent holding the same permission has a tool called void_invoice, and calling it is the output of a probabilistic judgement about a sentence.

Three things follow.

Role granularity that was fine becomes dangerous. A "Bookkeeper" role bundling forty operations is reasonable for a person who will use six of them and ignore the rest. Handed to an agent, all forty are live, all the time, selected by a model reading tool descriptions. The useful unit becomes the individual tool, granted by name.

Read and write stop being comparable risks. For a person, both are a click. For an agent, a wrong read produces a wrong sentence and a wrong write produces a wrong ledger. That asymmetry argues for read-by-default and writes granted individually — which is how Memtro works: every connector reads by default, and an action is only available once an administrator has granted that specific tool by name.

The agent must act as the asker, not as itself. A system where the agent holds its own service account with broad rights has no access control worth the name: every user effectively inherits the agent's permissions. The question to ask any AI product is not does it support RBAC but whose authority does a tool call run with? If the answer is "the integration's", the roles are decoration.

And the caller can be argued with. A support ticket containing instructions is data the model is about to read. Prompt injection has no clean fix, so the containment is boring and structural: least privilege per tool, writes granted deliberately, and a log that shows which tool ran with whose authority.

What good looks like

• Permissions scoped to a tool, not a whole integration.
• Read separated from write, with write off until granted.
• The agent executing as the person who asked, so answers cannot include records that person could not open.
• Grants set per team, so Finance and Support do not share a permission set by accident.
• An audit log of grant changes, not just of logins — a permission that changed with nobody able to say when is not governed.
• Provisioning from the directory, so the role someone holds follows the job they do.

RBAC, SSO and SCIM together

The three are routinely sold as one bundle and answer three different questions. SCIM decides whether an account exists. Single sign-on decides whether this login is allowed. RBAC decides what the account may do once in. A product can have the first two immaculately and still hand every user the same unscoped access — which is the failure mode worth checking for, because it is invisible from the login screen.