RBAC

Role-Based Access Control (RBAC) is a model for governing who can do what by assigning permissions to roles and then assigning roles to users, rather than granting rights to individuals one at a time. Formalized by NIST researchers in the 1990s, it became the default way large organizations reason about authorization because it maps cleanly onto how people actually work: a job function gets a role, and the role carries the permissions. It is the access model most API platforms reach for first.

• Roles, not identities - Permissions attach to named roles like admin, editor, or read-only, and users inherit them by membership.
• Least privilege - Roles are scoped to exactly what a function needs, shrinking the blast radius when credentials are compromised.
• Separation of duties - Conflicting capabilities can be split across distinct roles so no single actor holds too much power.
• Auditability - Because access flows through roles, you can review and explain who can reach what without untangling per-user grants.

In API operations, RBAC shows up everywhere from the management console down to the request path. Providers use it to control who can rotate keys, publish specs, or view billing, and it increasingly governs the API surface itself through scopes and claims carried in OAuth tokens and JWT assertions. As teams move toward finer-grained and attribute-based models, RBAC remains the baseline that most governance and agentic-access policies are expressed against, which is why it stays one of the most widely implemented controls across the providers I score.