Access control

This page is for the organization owner or admin who decides who may author a compliance posture and who may sign it off, and for the auditor who needs to see how that is enforced. By the end you will have assigned roles and the approver capability so that authoring and approval sit with different people, and you will know which of those separations the server refuses and which hold by agreement.

There are exactly three roles, member, admin and owner, and one role per person per organization.
The approver capability is granted separately from role. It decides who may approve a snapshot and promote to a protected environment.
Separation of duties is off by default, and there is no self-service switch for it: enabling it is operator-assisted.
Membership is re-read on every request, so a revoked or downgraded role takes effect on the next request (within seconds on registry traffic).
The organization is the tenant boundary, enforced in the application.

How it works

Role-based access alone is too coarse for the decision that matters most in a compliance tool: who is allowed to put a posture into production. In a three-role model, "can edit" and "can approve" land on the same role, so the person who authors a change also signs it off.

Authority here is split in two. Your role is a base grant that covers authoring, project structure and organization management. Approving a snapshot and promoting it to a protected environment are held back and granted through a separate approver capability, so an organization can decide who authors and who signs off. Every action is governed by a named permission; the role is the base grant, and the permission is what the server checks.

The server is the only authority. The web interface draws its buttons from a copy of the permission table, and that copy is cosmetic: every action is re-checked on the server against a freshly read membership record.

The three roles

Role	What it is
member	Read-only inside the organization. Can read projects, configs, snapshots and environment status, and can preview a promotion. Holds no permissions of its own.
admin	Authoring and organization management: edit and publish configs, create and archive projects, set module aliases, manage members and invitations, mint and revoke the organization's registry tokens, read the audit trail.
owner	Everything an admin has, plus approving snapshots and promoting to protected environments unconditionally, plus the organization-level governance settings.

There is no role stacking and no group indirection. Two properties to know before you assign anyone:

The owner role is assigned when the organization is created, and no product action assigns it afterwards. Role changes accept admin or member only. An organization that loses its owner cannot get one back through the product.
admin is an organization-wide trust grant. An admin can change any member's role and remove any member, including an owner, limited only by a guard that refuses to leave the organization with nobody in an admin or owner role. Keep the admin set small, and keep at least one owner you control.

The approver capability

The approver capability is a per-member flag, set separately from role. It grants exactly two permissions: approving a snapshot, and promoting or binding to a protected environment. It is honoured for admin and owner only.

A member with the capability set gains nothing: an explicit guard names the roles eligible for approver grants, and member is not among them. So the flag can stay set on someone you demote without re-granting them anything. An owner already holds both permissions unconditionally. The capability's real effect is on admins: it turns an author into an approver.

Tenant isolation

The organization is the isolation boundary. Every stored record belonging to an organization is addressed by a key built from that organization's id, and every read and write supplies it.

Isolation is application-level: one shared datastore, partitioned by organization, rather than separate infrastructure per tenant. The organization id is resolved from the membership record for the calling user, read on that request, never taken from something the caller can assert. A caller with no active membership is refused before any of that organization's data is addressed, and no query in the product spans organizations.

Switching which organization you are looking at is a session preference and confers nothing. Registry traffic follows the same rule: a terraform init addressing an organization is served only if the caller holds an active membership, or the credential is a token bound to that organization. That membership read is strongly consistent and fails closed: if the membership store cannot be read, the request is refused rather than downgraded to a lesser tier.

Joining and leaving

People join by invitation to an email address, and the invitation grants member or admin, never owner. The invitation lifecycle is on Organizations and members. Removing someone deletes their membership outright; there is no suspended state.

One thing removal does not do: removing a member does not revoke registry tokens owned by the organization that they created. An organization-owned token outlives its creator's membership. If someone leaving had minted organization tokens, revoke those separately on Registry tokens.

Where it is in the console

Roles and the approver capability are set per person on the organization's member list, which also shows pending invitations to admins and owners. Organization-owned registry tokens are managed on the organization's tokens screen.

Separate authoring from sign-off

Protect the owner. The owner is installed when the organization is created, an admin can demote or remove them, and no product action restores one. Keep the owner account secure, and if you need a second owner, ask us when the organization is set up.
Keep the admin set small. Every admin can manage members and tokens.
Grant the approver capability only to the people who sign off, and withhold it from the admins who author and publish configs.
Check whether separation of duties is enforced for your organization: preview a promotion of a snapshot you published to a protected environment. A sod_self_approval blocker means it is on; a clean preview under those conditions means it is off. See Promotion and gates.
If your framework requires enforced separation between the person who publishes a posture and the person who promotes it, raise it with us during onboarding. Until it is enabled, step 3 holds by agreement and is visible in the audit trail, not refused by the server.

What it does not do

It does not enforce separation of duties by default. The setting is off unless enabled for your organization with our help; there is no toggle in the product.
It does not stop an admin granting themselves the approver capability. Setting the capability is a member-management action, and there is no guard against targeting yourself. The audit trail does not record it either: membership and role changes are outside the trail.
It does not reassign owner. There is no ownership transfer action and no un-remove.
It does not revoke organization tokens when their creator leaves.
It does not scope by project. A role applies to the whole organization.

Who may do what

This is the summary every platform page links to. The full permission-by-action matrix is in the operating details below.

Action	member	admin	admin with approver capability	owner
Read projects, configs, snapshots and environment status; preview a promotion	yes	yes	yes	yes
Edit a config draft, dry-run it, read its coverage		yes	yes	yes
Create a config; create or archive a project; set module aliases		yes	yes	yes
Publish a snapshot; bind to an unprotected environment		yes	yes	yes
Approve a snapshot; propose, approve or revoke a waiver			yes	yes
Bind or promote to a protected environment; roll back			yes	yes
Rename the organization (display name only)		yes	yes	yes
Invite people, change roles and the approver capability, remove members		yes	yes	yes
Create, deactivate or delete organization registry tokens		yes	yes	yes
Edit operational rules and the rules state (trial, paid or enterprise plan)		yes	yes	yes
Read the audit trail		yes	yes	yes
Change the organization's coverage-blocking setting				yes

Plan limits are separate from this table. What your plan allows is on Plans and entitlements.

What gets recorded

Approvals, promotions, waiver decisions and the coverage-blocking setting are recorded in the audit trail; membership, role, approver-capability and token changes are not.

Operating details

The rest of this page is the operator's half: the full permission matrix, the guarantees the server holds and where each one stops, how separation of duties is evaluated when it is on, and the exact rules for assigning and removing roles.

Organizations and members: organization structure, aliases, invitations
Promotion and gates: the promotion gate, waivers, and separation of duties at promotion time
Registry tokens: personal and organization-owned tokens, and revoking them
Plans and entitlements: what gates on plan rather than on role
The audit trail: what approval and promotion records show

On this page