What an owner or admin looks after

If you're the only person using Permaura, most of this is optional. The moment a second person or a second environment appears, you're administering something, and it helps to know exactly what.

Four layers, and which one you're changing

Almost every "who can do this?" question resolves by working out which layer you're standing on.

Layer	What lives here	Who can change it
Account	A person's own profile, password, 2FA, passkeys	Only that person
Organisation	The plan and payment method, the member list, the role matrix	Owner, and admins for most of it
Workspace	One isolated environment: its gateway, its own member scoping	Owner and admins
Gateway	Connections, sealed credentials, policies, grants, agents, the audit log	Anyone with the matching operator capability

The rule that saves the most confusion: the organisation decides who you are, the workspace decides where you can work, and the gateway decides what you can do there. Three separate questions with three separate answers.

The three roles

Permaura ships three organisation roles. Their shape is fixed on purpose — structural power stays with owners and admins, and members can never reach org, member or workspace structure however you configure things.

	Owner	Admin	Member
Everything below, always	✅
Run the org: rename, billing, invite, change roles		✅	—
Delete the organisation		—	—
Edit what roles are allowed to do		—	—
Create and manage workspaces, assign people to them		✅	—
Add or remove the gateway, turn remote access on or off		✅	—
Day-to-day operations: connections, policies, grants, agents, approvals		✅	✅ by default

Two things only an owner can do, and no override changes them: delete the organisation, and edit the role matrix. An admin runs the organisation day to day but cannot redefine what a role means or remove the organisation itself.

Roles & permissions has the full capability list and which cells you can tune.

What you can't do, even as owner

Worth knowing before someone asks you to:

• Read a credential back. Nothing in Permaura returns a sealed secret — not the console, not the API, not you. You can rotate or replace one; you can never see it.
• Delete another person's account. Paying for their seat doesn't grant that. You can remove them from your organisation, which cuts their access immediately; the account itself is theirs.
• Lower the approval bar with a session alone. Once an approval device is paired, raising the bar works from anywhere; lowering it needs the machine running the gateway if it's local or tunnelled, or a fresh sign-in plus a signature from a device you still hold if it's hosted. That's deliberate: an attacker holding your session shouldn't be able to clear it.
• Approve on someone's behalf without it being recorded. Every approval and denial is a signed audit entry naming who resolved it.

Your first week

A short checklist that prevents most of the problems in Playbooks:

1. Protect your own account first. Turn on two-step verification or a passkey. Your account can change every grant in the organisation, so it's the highest-value target you own.
2. Decide the workspace split before inviting anyone. Separate environments are much easier to set up than to unpick. A common shape is one workspace per environment (production, staging) or one per team.
3. Invite people at the lowest role that works. Admin is for people who should be able to change billing and membership. Most people are members. See People & access.
4. Scope members to workspaces if the split matters. An unscoped member reaches every workspace. Scoping is opt-in, and easy to forget.
5. Write your policies before your grants. Policies are reusable templates; grants hand them out. Getting the policy right once saves editing five grants later.
6. Put anything irreversible or expensive behind approval. Refunds, deploys, deletes, anything that spends money. Approvals covers the ladder.
7. Set budgets on grants. A cap on calls per rolling day is the cheapest protection against a loop you didn't expect.
8. Look at the audit log once, deliberately, while nothing is wrong. Knowing what normal looks like is what makes abnormal visible. Monitoring says what to look for.

Do the boring one first

Of everything on that list, 2FA on your own account and a budget on the Default grant buy the most safety for the least effort. If you only do two things, do those.

Where each setting actually lives

Settings are split to match the hierarchy, which trips people up until they see the rule.

You're changing…	Go to
Your profile, password, 2FA, passkeys	Settings → Account
Plan, payment method, invoices	Settings → Billing
Who is in the organisation, and their role	Settings → Members
What a role is allowed to do	Settings → Roles & permissions (owner only)
How many workspaces, and their names	Settings → Workspaces
This workspace's gateway and remote access	console sidebar → Workspace → Gateway
Who is scoped to this workspace	console sidebar → Workspace → Members
Approval devices	console sidebar → Workspace → Devices

The short version: who pays and who you are lives in Settings; this environment's gateway and people live in the console's Workspace group.