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
Organization	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 organization 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 organization 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		✅	Never
Delete the organization		Never	Never
Edit what roles are allowed to do		Never	Never
Create and manage workspaces, assign people to them		✅	Never
Add or remove the gateway, turn remote access on or off		✅	Never
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 organization, and edit the role matrix. An admin runs the organization day to day but cannot redefine what a role means or remove the organization 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 one credential back. Nothing in Permaura shows you a single sealed secret: not the console, not the API. You can rotate or replace one, but not view it. A vault export is the exception that matters: it writes every credential on the gateway into one bundle, sealed under a passphrase the person exporting chooses, and whoever holds the bundle and the passphrase can read them all. Owners can export; admins and members cannot unless an owner switches Export the vault on for them (Roles & permissions). With a device paired, and the approval floor not lowered, an export waits for a device signature first. From gateway 1.3.46 that signature has to come from someone other than the person exporting when they ask through permaura.com: their own phone cannot confirm it while a device paired to another person is trusted, and confirms it alone only where theirs are the only devices trusted, as on a gateway with a single owner, or where the person exporting is the gateway's owner, whose device may always confirm.
• Delete another person's account. Paying for their seat doesn't grant that. You can remove them from your organization, 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 tunneled, or confirming it's you 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. Every account holds a strong factor from sign-up; add a second one on another device and keep your backup codes somewhere safe, so losing one phone doesn't lock you out. Your account can change every grant in the organization, 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, a second strong factor 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 organization, 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.