Tenant permissions reference

View and edit grants

1. Sign in and open IAM → Members.
2. Select a member to open their permissions page. You need iam:permissions:view to read the list.
3. Change the member's role or add extra permissions with iam:permissions:manage.
4. Remove unlocked extra permissions with iam:permissions:delete, subject to the delegation rules below.

Permissions describe access. A member needs the right permission even when their role name sounds administrative.

Delegation rules

Administrators can only grant permissions they already hold. When editing another member, you can add a permission only if your own membership includes that permission or a broader wildcard that covers it.

You can manage a member only when every permission on their membership is within your own grants. That includes locked permissions from the member's role and any additional permissions. That prevents handing out access you do not have yourself.

Passkey administration has the same delegation limit and also respects owner status. You cannot remove passkeys from a primary owner unless you are the primary owner, and you cannot manage members on the Owner role unless your own membership also has the Owner role.

The same limits apply when you edit role templates, create invites, import members from CSV, or run bulk actions on the members list:

• You can add a permission to a role only if you already hold it.
• You can remove a permission from a role, from an invite, or from a member only if you already hold it.
• You can assign a role only if every permission on that role is within your own grants.
• You can bulk-remove, bulk-assign a role, or bulk-add a permission only when you could perform that same action on each selected member individually.

Bulk actions cannot include your own membership, cannot remove the primary owner, and cannot move the primary owner off the Owner role.

Owners created during tenant setup receive the default Owner role with * automatically. Narrow that access by creating custom roles when you want separation of duties.

Permission values

Each permission record has an optional value. ONE stores the value and exposes it through CAS and SAPP, but IAM route checks look at the permission name only.

Use values when a connected application needs extra context, such as a scope label or feature flag. Values do not replace a missing permission name.

Outside IAM

CAS sessions and SAPP membership reads return the member's role identifier, role name, and permission names as stored on the membership. Connected applications enforce their own rules against that list. See Tenant roles for the role fields returned by each API.

Custom permission names are valid. ONE will store them, include them in API responses, and apply them to IAM only when they match a name in this reference.