Roles & permissions
Permaura authorises by capability, not by comparing role names. Every gated action names a capability, every route asks whether you hold it, and the role matrix is what maps roles to capabilities. That's why the answer to "can an admin do X?" is always lookup-able rather than a judgement call.
Owners see the live matrix for their organisation at Settings → Roles & permissions.
The matrix
Four states per cell. Two of them you can change, two you can't.
| State | Meaning |
|---|---|
| Always | Granted, and not editable |
| Never | Withheld, and not editable |
| On | Granted by default; an owner can switch it off |
| Off | Withheld by default; an owner can switch it on |
Owner holds everything, always. There is no cell to edit and no override that removes anything from an owner. The table below is therefore admin and member only.
Organisation
| Capability | Admin | Member |
|---|---|---|
| Rename organisation | Always | Never |
| Delete organisation | Never | Never |
| Manage billing & plan | Always | Never |
Deleting the organisation is owner-only and unlockable. An admin can change the plan and the card but cannot remove the thing being billed.
Members
| Capability | Admin | Member |
|---|---|---|
| Invite members | Always | Never |
| Change roles / remove members | Always | Never |
| Edit role permissions | Never | Never |
Editing the matrix is owner-only and unlockable. An admin can hand out existing roles but cannot redefine what a role means — otherwise an admin could quietly grant themselves the rest.
Workspaces
| Capability | Admin | Member |
|---|---|---|
| Create workspaces | Always | Never |
| Rename / delete workspaces | Always | Never |
| Assign members to workspaces | Always | Never |
Gateways
| Capability | Admin | Member |
|---|---|---|
| Add the gateway | Always | Never |
| Remove the gateway | Always | Never |
| Enable / disable remote access | Always | Never |
Giving a gateway a public URL changes the organisation's exposure, so it sits with admins rather than with whoever happens to be operating that workspace today.
Operations — the tunable part
This is the day-to-day operator surface, and the only group with editable cells. Admins always hold all of it. Members hold all of it by default, and an owner can switch any of these off.
| Capability | Admin | Member |
|---|---|---|
| Add / configure connections | Always | On |
| Create / edit policies | Always | On |
| Create / edit grants | Always | On |
| Add / rotate sealed credentials | Always | On |
| Connect / approve / remove agents | Always | On |
| Open / revoke gateway sessions | Always | On |
| Approve or deny held requests | Always | On |
| Enrol / remove approval devices | Always | On |
| Pause the broker / set approval gates | Always | On |
Two patterns worth knowing
Making a read-only member
Switch every Operations capability off for the member role. They keep the console — dashboard, audit log, grants and policies as they stand — and can change nothing. Useful for an auditor, a stakeholder who wants visibility, or a new hire in their first week.
The narrower version is better if you only want one person read-only: leave the role matrix alone and scope them into a workspace as a viewer instead. See People & access.
Splitting "operates it" from "governs it"
A shape that works well in a team: members operate — they add connections, connect agents, resolve approvals — while grant.manage and policy.manage are switched off for them. Anyone can wire something up and run it; only admins can widen what it's allowed to do. It keeps the deny-by-default boundary in the hands of the people accountable for it, without making everyone wait on an admin for routine work.
Switching Approve or deny held requests off makes members unable to clear the queue. That's a real safety control, but if your admins aren't around often it turns every approval-gated action into a bottleneck. Decide which failure you'd rather have.
Overrides are per organisation
A change to the matrix applies to that organisation only. If you own two, they can differ, and the defaults above are what a fresh organisation starts from. Switching a cell back to its default removes the override entirely rather than storing it, so "reset to default" and "never touched" end up in the same state.
When someone hits a wall
A capability check that fails produces one message: "You don't have permission to do this in this organisation." It doesn't name the capability, deliberately — the error is user-facing and shouldn't teach an attacker the shape of your permission model.
To diagnose it, look up the action in the tables above, check the person's role at Settings → Members, and check whether an override has moved that cell. Almost every real case is one of three things: they're a member and the action is admin-only, an owner switched that Operations cell off, or they're scoped into the workspace as a viewer.