Preparing for granular RBAC roadmap

Published · Last updated: May 2026 · 5 min read

Who this is for

Use this article if you are planning team permissions before rolling out granular role-based access control across an organization.

Internal content note: the RBAC engine, Team UI, Access Matrix v1, pending invites, AI Pilot tool enforcement, and AI proposal/goal/trigger lifecycle gates are implemented on dev. Broad protected operational route migration is still in progress, so public copy should avoid saying "every product action is RBAC-gated" until Phase 20.6 is fully closed.

What you will complete

You will map team responsibilities to roles, decide which actions should be read-only or managed, and prepare a simple testing checklist before inviting users broadly.

Before you begin

List the people who need access.
List the resources they need to see, such as servers, sites, apps, backups, costs, and alerts.
Decide who is allowed to change production systems.
Decide who is allowed to approve or run AI Pilot actions.

Step-by-step instructions

Start with the smallest group of users.
Put each person into one of four buckets: owner, administrator, operator, or viewer.
Use system roles for simple teams.
Use predefined templates for common jobs such as monitoring, billing, deployment, and security review.
Create custom roles only when a template is too broad or too narrow.
Use resource-scoped access when someone should only work with specific servers, sites, or cloud accounts.
Use IP allowlists and access expiry for contractors, agencies, and regulated teams.
For every role, write down which areas should be visible.
For every role, write down which actions should be allowed.
Treat read permissions as permission to view information only.
Treat manage, write, deploy, create, and delete permissions as change-making permissions.
Decide whether each role can use AI Pilot.
Decide whether each role can approve or run AI Pilot actions that change resources.
Test each role with a real low-risk user before assigning it widely.

AI Pilot and role permissions

AI Pilot should follow the same access expectations as the rest of CloudAIPilot:

A user who can only read a resource should only be able to ask AI Pilot read-only questions about it.
A user who can manage a resource may be allowed to ask AI Pilot to propose or run changes for it.
A user who cannot access a resource should not be able to use AI Pilot to work around that restriction.
Proposal approvals, goal creation, and authenticated goal-trigger actions check the user's current AI permissions before they run.
Goal triggers also re-check the creator's AI execute permission when a trigger fires.
Organization administrators can separately control AI Pilot safety settings and feature toggles.

For cautious organizations, keep AI execution permissions limited to owners, administrators, and trusted operators until your internal testing is complete.

Use these two AI permissions in explanations:

agent:use means the user can open AI Pilot and ask for help.
agent:execute means AI Pilot may run or propose change-making actions, but the user still needs the matching resource permission, such as server:manage or site:create.

Recommended role testing checklist

Sign in as an owner and confirm all team settings are visible.
Sign in as an admin and confirm organization management tasks work as expected.
Sign in as a member and confirm day-to-day operations work but organization ownership actions do not.
Sign in as a viewer and confirm read-only pages are visible but change-making buttons are unavailable or rejected.
Test each predefined template against the job it represents.
Test each custom role against the exact permissions you selected.
Try opening a page the role should not access.
Try running a change the role should not perform.
Try asking AI Pilot to read a permitted resource.
Try asking AI Pilot to change a resource the role should not manage.
Review the activity and audit history after testing.
Adjust the role and retest before inviting more users.

What success looks like

Users can see the sections they need for their job.
Change-making actions are unavailable, disabled, or rejected for users without permission.
AI Pilot follows the same access boundaries as the rest of the product.
Support can explain every denied action by pointing to the user's assigned role.

Common errors and exact fixes

Symptom: A user sees a page but cannot complete an action.

Cause: Their role may include read access but not manage access.

Fix: Assign a role with the needed manage permission, or keep the user read-only if that is intentional.

Symptom: A custom role is difficult to reason about.

Cause: It may include too many unrelated permissions.

Fix: Start from the closest predefined template, then add only the missing permissions.

Symptom: A user gets denied in AI Pilot.

Cause: AI Pilot follows the user's role and resource access.

Fix: Confirm the user has both access to the resource and permission for the action they requested.

Symptom: A viewer asks why a button is missing or disabled.

Cause: The action changes a resource and requires more than read access.

Fix: Explain that viewers can inspect but cannot change resources.

Safety notes

Test custom roles with non-production resources first.
Keep production-changing actions limited to trusted users.
Review AI Pilot permissions separately from normal page access.
Recheck roles after reorganizations, contractor changes, and production incidents.

Invite members and role basics
Current role model and practical governance
Access troubleshooting for team members