How whoot. resolves, enforces and audits its 58 tenant permissions — the risk tiers, the privilege ceiling that stops escalation, and the guard that keeps a workspace from losing its last administrator.
How a Permission Check Runs
Every action in whoot. — joining a room, reading the audit log, changing a payment method — is gated by a named permission. A check resolves in the same four steps whichever surface asked:
The caller is authenticated. The session is verified against the authentication service on every request, so a revoked session stops working immediately rather than at token expiry.
The workspace is resolved. The tenant is looked up from the URL, and soft-deleted workspaces do not resolve.
The permission set is resolved. A single database function returns every permission the caller holds in that workspace, from the role attached to their membership.
The action is allowed or refused. A caller without the permission gets a 403 and nothing happens.
Permission sets are resolved per request, not cached between requests. A role change takes effect on the caller's very next request — there is no window in which a demoted administrator keeps administrative access.
Where Enforcement Happens
Server-side on every API call. Each endpoint resolves the caller's permissions before doing any work. There are no client-only gates.
In the database. Row-level security policies are built on the same permission function, so even a direct query cannot read another workspace's data.
In the interface, as a courtesy. Buttons and pages the caller cannot use are hidden, and the open dashboard re-checks access periodically so a revoked member's view catches up without a reload. This is convenience, never the control.
Permission Categories
Fifty-eight permissions are available to a workspace, grouped into nineteen categories. A further two categories — platform operator and managed-service-provider administration — exist only for whoot. staff and reseller partners, and are not shown to an ordinary workspace.
Rooms — using, creating, configuring, sharing and deleting voice rooms
Users — the member list, invitations, the directory, account security and role assignment
Roles — the role definitions themselves and the permissions they grant
Settings — workspace configuration, retention, MFA policy, and workspace deletion
Billing — plan, licences, invoices and payment method
Single Sign-On — identity providers, domain claims and directory role mapping
API Keys — public API and SCIM credentials
Access Requests — temporary cross-organisation access into and out of this workspace
Activity Logs — the audit trail
Analytics — usage dashboards, transcript search, and AI analysis
Replay — playback of recorded transmissions, and bookmarks
Call Quality — per-call network and audio metrics
Messaging — SMS campaigns, the inbox and recipient lists
Security Operations — incidents, protocols, announcements and alerting
Behavioural Intelligence — topic intelligence and keyword insight
Compliance — regulatory export, legal hold and the keyword watchdog
Support — support tickets raised with whoot.
Phone Numbers — dial-in numbers, routing and regulatory bundles
The full list, with a description of each permission, is in the role editor at Admin → Security → Roles & Permissions. It is the authoritative version — this page names the categories, not every key.
Risk Tiers
Every permission carries a tier, so a reviewer can tell at a glance which grants matter. The tier is descriptive: it changes how the permission is presented, never what it does.
Standard — the end-user surface, and read-only views of the member's own things. Unmarked in the editor.
Elevated — reads or acts on other people's data, or configures a system the whole workspace depends on.
Critical — destroys data, grants authority, or spends money.
Each role shows a count of the critical permissions it carries, in the role list and while you are editing it. A role with an unexpected critical count is the first thing to look at in an access review.
The Privilege Ceiling
Nobody can hand out authority they do not have. The rule is enforced on the server, on every path that could otherwise be used to escalate:
Creating a role — every permission on it must be one the author holds.
Editing a role — every permission added must be one the editor holds. Permissions the role already carries are preserved, so an administrator can safely edit a role that reaches further than they do; they just cannot extend it.
Assigning a role — the role's entire permission set must be a subset of the assigner's own. This is what stops somebody with only user-management rights making themselves a full administrator.
Mapping a directory group to a role — the same subset rule, applied when the mapping is written rather than when it fires.
Removing permissions is not restricted — taking access away cannot escalate anyone. The one removal that is genuinely dangerous is covered separately, below.
The Last-Administrator Guard
A workspace with nobody able to assign roles cannot repair itself, because the privilege ceiling means no remaining member can mint the authority back. whoot. therefore treats Change user roles as a permission the workspace must never lose, and refuses any change that would take the last holder of it.
Assigning that member a role that does not carry it
Deleting the role that carries it, which would move its members to End User
Editing that permission out of the role
Removing the member from the workspace
An automatic role change from a directory group mapping
The first four are refused with an explanation. The fifth is skipped silently and recorded in the audit log, because a login must not fail on account of a mapping that cannot safely be applied.
The guard fails closed. If it cannot confirm that an administrator would remain, the change does not go through.
Directory-Driven Assignment
Roles can be assigned by your identity provider rather than by hand, by mapping SSO group claims or SCIM groups to roles. SSO mappings are applied at every sign-in, so a change in your directory propagates; SCIM mappings are applied whenever group membership changes.
Because a mapping is a standing instruction to grant a role, writing one requires both Manage SSO providers and Change user roles, and is subject to the privilege ceiling. The sync also re-checks that the mapped role still belongs to the workspace each time it fires, and will never demote the last administrator.
Every change to the access model is written to an append-only audit log. The log cannot be edited or deleted by anyone in the workspace, including a full administrator.
Role created, updated, deleted — with the full permission set before and after
Role assigned to a member — with the previous and new role
Directory mapping created, updated, deleted — with the group and role involved
Automatic role change — recording the group that matched, rather than an actor, because the directory made the decision
Skipped demotion — when the last-administrator guard blocked an automatic change
Actions taken under a cross-organisation access grant — flagged with the request they were performed under
This is the evidence base for SOC 2 (CC6.1, CC6.3, CC7.2) and ISO 27001 (A.9, A.12.4) access-control requirements.
Periodic Access Reviews
Go to Admin → Security → Access Review.
Review every member, their role, how many permissions it carries, and when they last signed in.
Change or remove anything that no longer fits.
Certify the review. The certification is recorded with your identity and the date.
Export the list if your auditor needs a point-in-time record.
Access reviews satisfy SOC 2 Type II (CC6.1, CC6.2, CC6.3), ISO 27001 (A.9.2.5), and comparable HIPAA access-management controls.