Role-based access control (RBAC) is the standard model for governing who can do what inside a platform. In AI operations specifically, it solves a structural problem: the people who deploy agents, the people who set budgets, and the people who review audit logs are not the same people, and they should not share the same permissions. A well-designed RBAC system lets you map fine-grained permissions to real team structures and enforce the principle of least privilege across every surface of your AI control plane. For a comparison of RBAC with attribute-based approaches, see RBAC vs ABAC for AI platforms.
Why AI operations makes RBAC harder
Most SaaS tools get away with three or four roles — admin, editor, viewer, billing — because the operations they expose are relatively uniform. An AI operations platform is different. You have users who configure guardrails, users who provision new agent connections, users who manage team membership, users who read usage reports, and users who handle billing disputes. These are not cleanly nested job functions. A security engineer probably needs the guardrail controls but not the billing console. A finance analyst needs cost reports but not agent provisioning.
Flat, hard-coded roles force a choice between over-permissioning (giving the security engineer a full admin role because there is no narrower option) and under-permissioning (denying the finance analyst access entirely because the viewer role does not include cost exports). Both outcomes undermine security.
The deeper issue is that over-permissioned accounts in AI platforms carry a different risk profile than in conventional SaaS. A user with unnecessary agent-provisioning access can register a rogue agent. A user with unnecessary security-settings access can weaken authentication requirements. The blast radius of a compromised or misconfigured account scales with the permissions attached to it. For a deeper look at how compromised credentials can be exploited in agent contexts, see Threat Model: Agent Credential Theft.
Built-in roles as the foundation
Every organization starts with a set of built-in roles that cover the common cases without requiring any configuration. The organization owner has full administrative authority. Members get read access and the ability to participate in workflows scoped to their teams. Billing administrators handle the financial side without touching operational controls.
Built-in roles are layered on top of each other in a defined hierarchy. This rank ordering matters for enforcement: a member cannot modify a setting that requires a higher-ranked role. The hierarchy also governs who can invite whom — you cannot grant a role higher than your own.
This foundation covers most organizations at the start. The problem surfaces when teams grow, responsibilities specialize, and the gap between "full admin" and "plain member" becomes too wide to bridge with the built-in options alone.
Custom roles and the permission catalogue
Custom roles address the gap. Instead of choosing from a fixed menu of roles, an organization owner can define a role by selecting from a catalogue of individual permissions grouped by category. The categories correspond to functional areas: agent management, workflow operations, security settings, billing, audit access, team administration, and so on.
Each permission in the catalogue maps to one or more specific API operations. A view-connections permission allows a user to read agent connection details, while a separate manage-connections permission allows creating and deleting them. The two are distinct, so you can give a user read-only access to connections without granting write access.
Building a custom role is straightforward: name the role, select the permissions that match the job function, and save. The role is then available to assign to any member of the organization. Roles can be updated at any time — the change propagates immediately to all users who hold the role.
Assigning and removing roles
Role assignment is restricted to organization owners. This is an intentional design boundary. If any sufficiently privileged user could grant custom roles, you would quickly end up with privilege escalation paths where users grant themselves or colleagues elevated access outside of any review process.
When an owner assigns a custom role to a user, that user gains the union of permissions across all roles they hold: their built-in role plus any custom roles assigned to them. Removing a role assignment revokes those permissions immediately — no logout or manual session refresh required.
Users can always read their own effective permissions. This is useful for understanding what a user can and cannot do without requiring them to contact an administrator. Owners and billing administrators can also inspect the effective permissions of any member in the organization, which is the appropriate tool for access reviews and audit preparation.
Preventing privilege-graph reconnaissance
An easily overlooked risk in RBAC systems is that the role and permission structure itself is sensitive data. If a plain member can query the permissions assigned to every other user, they can map out which accounts are high-value targets for social engineering or credential theft.
Praesidia enforces a self-or-privileged read rule on permission queries. A plain member can retrieve their own roles and permissions. They cannot enumerate the permission graph for other users. Only owners and billing administrators have visibility into the broader membership privilege structure.
This boundary is enforced server-side, so it cannot be bypassed by a client that constructs requests outside the standard interface.
Least privilege in practice
Translating least privilege from a principle into a real access model takes some deliberate thought. A useful starting exercise is to list the distinct job functions that interact with your AI platform, then identify the minimum permission set each function actually needs to do its job. For a broader framework on implementing least privilege for agents as well as human operators, see how to implement least privilege for AI agents.
A workflow author needs to create and edit workflows but not manage security policies. Grant workflow creation and editing permissions, not security configuration access.
A support engineer triaging agent failures needs to read task logs and connection status but not modify them. Grant read access to tasks and connections, not the corresponding write permissions.
A compliance reviewer needs audit log access and the ability to export reports but no operational controls at all. Grant audit viewing and report export permissions only.
None of these job functions fits neatly into a generic admin or member role. Custom roles let you define them precisely, and then you can audit them against the actual permission catalogue to confirm there is no excess.
Keeping roles from sprawling
Custom roles are only useful if they stay manageable. Left unchecked, organizations tend to accumulate dozens of near-identical roles that were created for slightly different circumstances and never cleaned up. When roles sprawl, it becomes impossible to understand who actually has access to what.
A few practices help. First, name roles after the job function, not the person or team. Security Reviewer survives org changes; Alice's Custom Role does not. Second, treat roles as shared resources, not individual grants. If two people need the same capability set, assign them the same role. Third, review roles periodically against the actual permission catalogue. If a role contains permissions that no current holder actually uses, narrow it.
Access reviews are easier when your roles are few, named for functions, and assigned to multiple people — because the question shifts from "what can each individual do?" to "what does each function need?" For how to approach a systematic audit of agent access across your organization, see How to Audit AI Agent Activity.
Common questions
Can a custom role grant permissions that exceed the assigning owner's own permissions? Assignment is restricted to organization owners, who hold the highest built-in rank. The owner-only assignment gate means that any custom role — including those carrying sensitive permissions — can only be created and assigned by an owner. This is worth noting when conducting access reviews: verify that custom roles carrying sensitive permissions are assigned narrowly.
What happens to a user's access when a custom role is deleted? Deleting a custom role automatically removes all assignments of that role. Users who held it lose the associated permissions at the time of deletion. Their built-in role remains unchanged. This makes cleanup safe — you can delete a deprecated role without manually unassigning it from every holder.
Do custom roles apply within teams, or only at the organization level? Custom roles are organization-scoped. Team membership carries its own team-level roles (admin, member) that govern team-specific operations. If you need to restrict what a user can do within a specific team context, that is controlled through team role assignment rather than custom roles. See organizing access with teams for how team roles and organization roles interact.
How does RBAC connect to SSO and automated provisioning? RBAC governs what authenticated users can do. SSO via SAML and OIDC governs how they authenticate. Combining both with SCIM provisioning gives you a fully automated lifecycle: roles follow directory group membership from day one to offboarding, with no manual assignment steps.
The RBAC model is designed to grow with your organization. You start with built-in roles that cover the common cases and layer in custom roles as your team structures and job functions become more specialized. The permission catalogue gives you the granularity to implement genuine least privilege without writing any policy language or custom code. For how access controls extend to the platform's API consumers as well as human users, see organization API keys and scopes.
The goal is not just compliance with the principle of least privilege. It is operational clarity: every person in your organization knows what they can do, every access review produces actionable findings, and a compromised or misconfigured account causes the minimum possible disruption.