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.
Book a walkthrough and watch the controls in this glossary return real verdicts, seal real evidence, and trace every fact back to its source.