Roles and permissions

An organization has five roles. They are fixed. You cannot invent a role or build your own permission set, and that is on purpose: a closed list is a list you can reason about.

​

The five roles

​

What each role can do

Every action in the organization is one of nineteen. This table is the whole model. Two things only the owner can do: delete the organization, and manage billing. An admin runs everything else.

​

Organization permissions

Permissions apply to everyone in the organization. An admin sets them on the Permissions screen.

​

Anyone can invite

This one costs money, so it is off by default. Off: an organization channel invite link only admits people who are already active members. On: an outsider who follows the link joins as a guest, and consumes a seat. Every new person costing a seat should be an administrator’s decision, so Zas makes you turn this on deliberately.

​

Channels per member

A regular member may create up to this many organization channels. Owners and administrators are exempt, so they can always set up managed spaces.

​

Agents per member

How many coding agents a member or guest may pair, counting revoked ones. Setting it to 0 turns agents off for them. Owners and administrators are exempt here too. The policy follows the person into every context, including their personal one, because agents belong to an account rather than to a workspace. With several memberships, the smallest number wins.

​

Agents in organization channels

Whether an agent may hold one of the organization’s channels at all. Off by default, and off is exactly the behaviour organizations had before this setting existed. Unlike every other permission on this page, it exempts nobody, owners and administrators included. The others are about one person’s allowance; this one is about the organization’s data. It covers both kinds of organization channel: the ones the organization manages, and the ones a member created inside the workspace. It is read on every request an agent makes, so turning it off closes every such grant at once. The Agents screen lists the agents that reach your channels and takes that access back one agent at a time. Agents in an organization covers both settings and what they do not give you.

​

Invites

An admin invites by email address from the Invites screen. The console shows every open invitation and its state. An admin can revoke an invitation, or reissue it if the link went stale. A guest’s access is renewable: an admin can extend it rather than re-inviting from scratch.

​

Members

An admin can change a member’s role, deactivate a member without removing them, reactivate them later, or remove them entirely. A seat is freed when a member is removed.

​

Transferring ownership

Ownership moves in two steps. The current owner starts the transfer, and the receiving person completes it. Neither half does anything on its own.

​

Work sessions

A person signed in to an organization holds a work session, and it does not last forever. Refreshing a sign-in does not extend either clock. The live session record decides on every request, not the token in the browser. Each person can see their open work sessions in Settings → Work sessions, with the device, when it was last used, and when it ends at the latest. Any of them can be ended from there.

​

The audit log

Every administrative action is written to the organization’s audit log with who did it, when, and what it touched. That covers organization changes, member invites and role changes, invite revocation and reissue, guest renewal, ownership transfer, branding publishes and rollbacks, domain changes, billing events, permission updates, and closing the organization. Two agent-governance acts get their own rows: turning Agents in organization channels off, with the number of grants that closed, and revoking one agent’s access from the Agents screen. What an agent itself does is not written here. Owners and admins can read the log and export it. Nobody else can see it.