Access Control

Why authorization is shaped this way

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, which means the person who authors a change also signs it off. That is exactly the property an auditor will ask you to rule out.

So 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 independently who authors and who signs off.

Two consequences shape everything below. First, the server is the only authority — the web interface ships a copy of the permission table to decide which buttons to draw, and that copy is cosmetic. Second, because authority is per-request rather than per-session, changing someone's role is not a change that has to propagate anywhere.

The three roles

Everyone has exactly one role per organization. There is no role stacking and no group indirection.

Two properties of this model are worth knowing 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. If an organization loses its owner, it cannot get one back through the product.
• admin is an organization-wide trust grant, not a bounded one. 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. Combined with the point above, an admin can permanently strip an organization of its owner. 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. Its effect on each role:

A member with the capability set gains nothing. That is not a side effect of the member role holding no permissions — there is an explicit guard naming the roles eligible for approver grants, and member is not among them. So the flag can be left set on someone you demote without quietly re-granting them anything.

An owner already holds both permissions unconditionally, so the capability changes nothing for an owner either. Its only real effect is on admins: it is the switch that turns an author into an approver.

One caveat to weigh before you rely on it as a separation control. Setting the capability is part of managing members, which is an admin action, and there is no guard against targeting yourself. An admin can grant themselves the approver capability. The capability separates authoring from approval across the people you manage; it does not constrain an admin who decides to grant it to themselves. What you have against that today is the audit trail, not a refusal.

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. What keeps tenants apart is where the organization id comes from. It is resolved from the membership record for the calling user, read on that request — never taken from something the caller can assert independently. A caller with no active membership for an organization is refused before any of that organization's data is addressed, and there is no query in the product that spans organizations.

Switching which organization you are looking at is a session preference and confers nothing. The switch itself verifies membership before it will move, and every subsequent request re-derives your authority from the membership record rather than from that preference.

The same rule governs registry traffic. When a terraform init addresses an organization, it is served for that organization 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 an organization

People join by invitation to an email address, and the invitation names the role it will grant. Invitations can grant member or admin — never owner.

Accepting requires being signed in with a verified email address that matches the invitation. The role granted is read from the stored invitation record, so the request that accepts an invitation cannot name its own role. If you are already a member, accepting consumes the invitation without touching your existing role. Inviting anyone requires an active trial or a paid plan; see plans and entitlements.

Removing someone deletes their membership outright. There is no deactivated or suspended state to reason about, so there is nothing to expire and nothing to sweep.

One thing removal does not do, and it matters: removing a member does not revoke registry tokens owned by the organization that they created. An organization-owned token belongs to the organization and deliberately outlives its creator's membership — the creator is recorded for audit and is not consulted when the token is used. If someone leaving had minted organization tokens, revoke those separately. See registry tokens.

Operating the model

The rest of this page is the operator's half: the full permission matrix, the guarantees the server holds and precisely where each one stops, the real state of separation of duties, and the exact rules that govern assigning and removing roles.

Related

• Organizations and members — organization structure, aliases, membership, invitations
• Promotion and gates — the promotion gate, waivers, and the permission each promotion action requires
• Registry tokens — personal and organization-owned tokens, and revoking them
• Plans and entitlements — what gates on plan rather than on role