Role-based access control
Roles, permissions, default policies, and how to scope access cleanly across modules.
What RBAC is in ThorStack
RBAC is the access model for everything in Mission Control — modules, records, settings, integrations, agents. Every action a user takes is checked against their effective role at the moment of the action. There is no "admin override" that bypasses the model.
Built-in roles
| Role | What it can do |
|---|---|
| Owner | Everything, including billing, RBAC changes, and tenant deletion. Limited to a small number of users by design. |
| Admin | Everything except billing changes and Owner promotion. |
| Manager | Read/write within their assigned modules; can approve gates within scope. |
| Member | Read/write on records they own or are assigned. |
| Viewer | Read-only across the modules they're entitled to. |
You can clone a built-in role to make a custom role with finer-grained scopes.
How permissions work
Every resource (module, record, setting) has a permission key like crm.deal.read or finance.invoice.send. A role is a set of permission keys. The check at action time is:
- Resolve effective permissions — built-in role + group memberships + record-level grants.
- Match the action against the resource's required keys.
- Allow or deny — and log the check to the audit trail (see Audit logs).
This is checked server-side on every API call. Client-side hiding is a UX nicety, never the security boundary.
Record-level scopes
Some modules support record-level grants on top of role-level permissions. Examples:
- A deal can be shared with a specific user or group beyond the deal owner's team.
- A note can be private, team-visible, or company-wide.
- An invoice can be visible to a contractor without granting them broader Finance access.
Record-level grants always expand, never shrink, what role permissions allow.
Default policy: least privilege
New users default to Member with no module assignments. An Admin must assign modules explicitly. This catches the failure mode where a junior hire accidentally inherits Finance write access from a generic "Staff" group.
Departments
Departments are groups with semantics. Adding a user to the Finance department grants the standard Finance permissions; removing them revokes them. Use departments instead of cloning custom roles per person.
Changes are gated
RBAC changes are themselves a gated action — see Approval gates. Adding someone to Owner triggers a second-Owner approval by default.
Next
- Team management — invite, deactivate, and manage users.
- Audit logs — every permission decision is logged.