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.