RBAC
Role-based access control — permissions granted by role rather than to individuals.
category ▸ Agents & Identity
RBAC, in plain language.
Role-based access control assigns permissions to roles, and roles to people, rather than wiring entitlements to each individual. It is the workhorse of enterprise authorization: define what an administrator, a reviewer, or an operator may do, then grant access by placing someone in a role.
RBAC keeps authorization legible and auditable. Instead of inspecting thousands of individual grants, you reason about a handful of roles, which makes it tractable to answer "who can change this control?" — a question every security review asks.
How Cortex implements it.
This term isn't abstract here — it maps to a real capability in the runtime. Here is exactly how Cortex enforces or relates to it.
Cortex scopes sensitive operations behind roles: setting oversight modes, approving or denying actions, break-glass, changing budgets, and managing solution packs all require a platform-admin session, while reads are tenant-scoped.
RBAC complements Agent IAM: roles govern which humans may change controls and policies, while Agent IAM governs what each agent identity may do — two layers of least privilege over the same runtime.
Keep building the vocabulary.
These terms sit next to this one in the governed-AI model — follow the thread to see how the controls connect.
Agent IAM
Identity and access management that treats each AI agent as a governed enterprise identity.
Tenant isolation
Strict separation so one customer's data and agents can never reach another's.
Policy-as-Code
Governance rules written as testable, versioned code that the runtime enforces directly.
Break-glass
An audited override that lets an authorized human force a held action through, with a recorded reason.
See RBAC enforced, not just defined.
Join the waitlist and watch the controls in this glossary return real verdicts, seal real evidence, and trace every fact back to its source.