Members and roles

Any account can be shared — the one created for you at sign-up as much as one you create later. Invite people by email, give each one a role, and the platform enforces what that role may do — in the dashboard, in ribo, over the REST API, and through MCP.

Members live under Account → Members. Only an owner or an admin sees the management controls.

Roles

Role	May do
owner	Everything, including renaming the account, managing members, and closing the account
admin	Manage members and every resource, but no vault access and no account-level writes
developer	Create and change Cells, databases, buckets and domains; delete none

Roles are not advisory. Every credential carries its role as a signed claim, and the management API narrows the credential's effective scopes to that role's ceiling on every request:

Role	Scopes it can exercise	Withheld
owner	All 25	—
admin	22	`vault:read`, `vault:write`, `account:write`
developer	10	The three withheld from admin, plus every `:delete`, plus `billing:`, `vesicle:`, `mast:` and `explant:export`

The ten a developer holds are cells:read, cells:write, databases:read, databases:write, buckets:read, buckets:write, domains:read, domains:write, account:read and events:read. A role Tissue does not recognize is treated as a developer, which is the narrowest defined ceiling.

The ceiling is a cap, not a grant: an API token holds the intersection of the scopes it was created with and what the holder's role allows.

Inviting someone

Account → Members → Invite, then give an email address and a role. owner is not assignable over the API — ownership moves by hand, at the operator console.

Your own address has to be verified. A session whose address has not opened its verification link is answered "Verify your email address before inviting members." and nothing is sent.
The invitation link is valid for 7 days.
One open invite per address per account. A second invite to the same address answers "There is already an open invite for that address."
Inviting somebody who is already a member answers "That person is already a member." Whether the address is already signed up is not revealed: an invite to an address that has signed up looks exactly like any other.
An invite can be withdrawn (Revoke) at any time before it is accepted. The link is already in the invitee's mailbox, so revoking is what makes it stop working there.

Accepting

The invitee opens the link and must be signed in as the address the invite was sent to. A different signed-in address gets "That invite was sent to a different address" — forwarding the mail does not redirect the invite. Someone who has not signed up yet signs up with that address first, then opens the link again.

Accepting joins the account and switches the session onto it at the invited role. Nothing the invitee already holds is revoked.

An unknown, revoked, or expired link all answer with the same string, so a stale link is indistinguishable from a guess.

Changing a role

Owners and admins can move a member between admin and developer. An owner cannot be demoted or removed over the API, and the same message covers demoting any owner and demoting the last one, so the answer never reveals how many owners an account has.

A role change takes effect by ending the member's sessions: they are signed out and sign back in at the new role. Two things move, and both have to land for the change to be fully applied:

Their sessions end — immediately in the account area, and within 15 seconds at the management API and ribo.
Their existing tok_ API tokens on this account are re-cut down to the new role's ceiling, so a demoted admin cannot keep exercising cells:delete through a token minted while they could.

If either half has not landed when the response is written, the dashboard reports the change as pending rather than done. The queued half drains on the next sign-in on the platform.

Removing someone

Removing a member deletes their membership, ends their sessions on the same timing as a role change, and deletes every API token they hold on that account. The session counter alone would not do it: a tok_ token is deliberately outside that counter, so without the token delete a removed member would keep a working credential on an account they are no longer part of.

Anyone can remove themselves without an administrative role — leaving only reduces your own access. If you still belong to another account, your session is re-issued against it; if that was your only account, the session ends. An owner leaves by handing ownership over first.

Every change is on the record

Inviting, revoking an invite, joining, changing a role and removing all write a row to the activity feed naming who did it and to whom. Leaving is recorded as a removal you performed on yourself, so the feed distinguishes it from an administrator removing you.

What a developer sees of the account

A developer's session can read the account and its activity feed, which is what account:read and events:read cover.

Vault scopes sit above the admin ceiling, so listing a Cell's vault key names takes an owner's session or an API token an owner created. Vault values are never returned to any credential at any role.