Organizations and roles

All permissions in Izri are organization-scoped. There are no global user roles.

Being an owner of one organization grants you nothing in another. Every capability is gated through your membership role in the specific organization that owns the resource.

The four roles

Role	Intent
OWNER	Full access, including billing and destructive operations.
ADMIN	Everything operational — projects, runs, webhooks, tokens — but not org-level ownership.
MEMBER	Day-to-day contributor. Can read projects and trigger runs.
VIEWER	Read-only.

New members default to MEMBER.

What each role can do

Permissions are expressed as scopes. These are the defaults per role:

Scope	OWNER	ADMIN	MEMBER	VIEWER
projects:read	✓	✓	✓	✓
projects:write	✓	✓
projects:delete	✓	✓
tests:read	✓	✓	✓	✓
tests:run	✓	✓	✓
analysis:read	✓	✓	✓	✓
analysis:run	✓	✓
webhooks:read	✓	✓
webhooks:write	✓	✓
org:read	✓	✓
org:write	✓
org:members:manage	✓
costs:read	✓	✓
tokens:read	✓	✓	✓	✓
tokens:write	✓	✓

OWNER holds the * scope, which grants everything — including anything added in future versions.

The practical line between MEMBER and VIEWER is tests:run. A member can trigger a run; a viewer can only read the results.

Roles cap what a token can do

An API token can hold a subset of its creator's role scopes, never more. A MEMBER cannot mint a token with projects:write, even deliberately.

This means a token's power is bounded by the role of the person who created it, at creation time. Changing someone's role does not retroactively expand tokens they already minted — reissue them.

The runner scope

runner:write is server-to-server only. It exists so the runner service can move test runs through their lifecycle, and it is never offered when creating a token through the UI — it's minted out-of-band as part of runner deployment. If you're self-hosting, this is the credential the runner needs.

Related

• API tokens — minting and scoping.
• Projects — what organization membership gets you access to.